Web Server Configuration Features
Fenix is capable of hosting multiple web servers simultaneously. Each server has a number of basic configuration options. Several features may also be controlled globally through preferences.
Each server has an editable descriptive name/title to quickly identify it.
All web servers require ports. Public web servers typically run on port 80. This is a protected port on desktops, and it's impossible to run more than one server on any given port at the same time. Fenix automatically assigns an available port (by default), which can be modified at whim. If you prefer not to use ports, domain names are also available in commercial editions.
-- PRO Feature --
Fenix PRO has a local DNS server, capable of supporting domain names like mydomain.com.
Web servers must have a root directory containing the files to serve. The core (free) version of Fenix supports a single web root directory, which is suitable for serving many web projects. Fenix PRO supports multiple web root directories per server.
Multiple web roots are useful for sharing common or repeatedly used resources. For example, a company may use a common set of icons and CSS styles across all projects. These can be stored in a single directory and used as a root on any web server.
Any number of web roots can be defined in any order. The order in which they are listed is important. When a request is made to the server, Fenix will scan the directory in search of the file and reply with the first match it finds.
Default File Names
When a request is made to a server that does not specify a particular file, default file names can be used. This is a standard feature of all major web servers. By default, Fenix uses the industry standard list of
index.html, index.htm, default.html, default.htm. This list can be set globally for all servers, or for each individual server.
By default, Fenix logs requests in realtime, ephemerally. Logs are displayed in the visual interface immediately and retained as long as Fenix remains open. Ephemeral logs are discarded when the application exits (which is not the same as stopping a server or running Fenix as a background process).
Each request log consists of a timestamp, request method, HTTP response status code, response time, and the path of the requested resource.
Realtime logs are typically sufficient for most development work, but a "Log to Disk" feature is available for permanent storage. This feature writes logs to a file and displays them in the realtime log viewer.
Fenix ships with a file browser. If a request is made for a directory with no default file, the file browser will be displayed.
The slightly highlighted blue rows indicate a special viewer is enabled for these file types (see "Rendering" below).
Like most major web servers, the file browser provides basic access to files within a directory. Since Fenix also has a robust sharing feature, there may be sensitive situations where guest access to the file browser is undesirable. To accommodate these situations, the file browser can be turned off for all servers or individual servers.
Rendering: Markdown, JSON, XML, YML
Due to the widespread popularity of certain file formats, Fenix provides "pretty print" features for Markdown (
.md), JSON, XML, and YAML/YML files. These can easily be toggled on/off to suit development needs.
For example, a raw/unrendered
demo.yml file may display like:
When "Pretty YML" is on, a friendlier view of the file is rendered1.
Take note that common IDE features such as line numbers, code-collapsing, invisible character display, spacing, and theming are all available.
Minification is often used to reduce bandwidth and decrease response times. Minification is not typically done by a web server. It is more commonly part of a build process executed before files are made available on a server. Since Fenix must minify each file on the fly, it adds a small amount of processing time to each request. For this reason, assessing performance on the basis of minification is not recommended.
Minification can be toggled on/off per web server.
Entity tags are a method of optimizing cached content and site performance, which Fenix fully supports. Similar to minification, initial ETag resources will have minor additional processing time, but all subsequent requests will perform accordingly.
ETags can be toggled on/off per web server.
Dynamic compression using gzip can be toggled on/off per server. It is very rare for compression to provide any performance gain on a local development server since HTTP traffic never actually leaves the desktop. However; compression may have an impact on file size. By turning compression on and off, it is possible to determine this impact, which helps predict how much bandwidth any particular request may save (before ever shipping code to production).
Compression can be toggled on/off per web server.
Cross origin resource sharing (CORS) provides restrictions on the use of resources from an external domain. CORS affects the HTTP headers returned by a web server. Frontend developers often run into problems with CORS when using JSON services or REST API's. The most common scenario occurs when a frontend developer must create error handling for resources blocked by CORS restrictions. This can be an exercise in frustration when the developer must rely on a backend architect to modify a server configuration to test each use case. Fenix eliminates this pain by providing a CORS toggle option.
CORS can be toggled on/off for each web server.
-- PRO Feature --
Fenix can send custom HTTP headers in response to all server requests, all of which are fully CORS supported (when applicable). Custom headers are often used when mocking a JSON API.
-- PRO Feature --
SSL can be toggled on/off per server in realtime. Using Fenix, developers do not need to create self-signed certificates, manage public/private keys, or deal with trust chains. While it is unnecessary, Fenix provides a global preferences section allowing developers to modify some details of SSL certificates if they choose to.
Fenix commercial editions ship with a native certificate authority, capable of automatically and immediately issuing, renewing, and revoking SSL certificates. It is a completely self-contained system that requires no administration or configuration. All generated certificates are domain aware and registered with the local certificate trust chain. In simple terms, developers will not receive browser warnings about untrusted certificates. Fenix automatically negotiates trusts with Google Chrome, Opera, Mozilla Firefox, Microsoft Internet Explorer, Microsoft Edge, and Apple Safari. Other browsers based on any of the aforementioned are also supported.
*These are not LetsEncrypt certificates. Fenix certificates are specifically designed for desktop web server use only.
1. If the "light" theme is selected, the renderer will utilize a light theme as well. ↩