Open the console and select Server Configuration to display the general server configuration dialog.
The following subsections describe the server configuration options.
Select Parameters in the Server Configuration dialog to display the server parameters dialog.
The dialog includes the following fields:
Server Root: The root path of the web server. By default, it is the directory where Abyss Web Server executable is installed. It is used as the base path for all relative real paths in the configuration.
Maximum length of the HTTP request line: The maximum length in bytes of the HTTP request line. Requests which do not respect this limit are refused and a HTTP error 414 (Request-URI Too Long) is reported to the client.
Maximum length of the HTTP request headers: The maximum length in bytes of all the HTTP request headers. Requests which exceed this limit are refused and a HTTP error 413 (Request Entity Too Large) is reported to the client.
Initial Window Size: The initial connection flow-control window size in bytes. By default, it is set to 65535 bytes. Changing it impacts initial buffer sizes on both the client and the server. It is recommended to not alter its default value unless you are fully aware of how it affects the latency and the quality of service of HTTP/2 connections.
Maximum Concurrent Streams Count: The maximum number of streams that could be multiplexed over each HTTP/2 connection. A stream is almost always associated with a HTTP request. By default, this parameter is set to 40. Do not decrease it too much if you have content heavy pages.
Operating System User: The user name under whom privileges the server is run when launched as a launch daemon (system service). See the "Startup Configuration" appendix for more information.
Operating System Group: The group identity under which the server is run when launched as a launch daemon (system service). See the "Startup Configuration" appendix for more information. If it is set to Default User's Group, the server uses the default login group associated with the selected operating system user.
Back-end Operation Support: When Abyss Web Server is used as a back-end for another reverse proxy, it can be configured to restore the original IP address of the reverse proxy client and other details before processing the request. This can help make the frontal reverse proxy completely transparent to Web applications running on Abyss Web Server and to the logging taking place on it.
Press Edit... to control the back-end operation support settings. This dialog contains the following fields:
Forwarded-For Headers: The names of the headers that should be checked for the original IP of the reverse proxy client. X-Forwarded-For and X-Real-IP are the most common ones widely used in reverse proxies.
Forwarded-Host Headers: The names of the headers that should be checked for the original Host header value as the client sent it to the frontal reverse proxy. X-Forwarded-Host and X-Host are the most common header names used for that purpose. Note that when the Host value is restored, the request will be normally processed and checked against the host names of each of the hosts managed by the server.
When the server sends a document to a browser, it also sends its MIME type. This information helps the browser to know what kind of file it is (HTML, ZIP, JPEG image, etc…) and what to do with it (display it, save it on the disk, launch a configured application to read it, etc…). Abyss Web Server comes with a list of common MIME types used as a default.
A MIME Type has the format type/subtype and is associated to one or more extensions separated by spaces.
Use the Custom MIME Types table to edit, remove or add custom MIME types. If a MIME Type is declared in both the Custom MIME Types table and the Default MIME Types table, the custom definition prevails.
Abyss Web Server gives you complete control over the bandwidth the server uses when answering to requests. Select Global Bandwidth Limits in the Server Configuration dialog to display the global bandwidth parameters dialog. For finer bandwidth settings, you should use Bandwidth Limits in every host configuration menu.
The dialog contains the following fields:
Maximum Bandwidth Per IP Address: The total amount of output bandwidth that the server should not exceed for all the connections made by a single IP address. No such limit will ever be applied if this parameter is set to Unlimited.
Maximum Requests Per IP Address: The maximum number of simultaneous requests originating from the same IP address that the server accepts to process. To disable such a limitation, set this parameter to Unlimited.
Note: Abyss Web Server does always its best to deliver data to clients while respecting the restrictions set on the bandwidth. For example, assume that Maximum Total Bandwidth is set to 10 KB/s and Maximum Bandwidth Per IP Address to 4 KB/s. If there are 2 clients connecting from different IP addresses, the server allocates to each of them a bandwidth of 4 KB/s. But if there are 5 clients, the server will allocate to each of them only 2 KB/s.
Although Abyss Web Server is secure and has an integrated system to prevent malicious accesses to the server, it was equipped with an automatic anti-hacking protection system to detect clients that are trying to attack the server and to ban them. This system improves the overall security, detects at an early stage denial of service attacks, and saves the bandwidth that could be wasted during attacks.
To configure the anti-hacking system, select Anti-Hacking Protection in the Server Configuration dialog.
The displayed dialog is made of the following items:
Do not Monitor Requests from: This table contains the IP addresses or IP address ranges that should not be protected against hacking. Refer to "IP Addresses and Ranges Format" appendix for more information about the IP addresses and ranges. Fill this table with trusted IP addresses only.
Bad Requests Count Before Banning: The number of tolerated bad requests before considering the client as attempting to hack the server. A request that results in a reply which HTTP status code is 400 or 401 is counted as a bad request. A request that results in a reply which HTTP status code is 403, 404, 405, or 408 is counted as half a bad request.
Monitoring Period: The server considers only the bad requests that are generated by a client during the last Monitoring Period to decide whether to ban it or not. The bigger this parameter is, the more memory the anti-hacking system needs to record all the bad requests.
In other words, the anti-hacking system works as follows: If a client has generated Bad Requests Count Before Banning bad requests during the last Monitoring Period seconds, then ban it for the next Banning Duration seconds. When a client is banned, the server will not accept connections from it.
Note: The server preserves the list of banned clients when it is shutdown. So if a client was banned for 2 hours at 10:00, and if the server was stopped at 10:15 and restarted at 11:00, the server will continue to not accept requests from the banned client until 12:00.
Beside the common log format and the combined log format, Abyss Web Server offers the possibility to define custom logging formats that can be used in the configuration of hosts. Select Logging Parameters in the Server Configuration dialog and use the Custom Logging Formats table to edit, remove or add custom logging formats definitions.
Each format is defined by its name and a list of fields it contains. Fields refer to information from the requests, the responses, or the CGI variables. They can also refer to general information (such as the date and time) or to static text that is to be inserted in each log line.