## 4 HTTP server

### 4.1 Introduction

The HTTP server, also refered to as httpd, handles HTTP requests as described in RFC 2616 with a few exceptions such as gateway and proxy functionality. (The same is true for servers written by NCSA and others.) The server supports ipv6 as long as the underlying mechanisms also do so.

The server implements numerous features such as SSL (Secure Sockets Layer), ESI (Erlang Scripting Interface), CGI (Common Gateway Interface), User Authentication(using Mnesia, dets or plain text database), Common Logfile Format (with or without disk_log(3) support), URL Aliasing, Action Mappings, Directory Listings and SSI (Server-Side Includes).

The configuration of the server is done using Apache-style configuration directives..

Allmost all server functionality has been implemented using an especially crafted server API, it is described in the Erlang Web Server API. This API can be used to advantage by all who wants to enhance the server core functionality, for example custom logging and authentication.

### 4.2 Basic Configuration

It is possible to start a number of Web servers in an embedded system using the services config parameter from an application config file. A minimal application config file (from now on referred to as inets.config) starting two HTTP servers typically looks as follows:

          [{inets,
          [{services,[{httpd,"/var/tmp/server_root/conf/8888.conf"},
          {httpd,"/var/tmp/server_root/conf/8080.conf"}]}]}].

or:

          [{inets,
          [{services,[{httpd,[{file,"/var/tmp/server_root/conf/8888.conf"}]},
          {httpd,[{file,"/var/tmp/server_root/conf/8080.conf"}]}]}]}].

according to a new syntax which allows more functionality in the configuration. The possible options here are a customer configurable request accept timeout, the default value is 15000 milliseconds, and some trace functionality to debug the http server. The syntax must match the following grammar:

         httpd_service() -> {httpd,httpd()}
         httpd()         -> [httpd_config()] | file()
         httpd_config()  -> {file,file()} ,
                            {debug,debug()} ?,
                            {accept_timeout,integer()} ?
         debug()         -> disable | [debug_options()]
         debug_options() -> {all_functions,modules()} |
                            {exported_functions,modules()} |
                            {disable,modules()}
         modules()       -> [atom()]

{file,file()} corresponds to the functionality of the old version.

{debug,debug()} is the new trace option. It can trace on all functions or only exported functions on choosen modules.

{accept_timeout,integer()} sets the wanted timeout value for the server to set up a request connection.

A server config file is specified for each HTTP server to be started. The server config file syntax and semantics is described in the run time configuration section.

An easy way to test the setup of inets webservers can be done by copying the example server root (UNIX: $INETS_ROOT/examples/server_root/conf/, Windows: %INETS_ROOT%\examples\server_root\conf\) to a specific installation directory (/var/tmp/server_root/conf in this example). Then manualy start the Erlang node, using inets.config.

          $ erl -config ./inets
          Erlang (BEAM) emulator version 4.9

          Eshell V4.9 (abort with ^G) 1> application:start(inets).
          ok

Now there should be two HTTP servers started listening on the ports 8888 and 8080. You can test it by using any browser or the inets HTTP client requesting the urls: http://localhost:8888 and http://localhost:8080

### 4.3 Server Runtime Configuration

All functionality in the server can be configured using Apache-style configuration directives stored in a configuration file. A minimal configuration file could look something like:

          ServerName web.server.net
          ServerRoot /var/tmp/server_root
          DocumentRoot /var/tmp/server_root/htdocs

E.i the syntax is Directive followed by a withspace followed by the value of the directive followed by a new line.

The available directives are described in the section Server Configuration Directives.

### 4.4 Server Configuration Directives

#### 4.4.1 Mandantory Directives

- DIRECTIVE: "ServerName"
  Syntax: `ServerName` fully-qualified domain name
  Default: - Mandatory -
  `ServerName` sets the `fully-qualified domain name` of the server.
- DIRECTIVE: "ServerRoot"
  Syntax: `ServerRoot` directory-filename
  Default: - Mandatory -
  `ServerRoot` defines a `directory-filename` where the server has it's operational home, e.g. used to store log files and system icons. Relative paths specified in the config file refer to this `directory-filename`.
- DIRECTIVE: "DocumentRoot"
  Syntax: `DocumentRoot` directory-filename
  Default: - Mandatory -
  `DocumentRoot` points the Web server to the document space from which to serve documents from. Unless matched by a directive like Alias, the server appends the path from the requested URL to the `DocumentRoot` to make the path to the document, for example:

                  DocumentRoot /usr/web

  and an access to `http://your.server.org/index.html` would refer to `/usr/web/index.html`.

#### 4.4.2 Communication Directives

- DIRECTIVE: "BindAddress"
  Syntax: `BindAddress` address
  Default: `BindAddress *`
  `BindAddress` defines which address the server will listen to. If the argument is * then the server listens to all addresses otherwise the server will only listen to the address specified. Address can be given either as an IP address or a hostname.
- DIRECTIVE: "Port"
  Syntax: `Port` number
  Default: `Port 80`
  `Port` defines which port `number` the server should use (0 to 65535). Certain port numbers are reserved for particular protocols, i.e. examine your OS characteristics (`UNIX: /etc/services, Windows:` ) for a list of reserved ports. The standard port for HTTP is 80.
  All ports numbered below 1024 are reserved for system use and regular (non-root) users cannot use them, i.e. to use port 80 you must start the Erlang node as root. (sic!) If you do not have root access choose an unused port above 1024 typically 8000, 8080 or 8888.
- DIRECTIVE: "SocketType"
  Syntax: `SocketType` type
  Default: `SocketType ip_comm`
  `SocketType` defines which underlying communication `type` to be used. Valid socket types are:
  `ip_comm`
    the default and preferred communication type. ip_comm is also used for all remote message passing in Erlang.
  `ssl`
    the communication type to be used to support SSL.

#### 4.4.3 Limit Directives

- DIRECTIVE: "DisableChunkedTransferEncodingSend"
  Syntax: `DisableChunkedTransferEncodingSend` true | false
  Default: false
  This directive tells the server whether to use chunked transfer-encoding when sending a response to a HTTP/1.1 client.
- DIRECTIVE: "KeepAlive"
  Syntax: `KeepAlive` true | false
  Default: true
  This directive tells the server whether to use persistent connection or not when the client claims to be HTTP/1.1 compliant.Note:the value of KeepAlive has changed from previous versions to be compliant with Apache.
- DIRECTIVE: "KeepAliveTimeout"
  Syntax: `KeepAliveTimeout` seconds
  Default:150
  The number of seconds the server will wait for a subsequent request from the client before closing the connection. If the load on the server is high you may want to shorten this.
- DIRECTIVE: "MaxBodyAction"
  Syntax: `MaxBodyAction` action
  Default: `MaxBodyAction close`
  `MaxBodyAction` specifies the action to be taken when the message body limit has been passed.
  `close`
    the default and preferred communication type. ip_comm is also used for all remote message passing in Erlang.
  `reply414`
    a reply (status) message with code 414 will be sent to the client prior to closing the socket. Note that this code is not defined in the HTTP/1.0 version of the protocol.
- DIRECTIVE: "MaxBodySize"
  Syntax: `MaxBodySize` size
  Default: `MaxBodySize nolimit`
  `MaxBodySize` limits the `size` of the message body of HTTP request. The reply to this is specified by the `MaxBodyAction` directive. Valid size is:
  `nolimit`
    the default message body limit, e.g. no limit.
  `integer()`
    any positive number.
- DIRECTIVE: "MaxClients"
  Syntax: `MaxClients` number
  Default: `MaxClients 150`
  `MaxClients` limits the `number` of simultaneous requests that can be supported. No more than this `number` of child server process's can be created.
- DIRECTIVE: "MaxHeaderAction"
  Syntax: `MaxHeaderAction` action
  Default: `MaxHeaderAction close`
  `MaxHeaderAction` specifies the action to be taken when the message Header limit has been passed.
  `close`
    the socket is closed without any message to the client. This is the default action.
  `reply414`
    a reply (status) message with code 414 will be sent to the client prior to closing the socket. Note that this code is not defined in the HTTP/1.0 version of the protocol.
- DIRECTIVE: "MaxHeaderSize"
  Syntax: `MaxHeaderSize` size
  Default: `MaxHeaderSize 10240`
  `MaxHeaderSize` limits the `size` of the message header of HTTP request. The reply to this is specified by the `MaxHeaderAction` directive. Valid size is:
  `integer()`
    any positive number (default is 10240)
  `nolimit`
    no limit should be applied
- DIRECTIVE: "MaxKeepAliveRequests"
  Syntax: `MaxKeepAliveRequests` NumberOfRequests
  Default:- Disabled -
  The number of request that a client can do on one connection. When the server has responded to the number of requests defined by MaxKeepAliveRequests the server close the connection. The server will close it even if there are queued request.

#### 4.4.4 Administrative Directives

- DIRECTIVE: "DefaultType"
  Syntax: `DefaultType` mime-type
  Default: - None -
  When the server is asked to provide a document type which cannot be determined by the MIME Type Settings, the server must inform the client about the content type of documents and `mime-type` is used if an unknown type is encountered.
- DIRECTIVE: "Modules"
  Syntax: `Modules` module module ...
  Default: `Modules mod_get mod_head mod_log`
  `Modules` defines which Erlang Webserver API modules to be used in a specific server setup. `module` is a module in the code path of the server which has been written in accordance with the section Erlang Web Server API. The server executes functionality in each module, from left to right (from now on called Erlang Webserver API Module Sequence).
  Before altering the Erlang Webserver API Modules Sequence please observe what types of data each module uses and propagates.
- DIRECTIVE: "ServerAdmin"
  Syntax: `ServerAdmin` email-address
  Default: `ServerAdmin unknown@unknown`
  `ServerAdmin` defines the `email-address` of the server administrator, to be included in any error messages returned by the server. It may be worth setting up a dedicated user for this because clients do not always state which server they have comments about, for example:

                  ServerAdmin www-admin@white-house.com

#### 4.4.5 SSL Directives

- DIRECTIVE: "SSLCACertificateFile"
  Syntax: `SSLCACertificateFile` filename
  Default: - None -
  `SSLCACertificateFile` points at a PEM encoded certificate of the certification authorities. Read more about PEM encoded certificates in the SSL application documentation. Read more about PEM encoded certificates in the SSL application documentation.
- DIRECTIVE: "SSLCertificateFile"
  Syntax: `SSLCertificateFile` filename
  Default: - None -
  `SSLCertificateFile` points at a PEM encoded certificate. Read more about PEM encoded certificates in the SSL application documentation. The dummy certificate server.pem (`UNIX: $INETS/examples/server_root/ssl/, Windows: %INETS%\examples\server_root\ssl\`), in the Inets distribution, can be used for test purposes. Read more about PEM encoded certificates in the SSL application documentation.
- DIRECTIVE: "SSLCertificateKeyFile"
  Syntax: `SSLCertificateKeyFile` filename
  Default: - None -
  `SSLCertificateKeyFile` is used to point at a certificate key file. This directive should only be used if a certificate key has not been bundled with the certificate file pointed at by SSLCertificateFile .
- DIRECTIVE: "SSLVerifyClient"
  Syntax: `SSLVerifyClient` type
  Default: - None -
  Set `type` to:
  0
    if no client certificate is required.
  1
    if the client may present a valid certificate.
  2
    if the client must present a valid certificate.
  3
    if the client may present a valid certificate but it is not required to have a valid CA.
  Read more about SSL in the application documentation.
- DIRECTIVE: "SSLVerifyDepth"
  Syntax: `SSLVerifyDepth` integer
  Default: - None -
  This directive specifies how far up or down the (certification) chain we are prepared to go before giving up.
  Read more about SSL in the application documentation.
- DIRECTIVE: "SSLCiphers"
  Syntax: `SSLCiphers` ciphers
  Default: - None -
  `SSLCihers` is a colon separated list of ciphers.
  Read more about SSL in the application documentation.
- DIRECTIVE: "SSLPasswordCallbackFunction"
  Syntax: `SSLPasswordCallbackFunction` function
  Default: - None -
  The `SSLPasswordCallbackFunction` function in module `SSLPasswordCallbackModule` is called in order to retrieve the user's password.
  Read more about SSL in the application documentation.
- DIRECTIVE: "SSLPasswordCallbackModule" Syntax: `SSLPasswordCallbackModule` function
  Default: - None -
  The `SSLPasswordCallbackFunction` function in the `SSLPasswordCallbackModule` module is called in order to retrieve the user's password.
  Read more about SSL in the application documentation.

#### 4.4.6 URL Aliasing

- DIRECTIVE: "Alias"
  Syntax: `Alias` url-path directory-filename
  Default: - None -
  The Alias directive allows documents to be stored in the local file system instead of the DocumentRoot location. URLs with a path that begins with `url-path` is mapped to local files that begins with `directory-filename`, for example:

                  Alias /image /ftp/pub/image

  and an access to `http://your.server.org/image/foo.gif` would refer to the file `/ftp/pub/image/foo.gif`.
- DIRECTIVE: "DirectoryIndex"
  Syntax: `DirectoryIndex` file file ...
  Default: - None -
  `DirectoryIndex` specifies a list of resources to look for if a client requests a directory using a `/` at the end of the directory name. `file` depicts the name of a file in the directory. Several files may be given, in which case the server will return the first it finds, for example:

                  DirectoryIndex index.html

  and access to `http://your.server.org/docs/` would return `http://your.server.org/docs/index.html` if it existed.
- DIRECTIVE: "ScriptAlias"
  Syntax: `ScriptAlias` url-path directory-filename
  Default: - None -
  The ScriptAlias directive has the same behavior as the Alias directive, except that it also marks the target directory as containing CGI scripts. URLs with a path beginning with `url-path` are mapped to scripts beginning with `directory-filename`, for example:

      ScriptAlias /cgi-bin/ /web/cgi-bin/

  and an access to `http://your.server.org/cgi-bin/foo` would cause the server to run the script `/web/cgi-bin/foo`.

#### 4.4.7 CGI Directives

- DIRECTIVE: "ScriptNoCache"
  Syntax: `ScritpNoCache` true | false
  Default: - false -
  If ScriptNoCache is set to true the Web server will by default add the header fields necessary to prevent proxies from caching the page. Generally this is something you want.

                  ScriptNoCache true

- DIRECTIVE: "ScriptTimeout"
  Syntax: `ScritpTimeout` Seconds
  Default: 15
  The time in seconds the web server will wait between each chunk of data from the script. If the CGI-script not delivers any data before the timeout the connection to the client will be closed.

                  ScriptTimeout  15

- DIRECTIVE: "Action"
  Syntax: `Action` mime-type cgi-script
  Default: - None -
  `Action` adds an action, which will activate a `cgi-script` whenever a file of a certain `mime-type` is requested. It propagates the URL and file path of the requested document using the standard CGI `PATH_INFO` and `PATH_TRANSLATED` environment variables.
  Examples:

                  Action text/plain /cgi-bin/log_and_deliver_text
                  Action home-grown/mime-type1 /~bob/do_special_stuff

- DIRECTIVE: "Script"
  Syntax: `Script` method cgi-script
  Default: - None -
  `Script` adds an action, which will activate a `cgi-script` whenever a file is requested using a certain HTTP `method`. The `method` is either `GET` or `POST` as defined in RFC 1945. It propagates the URL and file path of the requested document using the standard CGI `PATH_INFO` and `PATH_TRANSLATED` environment variables.
  Examples:

                  Script GET /cgi-bin/get
                  Script POST /~bob/put_and_a_little_more

#### 4.4.8 ESI Directives

- DIRECTIVE: "ErlScriptAlias"
  Syntax: `ErlScriptAlias` url-path allowed-module allowed-module ...
  Default: - None -
  `ErlScriptAlias` marks all URLs matching `url-path` as erl scheme scripts. A matching URL is mapped into a specific module and function. The module must be one of the `allowed-module`:s. For example:

      ErlScriptAlias /cgi-bin/hit_me httpd_example md4

  and a request to `http://your.server.org/cgi-bin/hit_me/httpd_example:yahoo` would refer to `httpd_example:yahoo/2`.
- DIRECTIVE: "ErlScriptNoCache"
  Syntax: `ErlScriptNoCache` true | false
  Default: false
  If `ErlScriptNoCache` is set to true the server will add http header fields that prevents proxies from caching the page. This is generally a good idea for dynamic content, since the content often vary between each request.

                  ErlScriptNoCache true

- DIRECTIVE: "ErlScriptTimeout"
  Syntax: `ErlScriptTimeout` seconds
  Default: 15
  If `ErlScriptTimeout` sets the time in seconds the server will wait between each chunk of data is delivered through mod_esi:deliver/2 when the new Erl Scheme format, that takes three argument is used.

                  ErlScriptTimeout 15

- DIRECTIVE: "EvalScriptAlias"
  Syntax: `EvalScriptAlias` url-path allowed-module allowed-module ...
  Default: - None -
  `EvalScriptAlias` marks all URLs matching `url-path` as eval scheme scripts. A matching URL is mapped into a specific module and function. The module must be one of the `allowed-module`:s. For example:

       EvalScriptAlias /cgi-bin/hit_me_to httpd_example md5

  and a request to `http://your.server.org/cgi-bin/hit_me_to/httpd_example:print("Hi!")` would refer to `httpd_example:print/1`.

#### 4.4.9 Auth Directives

- DIRECTIVE: "Directory"
  Syntax: `<Directory` regexp-filename`>`
  Default: - None -
  `<Directory>` and </Directory> are used to enclose a group of directives which applies only to the named directory and sub-directories of that directory. `regexp-filename` is an extended regular expression (See `regexp(3)`). For example:

                <Directory /usr/local/httpd[12]/htdocs>
                AuthAccessPassword sOmEpAsSwOrD
                AuthDBType plain
                AuthName My Secret Garden
                AuthUserFile /var/tmp/server_root/auth/user
                AuthGroupFile /var/tmp/server_root/auth/group
                require user ragnar edward
                require group group1
                allow from 123.145.244.5
                </Directory>

  If multiple directory sections match the directory (or its parents), then the directives are applied with the shortest match first. For example if you have one directory section for `garden/` and one for `garden/flowers`, the `garden/` section matches first.
- DIRECTIVE: "AuthDBType"
  Syntax: `AuthDBType` plain | dets | mnesia
  Default: - None -
  Context: Directory
  `AuthDBType` sets the type of authentication database that is used for the directory.The key difference between the different methods is that dynamic data can be saved when Mnesia and Dets is used.
  If Mnesia is used as storage method, Mnesia must be started prio to the webserver. The first time Mnesia is started the schema and the tables must be created before Mnesia is started. A naive example of a module with two functions that creates and start mnesia is provided here. The function shall be sued the first time. `first_start/0` creates the schema and the tables. The second function `start/0` shall be used in consecutive startups. `start/0` Starts Mnesia and wait for the tables to be initiated. This function must only be used when the schema and the tables already is created.

          -module(mnesia_test).
          -export([start/0,load_data/0]).
          -include("mod_auth.hrl").

          first_start()->
               mnesia:create_schema([node()]),
               mnesia:start(),
               mnesia:create_table(httpd_user,
                                   [{type,bag},{disc_copies,[node()]},
                                    {attributes,record_info(fields,httpd_user)}]),
               mnesia:create_table(httpd_group,
                                   [{type,bag},{disc_copies,[node()]},
                                   {attributes,record_info(fields,httpd_group)}]),
               mnesia:wait_for_tables([httpd_user,httpd_group],60000).

          start()->
              mnesia:start(),
              mnesia:wait_for_tables([httpd_user,httpd_group],60000).

  To create the Mnesia tables we use two records defined in mod_auth.hrl so the file must be included.
  The first function `first_start/0` creates a schema that specify on which nodes the database shall reside. Then it starts Mnesia and creates the tables. The first argument is the name of the tables, the second argument is a list of options how the table will be created, see Mnesia documentation for more information. Since the current implementation of the mod_auth_mnesia saves one row for each user the type must be bag.
  When the schema and the tables is created the second function `start/0`shall be used to start Mensia. It starts Mnesia and wait for the tables to be loaded. Mnesia use the directory specified as `mnesia_dir` at startup if specified, otherwise Mnesia use the current directory.
  For security reasons, make sure that the Mnesia tables are stored outside the document tree of the Web server. If it is placed in the directory which it protects, clients will be able to download the tables.
  Only the `dets` and `mnesia` storage methods allow writing of dynamic user data to disk. `plain` is a read only method.
- DIRECTIVE: "AuthUserFile"
  Syntax: `AuthUserFile` filename
  Default: - None -
  Context: Directory
  `AuthUserFile` sets the name of a file which contains the list of users and passwords for user authentication. `filename` can be either absolute or relative to the `ServerRoot`.
  If using the `plain` storage method, this file is a plain text file, where each line contains a user name followed by a colon, followed by the non-encrypted password. The behavior is undefined if user names are duplicated. For example:

              ragnar:s7Xxv7
              edward:wwjau8

  If using the `dets` storage method, the user database is maintained by `dets` and should not be edited by hand. Use the API functions in mod_auth module to create / edit the user database.
  This directive is ignored if using the `mnesia` storage method.
  For security reasons, make sure that the `AuthUserFile` is stored outside the document tree of the Web server. If it is placed in the directory which it protects, clients will be able to download it.
- DIRECTIVE: "AuthGroupFile"
  Syntax: `AuthGroupFile` filename
  Default: - None -
  Context: Directory
  `AuthGroupFile` sets the name of a file which contains the list of user groups for user authentication. `filename` can be either absolute or relative to the `ServerRoot`.
  If you use the `plain` storage method, the group file is a plain text file, where each line contains a group name followed by a colon, followed by the member user names separated by spaces. For example:

                  group1: bob joe ante

  If using the `dets` storage method, the group database is maintained by `dets` and should not be edited by hand. Use the API for mod_auth module to create / edit the group database.
  This directive is ignored if using the `mnesia` storage method.
  For security reasons, make sure that the `AuthGroupFile` is stored outside the document tree of the Web server. If it is placed in the directory which it protects, clients will be able to download it.
- DIRECTIVE: "AuthName"
  Syntax: `AuthName` auth-domain
  Default: - None -
  Context: Directory
  `AuthName` sets the name of the authorization realm (`auth-domain`) for a directory. This string informs the client about which user name and password to use.
- DIRECTIVE: "AuthAccessPassword"
  Syntax: `AuthAccessPassword` password
  Default: NoPassword
  Context: Directory
  If `AuthAccessPassword` is set to other than NoPassword the password is required for all API calls. If the password is set to DummyPassword the password must be changed before any other API calls. To secure the authenticating data the password must be changed after the webserver is started since it otherwise is written in clear text in the configuration file.
- DIRECTIVE: "allow"
  Syntax: `allow from` host host ...
  Default: `allow from all`
  Context: Directory
  `allow` defines a set of hosts which should be granted access to a given directory. `host` is one of the following:
  `all`
    All hosts are allowed access.
  A regular expression (Read `regexp(3)`)
    All hosts having a numerical IP address matching the specific regular expression are allowed access.
  For example:

                  allow from 123.34.56.11 150.100.23

  The host 123.34.56.11 and all machines on the 150.100.23 subnet are allowed access.
- DIRECTIVE: "deny"
  Syntax: `deny from` host host ...
  Default: `deny from all`
  Context: Directory
  `deny` defines a set of hosts which should not be granted access to a given directory. `host` is one of the following:
  `all`
    All hosts are denied access.
  A regular expression (Read `regexp(3)`)
    All hosts having a numerical IP address matching the specific regular expression are denied access.
  For example:

                  deny from 123.34.56.11 150.100.23

  The host 123.34.56.11 and all machines on the 150.100.23 subnet are denied access.
- DIRECTIVE: "require"
  Syntax: `require` entity-name entity entity ...
  Default: - None -
  Context: Directory
  `require` defines users which should be granted access to a given directory using a secret password. The allowed syntaxes are:
  `require user user-name user-name ...`
    Only the named users can access the directory.
  `require group group-name group-name ...`
    Only users in the named groups can access the directory.

#### 4.4.10 Htacess Authentication Directives

- DIRECTIVE: "AccessFileName" Syntax: `AccessFileName` `FileName1 FileName2`
  Default: .htaccess
  `AccessFileName` Specify which filenames that are used for access-files. When a request comes every directory in the path to the requested asset will be searched after files with the names specified by this parameter. If such a file is found the file will be parsed and the restrictions specified in it will be applied to the request.

#### 4.4.11 Auth Filter Directives

- DIRECTIVE: "SecurityDataFile"
  Syntax: `SecurityDataFile` filename
  Default: - None -
  Context: Directory
  `SecurityDataFile` sets the name of the security modules for a directory. The filename can be either absolute or relative to the `ServerRoot`. This file is used to store persistent data for the mod_security module.
  Several directories can have the same `SecurityDataFile`.
- DIRECTIVE: "SecurityMaxRetries"
  Syntax: `SecurityMaxRetries` integer() | infinity
  Default: 3
  Context:
  `SecurityMaxRetries` specifies the maximum number of tries to authenticate a user has before he is blocked out. If a user successfully authenticates when he is blocked, he will receive a 403 (Forbidden) response from the server.
  For security reasons, failed authentications made by this user will return a message 401 (Unauthorized), even if the user is blocked.
- DIRECTIVE: "SecurityBlockTime"
  Syntax: `SecurityBlockTime` integer() | infinity
  Default: 60
  Context: Directory
  `SecurityBlockTime` specifies the number of minutes a user is blocked. After this amount of time, he automatically regains access.
- DIRECTIVE: "SecurityFailExpireTime"
  Syntax: `SecurityFailExpireTime` integer() | infinity
  Default: 30
  Context: Directory
  `SecurityFailExpireTime` specifies the number of minutes a failed user authentication is remembered. If a user authenticates after this amount of time, his previous failed authentications are forgotten.
- DIRECTIVE: "SecurityAuthTimeout"
  Syntax: `SecurityAuthTimeout` integer() | infinity
  Default: 30
  Context: Directory
  `SecurityAuthTimeout` specifies the number of seconds a successful user authentication is remembered. After this time has passed, the authentication will no longer be reported.
- DIRECTIVE: "SecurityCallbackModule"
  Syntax: `SecurityCallbackModule` atom()
  Default: - None -
  Context: Directory
  `SecurityCallbackModule` specifies the name of a callback module.

#### 4.4.12 Logging Directives

- DIRECTIVE: "ErrorLog"
  Syntax: `ErrorLog` filename
  Default: - None -
  `ErrorLog` defines the `filename` of the error log file to be used to log server errors. If the `filename` does not begin with a slash (`/`) it is assumed to be relative to the ServerRoot, for example:

                  ErrorLog logs/error_log_8080

  and errors will be logged in the server root (`UNIX: $SERVER_ROOT/logs/error_log_8080, Windows: %SERVER_ROOT%\logs\error_log_8080`) space.
- DIRECTIVE: "SecurityLog"
  Syntax: `SecurityLog` filename
  Default: - None -
  `SecurityLog` defines the `filename` of the access log file to be used to log security events. If the `filename` does not begin with a slash (`/`) it is assumed to be relative to the ServerRoot. For example:

                  SecurityLog logs/security_log_8080

  and security events will be logged in the server root (`UNIX: $SERVER_ROOT/logs/security_log_8080, Windows: %SERVER_ROOT%\logs\security_log_8080`) space.
- DIRECTIVE: "TransferLog"
  Syntax: `TransferLog` filename
  Default: - None -
  `TransferLog` defines the `filename` of the access log file to be used to log incoming requests. If the `filename` does not begin with a slash (`/`) it is assumed to be relative to the ServerRoot. For example:

                  TransferLog logs/access_log_8080

  and errors will be logged in the server root (`UNIX: $SERVER_ROOT/logs/access_log_8080, Windows: %SERVER_ROOT%\logs\access_log_8080`) space.

#### 4.4.13 Disk Log Directives

- DIRECTIVE: "DiskLogFormat"
  Syntax: `DiskLogFormat` internal|external
  Default: - external -
  `DiskLogFormat` defines the file-format of the log files see disk_log for more information. If the internal file-format is used, the logfile will be repaired after a crash. When a log file is repaired data might get lost. When the external file-format is used httpd will not start if the log file is broken.

                DiskLogFormat external

- DIRECTIVE: "ErrorDiskLog"
  Syntax: `ErrorDiskLog` filename
  Default: - None -
  `ErrorDiskLog` defines the `filename` of the `(disk_log(3))` error log file to be used to log server errors. If the `filename` does not begin with a slash (`/`) it is assumed to be relative to the ServerRoot, for example:

                ErrorDiskLog logs/error_disk_log_8080

  and errors will be logged in the server root (`UNIX: $SERVER_ROOT/logs/error_disk_log_8080, Windows: %SERVER_ROOT%\logs\error_disk_log_8080`) space.
- DIRECTIVE: "ErrorDiskLogSize"
  Syntax: `ErrorDiskLogSize` max-bytes max-files
  Default: `ErrorDiskLogSize 512000 8`
  `ErrorDiskLogSize` defines the properties of the `(disk_log(3))` error log file. The `disk_log(3)` error log file is of type wrap log and `max-bytes` will be written to each file and `max-files` will be used before the first file is truncated and reused.
- DIRECTIVE: "SecurityDiskLog"
  Syntax: `SecurityDiskLog` filename
  Default: - None -
  `SecurityDiskLog` defines the `filename` of the `(disk_log(3))` access log file which logs incoming security events i.e authenticated requests. If the `filename` does not begin with a slash (`/`) it is assumed to be relative to the ServerRoot.
- DIRECTIVE: "SecurityDiskLogSize"
  Syntax: `SecurityDiskLogSize` max-bytes max-files
  Default: `SecurityDiskLogSize 512000 8`
  `SecurityDiskLogSize` defines the properties of the `disk_log(3)` access log file. The `disk_log(3)` access log file is of type wrap log and `max-bytes` will be written to each file and `max-files` will be used before the first file is truncated and reused.
- DIRECTIVE: "TransferDiskLog"
  Syntax: `TransferDiskLog` filename
  Default: - None -
  `TransferDiskLog` defines the `filename` of the `(disk_log(3))` access log file which logs incoming requests. If the `filename` does not begin with a slash (`/`) it is assumed to be relative to the ServerRoot, for example:

                TransferDiskLog logs/transfer_disk_log_8080

  and errors will be logged in the server root (`UNIX: $SERVER_ROOT/logs/transfer_disk_log_8080, Windows: %SERVER_ROOT%\logs\transfer_disk_log_8080`) space.
- DIRECTIVE: "TransferDiskLogSize"
  Syntax: `TransferDiskLogSize` max-bytes max-files
  Default: `TransferDiskLogSize 512000 8`
  `TransferDiskLogSize` defines the properties of the `disk_log(3)` access log file. The `disk_log(3)` access log file is of type wrap log and `max-bytes` will be written to each file and `max-files` will be used before the first file is truncated and reused.

### 4.5 Mime Type Configuration

Files delivered to the client are MIME typed according to RFC 1590. File suffixes are mapped to MIME types before file delivery.

The mapping between file suffixes and MIME types are specified in the mime.types file. The mime.types reside within the conf directory of the ServerRoot. MIME types may be added as required to the mime.types file and the DefaultType config directive can be used to specify a default mime type. An example of a very small mime.types file:

        # MIME type                 Extension
        text/html                   html htm
        text/plain                  asc txt

### 4.6 Htaccess - User Configurable Authentication.

If users of the webserver needs to manage authentication of webpages that are local to their user and do not have server administrative privileges. They can use the per-directory runtime configurable user-authentication scheme that Inets calls htaccess. It works the following way:

- Each directory in the path to the requested asset is searched for an access-file (default .htaccess), that restricts the webservers rights to respond to a request. If an access-file is found the rules in that file is applied to the request.
- The rules in an access-file applies both to files in the same directories and in subdirectories. If there exists more than one access-file in the path to an asset, the rules in the access-file nearest the requested asset will be applied.
- To change the rules that restricts the use of an asset. The user only needs to have write access to the directory where the asset exists.
- All the access-files in the path to a requested asset is read once per request, this means that the load on the server will increase when this scheme is used.
- If a directory is limited both by auth directives in the HTTP server configuration file and by the htaccess files. The user must be allowed to get access the file by both methods for the request to succed.

#### 4.6.1 Access Files Directives

In every directory under the `DocumentRoot` or under an `Alias` a user can place an access-file. An access-file is a plain text file that specify the restrictions that shall be considered before the webserver answer to a request. If there are more than one access-file in the path to the requested asset, the directives in the access-file in the directory nearest the asset will be used.

- DIRECTIVE: "allow" Syntax: `Allow` from subnet subnet|from all
  Default: `from all`
  Same as the directive allow for the server config file.
- DIRECTIVE: "AllowOverRide" Syntax: `AllowOverRide` all | none | Directives
  Default: `- None -`
  `AllowOverRide` Specify which parameters that not access-files in subdirectories are allowed to alter the value for. If the parameter is set to none no more access-files will be parsed.
  If only one access-file exists setting this parameter to none can lessen the burden on the server since the server will stop looking for access-files.
- DIRECTIVE: "AuthGroupfile" Syntax: `AuthGroupFile` Filename
  Default: `- None -`
  AuthGroupFile indicates which file that contains the list of groups. Filename must contain the absolute path to the file. The format of the file is one group per row and every row contains the name of the group and the members of the group separated by a space, for example:

                  GroupName: Member1 Member2 .... MemberN

- DIRECTIVE: "AuthName" Syntax: `AuthName` auth-domain
  Default: `- None -`
  Same as the directive AuthName for the server config file.
- DIRECTIVE: "AuthType" Syntax: `AuthType` Basic
  Default: `Basic`
  `AuthType` Specify which authentication scheme that shall be used. Today only Basic Authenticating using UUEncoding of the password and user ID is implemented.
- DIRECTIVE: "AuthUserFile" Syntax: `AuthUserFile` Filename
  Default: `- None -`
  `AuthUserFile` indicate which file that contains the list of users. Filename must contain the absolute path to the file. The users name and password are not encrypted so do not place the file with users in a directory that is accessible via the webserver. The format of the file is one user per row and every row contains User Name and Password separated by a colon, for example:

                  UserName:Password
                  UserName:Password

- DIRECTIVE: "deny" Syntax: `deny` from subnet subnet|from all
  Context: Limit
  Same as the directive deny for the server config file.
- DIRECTIVE: "Limit"
  Syntax: `<Limit` RequestMethods`>`
  Default: - None -
  `<Limit>` and </Limit> are used to enclose a group of directives which applies only to requests using the specified methods. If no request method is specified all request methods are verified against the restrictions.

                  <Limit POST GET HEAD>
                  order allow deny
                  require group group1
                  allow from 123.145.244.5
                  </Limit>

- DIRECTIVE: "order"
  Syntax: `order` allow deny | deny allow
  Default: allow deny
  `order`, defines if the deny or allow control shall be preformed first.
  If the order is set to allow deny, then first the users network address is controlled to be in the allow subset. If the users network address is not in the allowed subset he will be denied to get the asset. If the network-address is in the allowed subset then a second control will be preformed, that the users network address is not in the subset of network addresses that shall be denied as specified by the deny parameter.
  If the order is set to deny allow then only users from networks specified to be in the allowed subset will succeed to request assets in the limited area.
- DIRECTIVE: "require" Syntax: `require` group group1 group2...|user user1 user2...
  Default: `- None -`
  Context: Limit
  See the require directive in the documentation of mod_auth(3) for more information.

### 4.7 Dynamic Web Pages

The Inets HTTP server provides two ways of creating dynamic web pages, each with its own advantages and disadvantages.

First there are CGI-scripts that can be written in any programming language. CGI-scripts are standardized and supported by most webservers. The drawback with CGI-scripts is that they are resource intensive because of their design. CGI requires the server to fork a new OS process for each executable it needs to start.

Second there are ESI-functions that provide a tight and efficient interface to the execution of Erlang functions, this interface on the other hand is Inets specific.

#### 4.7.1 The Common Gateway Interface (CGI) Version 1.1, RFC 3875.

The mod_cgi module makes it possible to execute CGI scripts in the server. A file that matches the definition of a ScriptAlias config directive is treated as a CGI script. A CGI script is executed by the server and it's output is returned to the client.

The CGI Script response comprises a message-header and a message-body, separated by a blank line. The message-header contains one or more header fields. The body may be empty. Example:

    "Content-Type:text/plain\nAccept-Ranges:none\n\nsome very
            plain text"

The server will interpret the cgi-headers and most of them will be transformed into HTTP headers and sent back to the client together with the body.

Support for CGI-1.1 is implemented in accordance with the RFC 3875.

#### 4.7.2 Erlang Server Interface (ESI)

The erlang server interface is implemented by the module mod_esi.

##### 4.7.2.1 ERL Scheme

The erl scheme is designed to mimic plain CGI, but without the extra overhead. An URL which calls an Erlang erl function has the following syntax (regular expression):

              http://your.server.org/***/Module[:/]Function(?QueryString|/PathInfo)

*** above depends on how the ErlScriptAlias config directive has been used

The module (Module) referred to must be found in the code path, and it must define a function (Function) with an arity of two or three. It is preferable to implement a funtion with arity three as it permitts you to send chunks of the webpage beeing generated to the client during the generation phase instead of first generating the whole web page and then sending it to the client. The option to implement a function with arity two is only keept for backwardcompatibilty reasons. See mod_esi(3) for implementation details of the esi callback function.

##### 4.7.2.2 EVAL Scheme

The eval scheme is straight-forward and does not mimic the behavior of plain CGI. An URL which calls an Erlang eval function has the following syntax:

    http://your.server.org/***/Mod:Func(Arg1,...,ArgN)

*** above depends on how the ErlScriptAlias config directive has been used

The module (Mod) referred to must be found in the code path, and data returned by the function (Func) is passed back to the client. Data returned from the function must furthermore take the form as specified in the CGI specification. See mod_esi(3) for implementation details of the esi callback function.

| The eval scheme can seriously threaten the integrity of the Erlang node housing a Web server, for example:
    http://your.server.org/eval?httpd_example:print(atom_to_list(apply(erlang,halt,[])))
which effectively will close down the Erlang node, that is use the erl scheme instead, until this security breach has been fixed. Today there are no good way of solving this problem and therefore Eval Scheme may be removed in future release of Inets.

### 4.8 Logging

There are three types of logs supported. Transfer logs, security logs and error logs. The de-facto standard Common Logfile Format is used for the transfer and security logging. There are numerous statistics programs available to analyze Common Logfile Format. The Common Logfile Format looks as follows:

remotehost rfc931 authuser [date] "request" status bytes

remotehost
  Remote hostname
rfc931
  The client's remote username (RFC 931).
authuser
  The username with which the user authenticated himself.
[date]
  Date and time of the request (RFC 1123).
"request"
  The request line exactly as it came from the client (RFC 1945).
status
  The HTTP status code returned to the client (RFC 1945).
bytes
  The content-length of the document transferred.

Internal server errors are recorde in the error log file. The format of this file is a more ad hoc format than the logs using Common Logfile Format, but conforms to the following syntax:

[date] access to path failed for remotehost, reason: reason

### 4.9 Server Side Includes

Server Side Includes enables the server to run code embedded in HTML pages to generate the response to the client.

| Having the server parse HTML pages is a double edged sword! It can be costly for a heavily loaded server to perform parsing of HTML pages while sending them. Furthermore, it can be considered a security risk to have average users executing commands in the name of the Erlang node user. Carefully consider these items before activating server-side includes.

#### 4.9.1 SERVER-SIDE INCLUDES (SSI) SETUP

The server must be told which filename extensions to be used for the parsed files. These files, while very similar to HTML, are not HTML and are thus not treated the same. Internally, the server uses the magic MIME type `text/x-server-parsed-html` to identify parsed documents. It will then perform a format conversion to change these files into HTML for the client. Update the `mime.types` file, as described in the Mime Type Settings, to tell the server which extension to use for parsed files, for example:

            text/x-server-parsed-html shtml shtm

This makes files ending with `.shtml` and `.shtm` into parsed files. Alternatively, if the performance hit is not a problem, all HTML pages can be marked as parsed:

            text/x-server-parsed-html html htm

#### 4.9.2 Server-Side Includes (SSI) Format

All server-side include directives to the server are formatted as SGML comments within the HTML page. This is in case the document should ever find itself in the client's hands unparsed. Each directive has the following format:

            <!--#command tag1="value1" tag2="value2" -->

Each command takes different arguments, most only accept one tag at a time. Here is a breakdown of the commands and their associated tags:

`config`
  The config directive controls various aspects of the file parsing. There are two valid tags:
  `errmsg`
    controls the message sent back to the client if an error occurred while parsing the document. All errors are logged in the server's error log.
  `sizefmt`
    determines the format used to display the size of a file. Valid choices are `bytes` or `abbrev`. `bytes` for a formatted byte count or `abbrev` for an abbreviated version displaying the number of kilobytes.
`include`
  will insert the text of a document into the parsed document. This command accepts two tags:
  `virtual`
    gives a virtual path to a document on the server. Only normal files and other parsed documents can be accessed in this way.
  `file`
    gives a pathname relative to the current directory. `../` cannot be used in this pathname, nor can absolute paths. As above, you can send other parsed documents, but you cannot send CGI scripts.
`echo`
  prints the value of one of the include variables (defined below). The only valid tag to this command is `var`, whose value is the name of the variable you wish to echo.
`fsize`
  prints the size of the specified file. Valid tags are the same as with the `include` command. The resulting format of this command is subject to the `sizefmt` parameter to the `config` command.
`flastmod`
  prints the last modification date of the specified file. Valid tags are the same as with the `include` command.
`exec`
  executes a given shell command or CGI script. Valid tags are:
  `cmd`
    executes the given string using `/bin/sh`. All of the variables defined below are defined, and can be used in the command.
  `cgi`
    executes the given virtual path to a CGI script and includes its output. The server does not perform error checking on the script output.

#### 4.9.3 Server-Side Includes (SSI) Environment Variables

A number of variables are made available to parsed documents. In addition to the CGI variable set, the following variables are made available:

`DOCUMENT_NAME`
  The current filename.
`DOCUMENT_URI`
  The virtual path to this document (such as `/docs/tutorials/foo.shtml`).
`QUERY_STRING_UNESCAPED`
  The unescaped version of any search query the client sent, with all shell-special characters escaped with `\`.
`DATE_LOCAL`
  The current date, local time zone.
`DATE_GMT`
  Same as DATE_LOCAL but in Greenwich mean time.
`LAST_MODIFIED`
  The last modification date of the current document.

### 4.10 The Erlang Webserver API

The process of handling a HTTP request involves several steps such as:

- Seting up connections, sending and receiving data.
- URI to filename translation
- Authenication/access cheks.
- Retriving/generating the response.
- Logging

To provide customization and extensibility of the HTTP servers request handling most of these steps are handled by one or more modules that may be replaced or removed at runtime, and ofcourse new ones can be added. For each request all modules will be traversed in the order specified by the modules directive in the server configuration file. Some parts mainly the communication related steps are considered server core functionallity and are not implemented using the Erlang Webserver API. A description of functionality implemented by the Erlang Webserver API is described in the section Inets Webserver Modules.

A module can use data generated by previous modules in the Erlang Webserver API module sequence or generate data to be used by consecutive Erlang Webserver API modules. This is made possible due to an internal list of key-value tuples, also refered to as interaction data.

| Interaction data enforces module dependencies and should be avoided if possible. This means the order of modules in the Modules config directive is significant.

#### 4.10.1 API Description

Each module implements server functionality using the Erlang Webserver API should implement the following call back functions:

- do/1 (mandatory) - the function called when a request should be handled.
- load/2
- store/2
- remove/1

The latter functions are needed only when new config directives are to be introduced. For details see httpd(3)

### 4.11 Inets Webserver Modules

The convention is that all modules implementing some webserver functionallity has the name mod_*. When configuring the webserver an appropriate selection of these modules should be present in the Module directve. Please note that there are some interaction dependencies to take into account so the order of the modules can not be totally random.

#### 4.11.1 mod_action - Filetype/Method-Based Script Execution.

Runs CGI scripts whenever a file of a certain type or HTTP method (See RFC 1945) is requested.

Uses the following Erlang Webserver API interaction data, if available:

- real_name - from mod_alias

Exports the following Erlang Webserver API interaction data, if possible:

`{new_request_uri, RequestURI}`
  An alternative `RequestURI` has been generated.

#### 4.11.2 mod_alias - URL Aliasing

This module makes it possible to map different parts of the host file system into the document tree e.i. creates aliases and redirections.

Exports the following Erlang Webserver API interaction data, if possible:

`{real_name, PathData}`
  PathData is the argument used for API function mod_alias:path/3.

#### 4.11.3 mod_auth - User Authentication

This module provides for basic user authentication using textual files, dets databases as well as mnesia databases.

Uses the following Erlang Webserver API interaction data, if available:

- real_name - from mod_alias

Exports the following Erlang Webserver API interaction data, if possible:

`{remote_user, User}`
  The user name with which the user has authenticated himself.

#### 4.11.4 mod_cgi - CGI Scripts

This module handles invoking of CGI scripts

#### 4.11.5 mod_dir - Directories

This module generates an HTML directory listing (Apache-style) if a client sends a request for a directory instead of a file. This module needs to be removed from the Modules config directive if directory listings is unwanted.

Uses the following Erlang Webserver API interaction data, if available:

- real_name - from mod_alias

Exports the following Erlang Webserver API interaction data, if possible:

`{mime_type, MimeType}`
  The file suffix of the incoming URL mapped into a `MimeType`.

#### 4.11.6 mod_disk_log - Logging Using disk_log.

Standard logging using the "Common Logfile Format" and disk_log(3).

Uses the following Erlang Webserver API interaction data, if available:

- remote_user - from mod_auth

#### 4.11.7 mod_esi - Erlang Server Interface

This module implements the Erlang Server Interface (ESI) that provides a tight and efficient interface to the execution of Erlang functions.

Uses the following Erlang Webserver API interaction data, if available:

- remote_user - from mod_auth

Exports the following Erlang Webserver API interaction data, if possible:

`{mime_type, MimeType}`
  The file suffix of the incoming URL mapped into a `MimeType`

#### 4.11.8 mod_get - Regular GET Requests

This module is responsible for handling GET requests to regular files. GET requests for parts of files is handled by mod_range.

Uses the following Erlang Webserver API interaction data, if available:

- real_name - from mod_alias

#### 4.11.9 mod_head - Regular HEAD Requests

This module is responsible for handling HEAD requests to regular files. HEAD requests for dynamic content is handled by each module responsible for dynamic content.

Uses the following Erlang Webserver API interaction data, if available:

- real_name - from mod_alias

#### 4.11.10 mod_htacess - User Configurable Access

This module provides per-directory user configurable access control.

Uses the following Erlang Webserver API interaction data, if available:

- real_name - from mod_alias

Exports the following Erlang Webserver API interaction data, if possible:

`{remote_user_name, User}`
  The user name with which the user has authenticated himself.

#### 4.11.11 mod_include - SSI

This module makes it possible to expand "macros" embedded in HTML pages before they are delivered to the client, that is Server-Side Includes (SSI).

Uses the following Erlang Webserver API interaction data, if available:

- real_name - from mod_alias
- remote_user - from mod_auth

Exports the following Erlang Webserver API interaction data, if possible:

`{mime_type, MimeType}`
  The file suffix of the incoming URL mapped into a `MimeType` as defined in the Mime Type Settings section.

#### 4.11.12 mod_log - Logging Using Text Files.

Standard logging using the "Common Logfile Format" and text files.

Uses the following Erlang Webserver API interaction data, if available:

- remote_user - from mod_auth

#### 4.11.13 mod_range - Requests with Range Headers

This module response to requests for one or many ranges of a file. This is especially useful when downloading large files, since a broken download may be resumed.

Note that request for multiple parts of a document will report a size of zero to the log file.

Uses the following Erlang Webserver API interaction data, if available:

- real_name - from mod_alias

#### 4.11.14 mod_response_control - Requests with If* Headers

This module controls that the conditions in the requests is fullfilled. For example a request may specify that the answer only is of interest if the content is unchanged since last retrieval. Or if the content is changed the range-request shall be converted to a request for the whole file instead.

If a client sends more then one of the header fields that restricts the servers right to respond, the standard does not specify how this shall be handled. httpd will control each field in the following order and if one of the fields not match the current state the request will be rejected with a proper response.
1.If-modified
2.If-Unmodified
3.If-Match
4.If-Nomatch

Uses the following Erlang Webserver API interaction data, if available:

- real_name - from mod_alias

Exports the following Erlang Webserver API interaction data, if possible:

`{if_range, send_file}`
  The conditions for the range request was not fullfilled. The response must not be treated as a range request, instead it must be treated as a ordinary get request.

#### 4.11.15 mod_security - Security Filter

This module serves as a filter for authenticated requests handled in mod_auth. It provides possibility to restrict users from access for a specified amount of time if they fail to authenticate several times. It logs failed authentication as well as blocking of users, and it also calls a configurable call-back module when the events occur.

There is also an API to manually block, unblock and list blocked users or users, who have been authenticated within a configurable amount of time.

#### 4.11.16 mod_trace - TRACE Request

mod_trace is responsible for handling of TRACE requests. Trace is a new request method in HTTP/1.1. The intended use of trace requests is for testing. The body of the trace response is the request message that the responding Web server or proxy received.

Copyright © 1991-2006 Ericsson AB