How are they run?

When the server is asked for a document, it first checks if it is a script. Scripts must belong to one of the script paths or their subpaths, or must match with one of the path patterns listed in the Script Paths table.

Abyss Web Server is able to run standalone CGI or FastCGI executables. These executables can be GUI or non-GUI Windows applications or MS-DOS EXE or COM programs. The Script Paths table must contain explicitly the general patterns /*.exe and/or /*.com (or more path restrictive patterns ending with *.exe and/or *.com) in order to have them executed. Otherwise, the executable files are downloaded to the client browser.

Abyss Web Server can also run standalone ISAPI extensions. The Script Paths table must contain explicitly the virtual path of a module or a matching pattern to have it executed. A file is considered as being an ISAPI module if its file name extension matches one of the declared ISAPI file name extensions.

For other kinds of scripts, the server tries to find the suitable interpreter able to run them by:

If none of these steps is successful, the file is considered as a normal document and will be sent to the browser.

Abyss Web Server automatically detects NPH (Non Parsed Headers) scripts. NPH scripts output is sent directly to the browser without prior header decoding by the server. It is up to NPH scripts to generate correctly all the necessary HTTP response headers. Abyss Web Server considers a script to be NPH if the first line it outputs starts with the string HTTP/.

With the advent of HTTP/2, problems may arise with NPH scripts which carry low-level HTTP/1.0 or HTTP/1.1 protocol details. So it is recommended to disable HTTP/2 for them by adding their virtual paths in the HTTP/1.1 Required table. By default, the mentionned table already contains */nph- pattern which matches with any script which file name starts with nph-. This naming convention was the defacto standard for NPH in legacy Web servers and was enforced by legacy Perl language CGI packages.