Home   Info   Documentation   Installation   Configuration   History   Download   Mailing list   Feedback 

HTTP request processing in fhttpd

1. When HTTP request arrives, it is received and parsed in the main process. First line of request is parsed, "query" part separated from the path, and URL-encoding is applied to the path.

2. If the last character is a slash, flag "trailing slash" is set for request.

3. If anonymous user is not defined, 403 Forbidden is returned, and request processing is finished

4. Parameters for URL to filename translation are initialized, "/" is mapped according to AddressRoot configuration line that corresponds to the local IP address, or, if there is no such line, the home directory of the anonymous user. Pathname from URL is translated first time to the absolute pathname by prepending that directory and slash. This translation can be overridden later.

HTTP 1.x HTTP 0.9

5a. If HTTP 1.x is used by the client, request header lines are received. Every line of request header is passed through the following process:

  • If-Modified-Since is parsed as time and used in the form of integer. [Abs]GetRule processing doesn't apply to the If-Modified-Since header line.
  • Authorization has any meaning only if the type is Basic -- the username and password are converted to plain text, and also aren't used in [Abs]GetRule processing.
  • Accept is taken as-is.
  • User-Agent is taken as-is.
  • Content-Length is converted to integer and used internally.
  • Connection, if has value Keep-Alive, enables keep-alive mode.

Header lines are matched with [Abs]GetRule lines, and results of matching are placed in the order of matched rules. AbsGetRule and GetRule matches are placed in the same sequence. Replacements of BASEDIR ("/" mapping) and NAME (relative pathname) are performed according to the last rule in each category.

5b. If HTTP 0.9 is used by the client, processing of rules is performed with no header lines because HTTP 0.9 has no header. Rules may redirect names and mappings, and further processing will be done with the result of this processing. rules are applied like in the case of HTTP 1.x request, however there are no header lines, so only UNCONDITIONAL rules are used.

6a. If HTTP 1.x is used by the client, access rights are checked. Only AccessRights lines with masks that match with absolute pathname are used.

  • If AccessRights defines "restrict" rule, access is not allowed.
  • If AccessRights defines "allow" rule, access is allowed.
  • If username and password supplied in Authorization: Basic header line match with username and password in realm, defined in AccessRights, access is allowed.
  • If AccessRights has ":all:" as username, and password supplied in Authorization: Basic header line matches with password for the same username in realm, defined in AccessRights, access is allowed.
  • If there is no Authorization: Basic header line in the header, or username from header isn't present in the realm, defined in AccessRealm, access isn't changed.
This means that explicit "restrict" line is required to define all sets of URLs that have any restrictions, and if the same username with different passwords will appear in different realms, URLs that have AccessRights for multiple realms with the same username will be accessible only to the user in the realm, mentioned last in the configuration.

6b. If HTTP 0.9 is used by the client, access rights are checked because HTTP 0.9 doesn't support authentication. If ANY restriction exists (anything but "allow" line last in the list, 403 Forbidden is returned (in the text of response because HTTP 0.9 responses don't have a header).

7. Absolute pathname is checked against the list of preloaded files. If absolute pathname matches and either trailing slash matches with trailing slash flag, set for preloaded file, or check for trailing slash is disabled by "-" in the configuration line as a filename, preloaded file is used. If absolute pathname matches, trailing slash is present in the request but trailing slash flag is not set for the preloaded file, 404 Not Found is returned (in normal HTTP 1.0 response for HTTP 1.x request, or in the text of response for HTTP 0.9 because HTTP 0.9 responses don't have a header). If absolute pathname matches and trailing slash is not present in the request, but trailing slash flag is set for the preloaded file, the response is 302 Moved Temporarily with redirection to the same URL with trailing slash. It's normal HTTP 1.0 response for HTTP 1.x request or text

Directory
This directory is located here

with a link to the same file with trailing slash for HTTP 0.9 request because HTTP 0.9 does not support redirects.

8. If no other response is produced, [Auth]Application mapping is used at this point. If absolute pathname matches and either trailing slash matches with trailing slash flag, set for application, or check for trailing slash is disabled by "-" in the configuration line as a filename, application is used. If absolute pathname matches, trailing slash is present in the request but trailing slash flag is not set for the application, 404 Not Found is returned (in normal HTTP 1.0 response for HTTP 1.x request, or in the text of response for HTTP 0.9 because HTTP 0.9 responses don't have a header). If absolute pathname matches and trailing slash is not present in the request, but trailing slash flag is set for the preloaded file, the response is 302 Moved Temporarily with redirection to the same URL with trailing slash. It's normal HTTP 1.0 response for HTTP 1.x request or text

Directory
This directory is located here

with a link to the same file with trailing slash for HTTP 0.9 request because HTTP 0.9 does not support redirects.

If there is no matching application, 404 Not Found is returned, and processing is finished.

9. If application is chosen, request is passed to module process that implements this application.

Alex Belits
Last modified: Wed Jun 23 03:32:13 PDT 1999
 Home   Info   Documentation   Installation   Configuration   History   Download   Mailing list   Feedback