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 executable files (files which executable attribute is set using the command chmod +x <File>; see chmod reference in your system's manual). For other kinds of scripts, the server tries to find the suitable interpreter to run them by checking the Interpreters table and matching the script's extension with a declared interpreter.

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.

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.