File: http_server.html

package info (click to toggle)
erlang-doc-html 1%3A11.b.2-1
links: PTS
area: main
in suites: etch, etch-m68k
size: 23,284 kB
ctags: 10,724
sloc: erlang: 505; ansic: 323; makefile: 62; perl: 61; sh: 45
file content (3447 lines) | stat: -rw-r--r-- 85,984 bytes
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<!-- This document was generated using DocBuilder 3.3.3 -->
<HTML>
<HEAD>
  <TITLE>HTTP server </TITLE>
  <SCRIPT type="text/javascript" src="../../../../doc/erlresolvelinks.js">
</SCRIPT>
</HEAD>
<BODY BGCOLOR="#FFFFFF" TEXT="#000000" LINK="#0000FF" VLINK="#FF00FF"
      ALINK="#FF0000">
<CENTER>
<A HREF="http://www.erlang.se"><IMG BORDER=0 ALT="[Ericsson AB]" SRC="min_head.gif"></A>
</CENTER>
<A NAME="4"><!-- Empty --></A>
<H2>4 HTTP server </H2>
<A NAME="4.1"><!-- Empty --></A>
<H3>4.1 Introduction</H3>

<P>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.
<P>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).
<P>The configuration of the server is done using Apache-style
configuration directives..
<P>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.<A NAME="4.2"><!-- Empty --></A>
<H3>4.2 Basic Configuration</H3>

<P>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:
<PRE>
      [{inets,
        [{services, [{httpd, &#34;/var/tmp/server_root/conf/8888.conf&#34;},
                     {httpd, &#34;/var/tmp/server_root/conf/8080.conf&#34;}]
         }
        ]
       }
      ].
      
</PRE>

<P> or:
<PRE>
      [{inets,
        [{services, [{httpd, [{file,&#34;/var/tmp/server_root/conf/8888.conf&#34;}]},
                     {httpd, [{file,&#34;/var/tmp/server_root/conf/8080.conf&#34;}]}]
         }
        ]
       }
      ].
      
</PRE>

<P>According to the 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:
<PRE>
     httpd_service() -&#62; {httpd, httpd()}
     httpd()         -&#62; [httpd_config()] | file()
     httpd_config()  -&#62; {file, file()} | 
                        {debug, debug()} |
                        {accept_timeout, integer()}
     debug()         -&#62; disable | [debug_options()]
     debug_options() -&#62; {all_functions, modules()} | 
                        {exported_functions, modules()} |
                        {disable, modules()}
     modules()       -&#62; [atom()]
     
</PRE>

<P>{file, file()} corresponds to the functionality of the old
version.
<P>{debug, debug()} is the new trace option. It can trace on all
functions or only exported functions on choosen modules.
<P>{accept_timeout, integer()} sets the wanted timeout value for
the server to set up a request connection.
<P>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.
<P>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.
<PRE>
      $ erl -config ./inets
      Erlang (BEAM) emulator version 4.9
      
      Eshell V4.9 (abort with ^G) 1&#62; application:start(inets).
      ok
     
</PRE>

<P>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<A NAME="4.3"><!-- Empty --></A>
<H3>4.3 Server Runtime Configuration</H3>

<P>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: 
<PRE>
      ServerName web.server.net
      ServerRoot /var/tmp/server_root
      DocumentRoot /var/tmp/server_root/htdocs
    
</PRE>

<P>E.i the syntax is Directive followed by a withspace followed by
the value of the directive followed by a new line.
<P>The available directives are described in the section Server
Configuration Directives.<A NAME="4.4"><!-- Empty --></A>
<H3>4.4 Server Configuration Directives</H3>
<A NAME="4.4.1"><!-- Empty --></A>
<H4>4.4.1 Mandantory Directives</H4>

<P>
<UL>

<LI>
         <STRONG>DIRECTIVE: &#34;ServerName&#34;</STRONG><BR>

         <STRONG>Syntax:</STRONG>
         <CODE>ServerName</CODE> fully-qualified domain name<BR>

         <STRONG>Default:</STRONG> - Mandatory - <BR>

         
         <BR>
<CODE>ServerName</CODE> sets the <CODE>fully-qualified domain
         name</CODE> of the server.
        <BR>

</LI>


<LI>
         <STRONG>DIRECTIVE: &#34;ServerRoot&#34;</STRONG><BR>

         <STRONG>Syntax:</STRONG> <CODE>ServerRoot</CODE> directory-filename<BR>

         <STRONG>Default:</STRONG> - Mandatory -<BR>

         
         <BR>
<CODE>ServerRoot</CODE> defines a <CODE>directory-filename</CODE>
         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 <CODE>directory-filename</CODE>.
        <BR>

</LI>


<LI>
         <STRONG>DIRECTIVE: &#34;DocumentRoot&#34;</STRONG><BR>

         <STRONG>Syntax:</STRONG> <CODE>DocumentRoot</CODE> directory-filename<BR>

         <STRONG>Default:</STRONG> - Mandatory -<BR>

         
         <BR>
<CODE>DocumentRoot</CODE> 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 <CODE>DocumentRoot</CODE> to make
         the path to the document, for example:
         
         <BR>

<PRE>
            DocumentRoot /usr/web
          
</PRE>

         
         and an access to <CODE>http://your.server.org/index.html</CODE>
         would refer to <CODE>/usr/web/index.html</CODE>.<BR>

        
</LI>


</UL>
<A NAME="4.4.2"><!-- Empty --></A>
<H4>4.4.2 Communication Directives</H4>

<P>
<UL>

<LI>
 
         <STRONG>DIRECTIVE: &#34;BindAddress&#34;</STRONG><BR>

         <STRONG>Syntax:</STRONG> <CODE>BindAddress</CODE> address<BR>

         <STRONG>Default:</STRONG> <CODE>BindAddress *</CODE><BR>

         
         <CODE>BindAddress</CODE> 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.<BR>

        
</LI>


<LI>
         <STRONG>DIRECTIVE: &#34;Port&#34;</STRONG><BR>

         <STRONG>Syntax:</STRONG> <CODE>Port</CODE> number<BR>

         <STRONG>Default:</STRONG> <CODE>Port 80</CODE><BR>


        <BR>
<CODE>Port</CODE> defines which port <CODE>number</CODE> the server should
         use (0 to 65535). Certain port numbers are reserved for
         particular protocols, i.e. examine your
         OS characteristics <FONT SIZE="-2">(<CODE>UNIX: /etc/services, Windows: </CODE>)</FONT> for a list 
         of reserved ports. The standard port for HTTP is 80.<BR>

        
        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.<BR>


</LI>


<LI>
         <STRONG>DIRECTIVE: &#34;SocketType&#34;</STRONG><BR>

         <STRONG>Syntax:</STRONG> <CODE>SocketType</CODE> type<BR>

         <STRONG>Default:</STRONG> <CODE>SocketType ip_comm</CODE><BR>

         
         <BR>
<CODE>SocketType</CODE> defines which underlying communication
         <CODE>type</CODE> to be used. Valid socket types are:
         
         <BR>

<DL>

<DT>
<CODE>ip_comm</CODE> 
</DT>

<DD>
the default and preferred
         communication type. ip_comm is also used for all remote
         message passing in Erlang. 
</DD>

<DT>
<CODE>ssl</CODE> 
</DT>

<DD>
the
         communication type to be used to support SSL.
        
</DD>

</DL>

        
</LI>


</UL>
<A NAME="4.4.3"><!-- Empty --></A>
<H4>4.4.3 Limit Directives</H4>

<P>
<UL>

<LI>
         <STRONG>DIRECTIVE: &#34;DisableChunkedTransferEncodingSend&#34;</STRONG><BR>

         <STRONG>Syntax:</STRONG> <CODE>DisableChunkedTransferEncodingSend</CODE>
         true | false<BR>
 <STRONG>Default:</STRONG> false<BR>

         
         <BR>
This directive tells the server whether to use chunked
         transfer-encoding when sending a response to a HTTP/1.1
         client.<BR>

        
</LI>


<LI>
         <STRONG>DIRECTIVE: &#34;KeepAlive&#34;</STRONG><BR>

         <STRONG>Syntax:</STRONG> <CODE>KeepAlive</CODE> true | false<BR>

         <STRONG>Default:</STRONG> true<BR>

         
         <BR>
This directive tells the server whether to use persistent
         connection or not when the client claims to be HTTP/1.1
         compliant.<STRONG>Note:</STRONG>the value of KeepAlive has changed
         from previous versions to be compliant with Apache.<BR>

        
</LI>


<LI>
         <STRONG>DIRECTIVE: &#34;KeepAliveTimeout&#34;</STRONG><BR>

         <STRONG>Syntax:</STRONG> <CODE>KeepAliveTimeout</CODE> seconds<BR>

         <STRONG>Default:</STRONG>150<BR>

         
         <BR>
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.<BR>

        
</LI>


<LI>
         <STRONG>DIRECTIVE: &#34;MaxBodyAction&#34;</STRONG><BR>

         <STRONG>Syntax:</STRONG> <CODE>MaxBodyAction</CODE> action<BR>

         <STRONG>Default:</STRONG> <CODE>MaxBodyAction close</CODE><BR>

         
         <BR>
<CODE>MaxBodyAction</CODE> specifies the action to be taken when the
         message body limit has been passed.
         <BR>

<DL>

<DT>
<CODE>close</CODE>
         
</DT>

<DD>
the default and preferred communication type. ip_comm is
         also used for all remote message passing in Erlang. 
         
</DD>

<DT>
<CODE>reply414</CODE>
         
         
</DT>

<DD>
a reply (status) message with code 414 will be sent to the
         client <STRONG>prior</STRONG> to closing the socket. Note that this
         code is <STRONG>not</STRONG> defined in the HTTP/1.0 version of the
         protocol.
         
</DD>

</DL>

        
</LI>


<LI>
         <STRONG>DIRECTIVE: &#34;MaxBodySize&#34;</STRONG><BR>

         <STRONG>Syntax:</STRONG> <CODE>MaxBodySize</CODE> size<BR>

         <STRONG>Default:</STRONG> <CODE>MaxBodySize nolimit</CODE><BR>

         
         <BR>
<CODE>MaxBodySize</CODE> limits the <CODE>size</CODE> of the message
         body of HTTP request. The reply to this is specified by the
         <CODE>MaxBodyAction</CODE> directive. Valid size is:
         <BR>

<DL>

<DT>
<CODE>nolimit</CODE>
         
</DT>

<DD>
the default message body limit, e.g. no limit.
         
</DD>

<DT>
<CODE>integer()</CODE>
         
</DT>

<DD>
any positive number.
         
</DD>

</DL>

        
</LI>


<LI>
         <STRONG>DIRECTIVE: &#34;MaxClients&#34;</STRONG><BR>

         <STRONG>Syntax:</STRONG> <CODE>MaxClients</CODE> number<BR>

         <STRONG>Default:</STRONG> <CODE>MaxClients 150</CODE><BR>

         
         <BR>
<CODE>MaxClients</CODE> limits the <CODE>number</CODE> of simultaneous
         requests that can be supported. No more than this <CODE>number</CODE>
         of child server process's can be created.<BR>

        
</LI>


<LI>
         <A NAME="MaxHeaderAction"><!-- Empty --></A>
         <STRONG>DIRECTIVE: &#34;MaxHeaderAction&#34;</STRONG> <BR>

         <STRONG>Syntax:</STRONG> <CODE>MaxHeaderAction</CODE> action<BR>

         <STRONG>Default:</STRONG> <CODE>MaxHeaderAction close</CODE>
         
         <BR>
<CODE>MaxHeaderAction</CODE> specifies the action to be taken
         when the message Header limit has been passed.
         <BR>

<DL>

<DT>
<CODE>close</CODE> 
</DT>

<DD>
the socket is closed without any
         message to the client. This is the default action.
         
</DD>

<DT>
<CODE>reply414</CODE> 
</DT>

<DD>
a reply (status) message with
         code 414 will be sent to the client <STRONG>prior</STRONG> to
         closing the socket. Note that this code is <STRONG>not</STRONG>
         defined in the HTTP/1.0 version of the protocol.
         
</DD>

</DL>

        
</LI>


<LI>
         <STRONG>DIRECTIVE: &#34;MaxHeaderSize&#34;</STRONG><BR>

         <STRONG>Syntax:</STRONG> <CODE>MaxHeaderSize</CODE> size<BR>

         <STRONG>Default:</STRONG> <CODE>MaxHeaderSize 10240</CODE><BR>

         
        <BR>
<CODE>MaxHeaderSize</CODE> limits the <CODE>size</CODE> of the message
         header of HTTP request. The reply to this is specified by
         the <CODE>MaxHeaderAction</CODE> directive. Valid size is:
         <BR>

<DL>

<DT>
<CODE>integer()</CODE>
         
</DT>

<DD>
any positive number (default is 10240)
         
</DD>

<DT>
<CODE>nolimit</CODE>
         
</DT>

<DD>
no limit should be applied
         
</DD>

</DL>

        
</LI>


<LI>
        <STRONG>DIRECTIVE: &#34;MaxKeepAliveRequests&#34;</STRONG><BR>

         <STRONG>Syntax:</STRONG> <CODE>MaxKeepAliveRequests</CODE> NumberOfRequests<BR>

         <STRONG>Default:</STRONG>- Disabled -<BR>

         
         <BR>
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.<BR>

        
</LI>


</UL>
<A NAME="4.4.4"><!-- Empty --></A>
<H4>4.4.4 Administrative Directives</H4>

<P>
<UL>

<LI>
         <STRONG>DIRECTIVE: &#34;DefaultType&#34;</STRONG><BR>

         <STRONG>Syntax:</STRONG> <CODE>DefaultType</CODE> mime-type<BR>

         <STRONG>Default:</STRONG> - None -<BR>

         
        <BR>
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 <CODE>mime-type</CODE> is used if an unknown type is
         encountered.<BR>

        
</LI>


<LI>
         <STRONG>DIRECTIVE: &#34;Modules&#34;</STRONG><BR>

         <STRONG>Syntax:</STRONG> <CODE>Modules</CODE> module module ...<BR>

         <STRONG>Default:</STRONG> <CODE>Modules mod_get mod_head mod_log</CODE><BR>

         
         <BR>
<CODE>Modules</CODE> defines which Erlang Webserver API modules to be used in a
         specific server setup. <CODE>module</CODE> 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 <STRONG>Erlang Webserver API Module Sequence</STRONG>).
         
         <BR>
Before altering the Erlang Webserver API Modules Sequence please observe what
         types of data each module uses and propagates.
        <BR>

</LI>


<LI>
         <STRONG>DIRECTIVE: &#34;ServerAdmin&#34;</STRONG><BR>

         <STRONG>Syntax:</STRONG> <CODE>ServerAdmin</CODE> email-address<BR>

         <STRONG>Default:</STRONG> <CODE>ServerAdmin unknown@unknown</CODE><BR>

         
         <BR>
<CODE>ServerAdmin</CODE> defines the <CODE>email-address</CODE> 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:<BR>

         
         
<PRE>
            ServerAdmin www-admin@white-house.com
          
</PRE>

        
</LI>


</UL>
<A NAME="4.4.5"><!-- Empty --></A>
<H4>4.4.5 SSL Directives</H4>

<P>
<UL>

<LI>
         <STRONG>DIRECTIVE: &#34;SSLCACertificateFile&#34;</STRONG><BR>

         <STRONG>Syntax:</STRONG> <CODE>SSLCACertificateFile</CODE> filename<BR>

         <STRONG>Default:</STRONG> - None -<BR>

         
         <BR>
<CODE>SSLCACertificateFile</CODE> 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.
        <BR>

</LI>


<LI>
         <STRONG>DIRECTIVE: &#34;SSLCertificateFile&#34;</STRONG><BR>

         <STRONG>Syntax:</STRONG> <CODE>SSLCertificateFile</CODE> filename<BR>

         <STRONG>Default:</STRONG> - None -<BR>

         
         <BR>
<CODE>SSLCertificateFile</CODE> points at a PEM encoded
         certificate. Read more about PEM encoded certificates in
         the SSL application documentation. The dummy certificate
         server.pem <FONT SIZE="-2">(<CODE>UNIX: $INETS/examples/server_root/ssl/, Windows: %INETS%\examples\server_root\ssl\</CODE>)</FONT>,
         in the Inets distribution, can be used for test
         purposes. Read more about PEM encoded certificates in
         the SSL application documentation.<BR>

        
</LI>


<LI>
         <STRONG>DIRECTIVE: &#34;SSLCertificateKeyFile&#34;</STRONG><BR>

         <STRONG>Syntax:</STRONG> <CODE>SSLCertificateKeyFile</CODE> filename<BR>

         <STRONG>Default:</STRONG> - None -<BR>

         
         <BR>
<CODE>SSLCertificateKeyFile</CODE> 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 .
        <BR>

</LI>


<LI>
         <STRONG>DIRECTIVE: &#34;SSLVerifyClient&#34;</STRONG><BR>

         <STRONG>Syntax:</STRONG> <CODE>SSLVerifyClient</CODE> type<BR>

         <STRONG>Default:</STRONG> - None -<BR>

         
         <BR>
Set <CODE>type</CODE> to:
         
         <BR>

<DL>

<DT>
0
         
         
</DT>

<DD>
if no client certificate is required.
         
</DD>

<DT>
1
</DT>

<DD>
if the client <STRONG>may</STRONG> present a valid
         certificate.
         
         
</DD>

<DT>
2
</DT>

<DD>
if the client <STRONG>must</STRONG>
                present a valid certificate.
         
         
</DD>

<DT>
3 
</DT>

<DD>
if the client <STRONG>may</STRONG> present a valid
         certificate but it is <STRONG>not</STRONG> required to have a
         valid CA.
         
</DD>

</DL>

         
         Read more about SSL in the application documentation.
        <BR>

</LI>


<LI>
         <STRONG>DIRECTIVE: &#34;SSLVerifyDepth&#34;</STRONG><BR>

         <STRONG>Syntax:</STRONG> <CODE>SSLVerifyDepth</CODE> integer<BR>

         <STRONG>Default:</STRONG> - None -<BR>

         
         <BR>
This directive specifies how far up or down the
         (certification) chain we are prepared to go before giving up.
         <BR>
Read more about SSL in the application documentation.
         
        <BR>

</LI>


<LI>
         <STRONG>DIRECTIVE: &#34;SSLCiphers&#34;</STRONG><BR>

         <STRONG>Syntax:</STRONG> <CODE>SSLCiphers</CODE> ciphers<BR>

         <STRONG>Default:</STRONG> - None - <BR>

         
         <BR>
<CODE>SSLCihers</CODE> is a colon separated list of ciphers.
         <BR>
Read more about SSL in the application documentation.
        <BR>

</LI>


<LI>
         <STRONG>DIRECTIVE: &#34;SSLPasswordCallbackFunction&#34;</STRONG><BR>

         
         <STRONG>Syntax:</STRONG> <CODE>SSLPasswordCallbackFunction</CODE>
         function<BR>

         
         <STRONG> Default:</STRONG> - None - <BR>

         
         <BR>
The <CODE>SSLPasswordCallbackFunction</CODE> function in module
         <CODE>SSLPasswordCallbackModule</CODE> is called in order to
         retrieve the user's password.<BR>


         Read more about SSL in
         the application documentation.<BR>


        
</LI>


<LI>
         <A NAME="SSLPasswordCallbackModule"><!-- Empty --></A>
        <STRONG>DIRECTIVE: &#34;SSLPasswordCallbackModule&#34;</STRONG>
         <STRONG>Syntax:</STRONG> <CODE>SSLPasswordCallbackModule</CODE> function<BR>

         <STRONG>Default:</STRONG> - None - <BR>

         
         <BR>
The <CODE>SSLPasswordCallbackFunction</CODE> function in the 
         <CODE>SSLPasswordCallbackModule</CODE> module is called in order 
         to retrieve the user's password.<BR>


         Read more about SSL in the application documentation.<BR>

        
</LI>


</UL>
<A NAME="4.4.6"><!-- Empty --></A>
<H4>4.4.6 URL Aliasing</H4>

<P>
<UL>

<LI>
         <STRONG>DIRECTIVE: &#34;Alias&#34;</STRONG><BR>

         <STRONG>Syntax:</STRONG> <CODE>Alias</CODE> url-path directory-filename<BR>

         <STRONG>Default:</STRONG> - None -<BR>

         
         <BR>
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
         <CODE>url-path</CODE> is mapped to local files that begins with
         <CODE>directory-filename</CODE>, for example:<BR>

         
         
<PRE>
            Alias /image /ftp/pub/image
          
</PRE>

         
         and an access to
         <CODE>http://your.server.org/image/foo.gif</CODE> would refer to the
         file <CODE>/ftp/pub/image/foo.gif</CODE>.<BR>

         
        
</LI>


<LI>
         <STRONG>DIRECTIVE: &#34;DirectoryIndex&#34;</STRONG><BR>

         <STRONG>Syntax:</STRONG> <CODE>DirectoryIndex</CODE> file file ...<BR>

         <STRONG>Default:</STRONG> - None -<BR>

         
         <BR>
<CODE>DirectoryIndex</CODE> specifies a list of resources to
         look for if a client requests a directory using a <CODE>/</CODE>
         at the end of the directory name. <CODE>file</CODE> 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:<BR>


         
<PRE>
            DirectoryIndex index.html
          
</PRE>


         and access to <CODE>http://your.server.org/docs/</CODE> would
         return <CODE>http://your.server.org/docs/index.html</CODE> if it
         existed.<BR>

        
</LI>


<LI>
         <STRONG>DIRECTIVE: &#34;ScriptAlias&#34;</STRONG><BR>

         <STRONG>Syntax:</STRONG>
         <CODE>ScriptAlias</CODE> url-path directory-filename<BR>

         <STRONG>Default:</STRONG> - None -<BR>

         
         <BR>
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
         <CODE>url-path</CODE> are mapped to scripts beginning with
         <CODE>directory-filename</CODE>, for example:<BR>


         
<PRE>
ScriptAlias /cgi-bin/ /web/cgi-bin/
          
</PRE>

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

        
</LI>


</UL>
<A NAME="4.4.7"><!-- Empty --></A>
<H4>4.4.7 CGI Directives</H4>

<P>
<UL>

<LI>
         <STRONG>DIRECTIVE: &#34;ScriptNoCache&#34;</STRONG><BR>

         <STRONG>Syntax:</STRONG> <CODE>ScritpNoCache</CODE> true | false<BR>

         <STRONG>Default:</STRONG> - false -<BR>

         
         <BR>
         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.<BR>

         
         
<PRE>
            ScriptNoCache true
          
</PRE>

        
</LI>


<LI>
         <STRONG>DIRECTIVE: &#34;ScriptTimeout&#34;</STRONG><BR>

         <STRONG>Syntax:</STRONG> <CODE>ScritpTimeout</CODE> Seconds<BR>

         <STRONG>Default:</STRONG> 15 <BR>

         
         <BR>
 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.
         <BR>

<PRE>
            ScriptTimeout  15
          
</PRE>

        
</LI>


<LI>
         <STRONG>DIRECTIVE: &#34;Action&#34;</STRONG><BR>

         <STRONG>Syntax:</STRONG> <CODE>Action</CODE> mime-type cgi-script<BR>

         <STRONG>Default:</STRONG> - None -<BR>

         
        <BR>
<CODE>Action</CODE> adds an action, which will activate a
         <CODE>cgi-script</CODE> whenever a file of a certain
         <CODE>mime-type</CODE> is requested. It propagates the URL and
         file path of the requested document using the standard CGI
         <CODE>PATH_INFO</CODE> and <CODE>PATH_TRANSLATED</CODE> environment
         variables.
         
         <BR>
Examples:<BR>
 
         
         
<PRE>
            Action text/plain /cgi-bin/log_and_deliver_text
            Action home-grown/mime-type1 /~bob/do_special_stuff
          
</PRE>

        
</LI>


<LI>
         <STRONG>DIRECTIVE: &#34;Script&#34;</STRONG><BR>

         <STRONG>Syntax:</STRONG> <CODE>Script</CODE> method cgi-script<BR>

         <STRONG>Default:</STRONG> - None -<BR>

         
         <BR>
<CODE>Script</CODE> adds an action, which will activate a
         <CODE>cgi-script</CODE> whenever a file is requested using a certain
         HTTP <CODE>method</CODE>. The <CODE>method</CODE> is either <CODE>GET</CODE> or
         <CODE>POST</CODE> as defined in RFC 1945. It propagates the URL and
         file path of the requested document using the standard CGI
         <CODE>PATH_INFO</CODE> and <CODE>PATH_TRANSLATED</CODE> environment
         variables.<BR>

         
         Examples:<BR>
 
         
         
<PRE>
            Script GET /cgi-bin/get
            Script POST /~bob/put_and_a_little_more
          
</PRE>

        
</LI>


</UL>
<A NAME="4.4.8"><!-- Empty --></A>
<H4>4.4.8  ESI Directives</H4>

<P>
<UL>

<LI>
         <STRONG>DIRECTIVE: &#34;ErlScriptAlias&#34;</STRONG><BR>

         <STRONG>Syntax:</STRONG> <CODE>ErlScriptAlias</CODE> url-path
         allowed-module allowed-module ...<BR>

         <STRONG>Default:</STRONG> - None -<BR>

         
         <BR>
<CODE>ErlScriptAlias</CODE> marks all URLs matching <CODE>url-path</CODE>
         as erl scheme scripts. A
         matching URL is mapped into a specific module and
         function. The module must be one of the
         <CODE>allowed-module</CODE>:s. For example:
         
         <BR>

<PRE>
ErlScriptAlias /cgi-bin/hit_me httpd_example md4
          
</PRE>

         
         and a request to
         <CODE>http://your.server.org/cgi-bin/hit_me/httpd_example:yahoo</CODE>
         would refer to <CODE>httpd_example:yahoo/2</CODE>. 
        <BR>

</LI>


<LI>
         <STRONG>DIRECTIVE: &#34;ErlScriptNoCache&#34;</STRONG><BR>

         <STRONG>Syntax:</STRONG> <CODE>ErlScriptNoCache</CODE> true | false<BR>
 
         <STRONG>Default:</STRONG> false <BR>

         
         <BR>
If <CODE>ErlScriptNoCache</CODE> 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.<BR>

         
         
<PRE>
            ErlScriptNoCache true
          
</PRE>

        
</LI>


<LI>
         <STRONG>DIRECTIVE: &#34;ErlScriptTimeout&#34;</STRONG><BR>

         <STRONG>Syntax:</STRONG> <CODE>ErlScriptTimeout</CODE> seconds<BR>
 
         <STRONG>Default:</STRONG> 15 <BR>

         
         <BR>
If <CODE>ErlScriptTimeout</CODE> 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.
         
        <BR>

<PRE>
            ErlScriptTimeout 15
          
</PRE>

        
</LI>


<LI>
         <STRONG>DIRECTIVE: &#34;EvalScriptAlias&#34;</STRONG><BR>

         <STRONG>Syntax:</STRONG>
         <CODE>EvalScriptAlias</CODE> url-path allowed-module
         allowed-module ...<BR>
 <STRONG>Default:</STRONG> - None -<BR>

         
         <BR>
<CODE>EvalScriptAlias</CODE> marks all URLs matching
         <CODE>url-path</CODE> as eval scheme
         scripts. A matching URL is mapped into a specific module
         and function. The module must be one of the
         <CODE>allowed-module</CODE>:s. For example:
         
         <BR>

<PRE>
 EvalScriptAlias /cgi-bin/hit_me_to httpd_example md5
          
</PRE>

         
         and a request to
         <CODE>http://your.server.org/cgi-bin/hit_me_to/httpd_example:print(&#34;Hi!&#34;)</CODE>
         would refer to <CODE>httpd_example:print/1</CODE>.<BR>
 
        
</LI>


</UL>
<A NAME="4.4.9"><!-- Empty --></A>
<H4>4.4.9 Auth Directives</H4>

<P>
<UL>

<LI>
         <STRONG>DIRECTIVE: &#34;Directory&#34;</STRONG><BR>

         <STRONG>Syntax:</STRONG>
         <CODE>&#60;Directory</CODE> regexp-filename<CODE>&#62;</CODE><BR>

         <STRONG>Default:</STRONG> - None -<BR>

         
         <BR>
<CODE>&#60;Directory&#62;</CODE> and &#60;/Directory&#62; are used
         to enclose a group of directives which applies only to the
         named directory and sub-directories of that
         directory. <CODE>regexp-filename</CODE> is an extended regular
         expression (See <CODE>regexp(3)</CODE>). For example:
         
        <BR>

<PRE>
          &#60;Directory /usr/local/httpd[12]/htdocs&#62;
          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
          &#60;/Directory&#62;
        
</PRE>


        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 <CODE>garden/</CODE> and one for <CODE>garden/flowers</CODE>, the
         <CODE>garden/</CODE> section matches first.
<BR>

</LI>


<LI>
        <STRONG>DIRECTIVE: &#34;AuthDBType&#34;</STRONG><BR>

        <STRONG>Syntax:</STRONG> <CODE>AuthDBType</CODE> plain | dets | mnesia<BR>

         <STRONG>Default:</STRONG> - None -<BR>

         <STRONG>Context:</STRONG> Directory<BR>
 

        <BR>
<CODE>AuthDBType</CODE> 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.

        <BR>
 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. <CODE>first_start/0</CODE> creates the schema
and the tables. The second function <CODE>start/0</CODE> shall be used
in consecutive startups. <CODE>start/0</CODE> 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.

        <BR>

<PRE>
   
    -module(mnesia_test).
    -export([start/0,load_data/0]).
    -include(&#34;mod_auth.hrl&#34;).   
 
    first_start()-&#62;
         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()-&#62;
        mnesia:start(),
        mnesia:wait_for_tables([httpd_user,httpd_group],60000).                 
    
</PRE>


                 To create the Mnesia tables we use two records defined in
         mod_auth.hrl so the file must be included.

        <BR>
The first function <CODE>first_start/0</CODE> 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.

        <BR>
         When the schema and the tables is created the second
         function <CODE>start/0</CODE>shall be used to start Mensia. It
         starts Mnesia and wait for the tables to be loaded. Mnesia
         use the directory specified as <CODE>mnesia_dir</CODE> at startup
         if specified, otherwise Mnesia use the current directory.

<BR>
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.
        
<BR>
Only the <CODE>dets</CODE> and <CODE>mnesia</CODE> storage methods allow
        writing of dynamic user data to disk. <CODE>plain</CODE> is a read
only method.
                        
<BR>

</LI>


<LI>
 <STRONG>DIRECTIVE: &#34;AuthUserFile&#34;</STRONG><BR>

<STRONG>Syntax:</STRONG> <CODE>AuthUserFile</CODE> filename<BR>

        <STRONG>Default:</STRONG> - None -<BR>

         <STRONG>Context:</STRONG> Directory<BR>

        
         <BR>
<CODE>AuthUserFile</CODE> sets the name of a file which
         contains the list of users and passwords for user
         authentication. <CODE>filename</CODE> can be either absolute or
         relative to the <CODE>ServerRoot</CODE>.

         <BR>
If using the <CODE>plain</CODE> storage method, this file is a
         plain text file, where each line contains a user name followed
         by a colon, followed by the <STRONG>non-encrypted</STRONG> password.
         The behavior is undefined if user names are duplicated. For
         example:

<BR>

<PRE>
        ragnar:s7Xxv7
        edward:wwjau8
      
</PRE>


         If using the <CODE>dets</CODE> storage method, the user database is
         maintained by <CODE>dets</CODE> and <STRONG>should not</STRONG> be edited by
         hand. Use the API functions in mod_auth
         module to create / edit the user database.
         
         <BR>
This directive is ignored if using the <CODE>mnesia</CODE> storage
         method.
         
         <BR>
For security reasons, make sure that the <CODE>AuthUserFile</CODE>
         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.
         
<BR>

</LI>


<LI>
         
         <STRONG>DIRECTIVE: &#34;AuthGroupFile&#34;</STRONG><BR>

         <STRONG>Syntax:</STRONG> <CODE>AuthGroupFile</CODE> filename<BR>

         <STRONG>Default:</STRONG> - None -<BR>

         <STRONG>Context:</STRONG> Directory<BR>
 

         <BR>
<CODE>AuthGroupFile</CODE> sets the name of a file which contains the
         list of user groups for user authentication. <CODE>filename</CODE> can
         be either absolute or relative to the <CODE>ServerRoot</CODE>.

         <BR>
If you use the <CODE>plain</CODE> 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:

         <BR>

<PRE>
            group1: bob joe ante
          
</PRE>

         
         If using the <CODE>dets</CODE> storage method, the group database is
         maintained by <CODE>dets</CODE> and <STRONG>should not</STRONG> be edited by
         hand. Use the API for mod_auth
         module to create / edit the group database.

         <BR>
This directive is ignored if using the <CODE>mnesia</CODE> storage
         method.

         <BR>
For security reasons, make sure that the <CODE>AuthGroupFile</CODE>
         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.
        <BR>

</LI>


<LI>
        <STRONG>DIRECTIVE: &#34;AuthName&#34;</STRONG><BR>

        <STRONG>Syntax:</STRONG> <CODE>AuthName</CODE> auth-domain<BR>

         <STRONG>Default:</STRONG> - None -<BR>

         <STRONG>Context:</STRONG> Directory<BR>
 
         
         <BR>
<CODE>AuthName</CODE> sets the name of the authorization realm
         (<CODE>auth-domain</CODE>) for a directory. This string informs the
         client about which user name and password to use.
        <BR>

</LI>


<LI>
         <STRONG>DIRECTIVE: &#34;AuthAccessPassword&#34;</STRONG><BR>

         <STRONG>Syntax:</STRONG> <CODE>AuthAccessPassword</CODE> password<BR>

         <STRONG>Default:</STRONG> NoPassword <BR>

         <STRONG>Context:</STRONG> Directory<BR>


         <BR>
If <CODE>AuthAccessPassword</CODE> 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.<BR>

        
</LI>


<LI>
         <STRONG>DIRECTIVE: &#34;allow&#34;</STRONG><BR>

         <STRONG>Syntax:</STRONG> <CODE>allow from</CODE> host host ...<BR>

         <STRONG>Default:</STRONG> <CODE>allow from all</CODE><BR>

         <STRONG>Context:</STRONG> Directory <BR>
 
         
         <BR>
<CODE>allow</CODE> defines a set of hosts which should be
         granted access to a given directory. <CODE>host</CODE> is one of
         the following:
         
         <BR>

<DL>

<DT>
<CODE>all</CODE> 
         
</DT>

<DD>
All hosts are allowed access.
         
</DD>

<DT>
A regular expression (Read <CODE>regexp(3)</CODE>)
         
</DT>

<DD>
All hosts having a numerical IP address matching the
         specific regular expression are allowed access.
         
</DD>

</DL>

         
         For example:
         
         <BR>

<PRE>
            allow from 123.34.56.11 150.100.23
          
</PRE>

         
         The host 123.34.56.11 and all machines on the 150.100.23
         subnet are allowed access.<BR>

        
</LI>


<LI>
         <STRONG>DIRECTIVE: &#34;deny&#34;</STRONG><BR>

         <STRONG>Syntax:</STRONG> <CODE>deny from</CODE> host host ...<BR>

         <STRONG>Default:</STRONG> <CODE>deny from all</CODE><BR>

         <STRONG>Context:</STRONG> Directory<BR>

        
         <BR>
<CODE>deny</CODE> defines a set of hosts which should not be
         granted access to a given directory. <CODE>host</CODE> is one of
         the following:
        
         <BR>

<DL>

<DT>
<CODE>all</CODE> 
         
</DT>

<DD>
All hosts are denied access.
         
</DD>

<DT>
A regular expression (Read <CODE>regexp(3)</CODE>)
         
</DT>

<DD>
All hosts having a numerical IP address matching the
         specific regular expression are denied access.
         
</DD>

</DL>

         
         For example:
         
         <BR>

<PRE>
            deny from 123.34.56.11 150.100.23
          
</PRE>

         
         The host 123.34.56.11 and all machines on the 150.100.23 subnet
         are denied access. <BR>

</LI>


<LI>
         <STRONG>DIRECTIVE: &#34;require&#34;</STRONG><BR>

         <STRONG>Syntax:</STRONG> <CODE>require</CODE> entity-name entity entity ...<BR>

         <STRONG>Default:</STRONG> - None -<BR>

         <STRONG>Context:</STRONG> Directory<BR>

         
         <BR>
<CODE>require</CODE> defines users which should be granted
         access to a given directory using a secret password. The allowed
         syntaxes are:
         
         <BR>

<DL>

<DT>
<CODE>require user user-name user-name ...</CODE>
         
</DT>

<DD>
Only the named users can access the directory.
         
</DD>

<DT>
<CODE>require group group-name group-name ...</CODE>
         
</DT>

<DD>
Only users in the named groups can access the directory.
         
</DD>

</DL>

        
</LI>


</UL>
<A NAME="4.4.10"><!-- Empty --></A>
<H4>4.4.10 Htacess Authentication Directives</H4>

<P>
<UL>

<LI>
         <STRONG>DIRECTIVE: &#34;AccessFileName&#34;</STRONG>
                 <STRONG>Syntax:</STRONG> <CODE>AccessFileName</CODE><CODE>FileName1
         FileName2</CODE><BR>
 <STRONG>Default:</STRONG> .htaccess 
         <BR>

         
                 <CODE>AccessFileName</CODE> 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.
        <BR>

</LI>


</UL>
<A NAME="4.4.11"><!-- Empty --></A>
<H4>4.4.11 Auth Filter Directives</H4>

<P>
<UL>

<LI>
 
         <STRONG>DIRECTIVE: &#34;SecurityDataFile&#34;</STRONG><BR>

         <STRONG>Syntax:</STRONG> <CODE>SecurityDataFile</CODE> filename<BR>

         <STRONG>Default:</STRONG> - None -<BR>

         <STRONG>Context:</STRONG> Directory

         <BR>
<CODE>SecurityDataFile</CODE> sets the name of the security
         modules for a directory. The filename can be either absolute
         or relative to the <CODE>ServerRoot</CODE>. This file is used to
         store persistent data for the mod_security module.
         
         <BR>
Several directories can have the same
         <CODE>SecurityDataFile</CODE>.
         
        <BR>

</LI>


<LI>
 <STRONG>DIRECTIVE: &#34;SecurityMaxRetries&#34;</STRONG><BR>

         <STRONG>Syntax:</STRONG> <CODE>SecurityMaxRetries</CODE> integer() | infinity<BR>

         <STRONG>Default:</STRONG> 3<BR>

         <STRONG>Context:</STRONG><BR>

         
         <BR>
<CODE>SecurityMaxRetries</CODE> 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.<BR>

         
        For security reasons, failed authentications made by this
         user will return a message 401 (Unauthorized), even if the
user is blocked.<BR>


</LI>


<LI>
         <STRONG>DIRECTIVE: &#34;SecurityBlockTime&#34;</STRONG> <BR>

         <STRONG>Syntax:</STRONG> <CODE>SecurityBlockTime</CODE> integer() | infinity<BR>

         <STRONG>Default:</STRONG> 60<BR>

         <STRONG>Context:</STRONG> Directory<BR>
 

         <BR>
<CODE>SecurityBlockTime</CODE> specifies the number of minutes a user
         is blocked. After this amount of time, he automatically
         regains access.
        <BR>

</LI>


<LI>
 <STRONG>DIRECTIVE: &#34;SecurityFailExpireTime&#34;</STRONG><BR>

         <STRONG>Syntax:</STRONG> <CODE>SecurityFailExpireTime</CODE> integer() | infinity<BR>

         <STRONG>Default:</STRONG> 30<BR>

         <STRONG>Context:</STRONG> Directory <BR>
 
         
         <BR>
<CODE>SecurityFailExpireTime</CODE> 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.<BR>

        
</LI>


<LI>
        <STRONG>DIRECTIVE: &#34;SecurityAuthTimeout&#34;</STRONG><BR>

         <STRONG>Syntax:</STRONG> <CODE>SecurityAuthTimeout</CODE> integer() | infinity<BR>

         <STRONG>Default:</STRONG> 30<BR>

         <STRONG>Context:</STRONG> Directory<BR>
 
         
         <BR>
<CODE>SecurityAuthTimeout</CODE> specifies the number of
         seconds a successful user authentication is
         remembered. After this time has passed, the authentication
         will no longer be reported.<BR>


</LI>


<LI>
         <STRONG>DIRECTIVE: &#34;SecurityCallbackModule&#34;</STRONG><BR>

         <STRONG>Syntax:</STRONG> <CODE>SecurityCallbackModule</CODE> atom()<BR>

         <STRONG>Default:</STRONG> - None -<BR>

         <STRONG>Context:</STRONG> Directory <BR>

         
         <BR>
<CODE>SecurityCallbackModule</CODE> specifies the name of a callback
         module. <BR>
 
        
</LI>


</UL>
<A NAME="4.4.12"><!-- Empty --></A>
<H4>4.4.12 Logging Directives</H4>

<P>
<UL>

<LI>
         <STRONG>DIRECTIVE: &#34;ErrorLog&#34;</STRONG><BR>

         <STRONG>Syntax:</STRONG> <CODE>ErrorLog</CODE> filename<BR>

         <STRONG>Default:</STRONG> - None -<BR>

         
         <BR>
<CODE>ErrorLog</CODE> defines the <CODE>filename</CODE> of the error log
         file to be used to log server errors. If the <CODE>filename</CODE>
         does not begin with a slash (<CODE>/</CODE>) it is assumed to be
         relative to the ServerRoot, for example: 
         
         <BR>

<PRE>
            ErrorLog logs/error_log_8080
          
</PRE>

         
         and errors will be logged in the
         server
         root <FONT SIZE="-2">(<CODE>UNIX: $SERVER_ROOT/logs/error_log_8080, Windows: %SERVER_ROOT%\logs\error_log_8080</CODE>)</FONT> space.
        <BR>

</LI>


<LI>
         <STRONG>DIRECTIVE: &#34;SecurityLog&#34;</STRONG><BR>

         <STRONG>Syntax:</STRONG> <CODE>SecurityLog</CODE> filename<BR>

         <STRONG>Default:</STRONG> - None -<BR>


         <BR>
<CODE>SecurityLog</CODE> defines the <CODE>filename</CODE> of the
         access log file to be used to log security events. If the
         <CODE>filename</CODE> does not begin with a slash (<CODE>/</CODE>) it is
         assumed to be relative to the ServerRoot. For example:
         
        <BR>

<PRE>
            SecurityLog logs/security_log_8080
          
</PRE>

         
         and security events will be logged in the
         server
         root <FONT SIZE="-2">(<CODE>UNIX: $SERVER_ROOT/logs/security_log_8080, Windows: %SERVER_ROOT%\logs\security_log_8080</CODE>)</FONT> space.
        <BR>

</LI>


<LI>
         <STRONG>DIRECTIVE: &#34;TransferLog&#34;</STRONG><BR>

         <STRONG>Syntax:</STRONG> <CODE>TransferLog</CODE> filename<BR>

         <STRONG>Default:</STRONG> - None -<BR>

         
        <BR>
<CODE>TransferLog</CODE> defines the <CODE>filename</CODE> of the
         access log file to be used to log incoming requests. If the
         <CODE>filename</CODE> does not begin with a slash (<CODE>/</CODE>) it is
         assumed to be relative to the ServerRoot. For example:<BR>

         
        
<PRE>
            TransferLog logs/access_log_8080
          
</PRE>

         
         and errors will be logged in the
         server
         root <FONT SIZE="-2">(<CODE>UNIX: $SERVER_ROOT/logs/access_log_8080, Windows: %SERVER_ROOT%\logs\access_log_8080</CODE>)</FONT> space.
        <BR>

</LI>


</UL>
<A NAME="4.4.13"><!-- Empty --></A>
<H4>4.4.13 Disk Log Directives</H4>

<P>
<UL>

<LI>
         <STRONG>DIRECTIVE: &#34;DiskLogFormat&#34;</STRONG><BR>

         <STRONG>Syntax:</STRONG> <CODE>DiskLogFormat</CODE> internal|external<BR>

         <STRONG>Default:</STRONG> - external -<BR>

         
        <BR>
<CODE>DiskLogFormat</CODE> defines the file-format of the
         log files see <STRONG>disk_log</STRONG> 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. <BR>

         
<PRE>
          DiskLogFormat external
          
</PRE>

        
</LI>


<LI>
         <STRONG>DIRECTIVE: &#34;ErrorDiskLog&#34;</STRONG><BR>

         <STRONG>Syntax:</STRONG> <CODE>ErrorDiskLog</CODE> filename<BR>

         <STRONG>Default:</STRONG> - None -<BR>

         
         <BR>
<CODE>ErrorDiskLog</CODE> defines the <CODE>filename</CODE> of the
         <CODE>(disk_log(3))</CODE> error log file to be used to log server
         errors. If the <CODE>filename</CODE> does not begin with a slash
         (<CODE>/</CODE>) it is assumed to be relative to the ServerRoot,
         for example:<BR>

         
         
<PRE>
          ErrorDiskLog logs/error_disk_log_8080
          
</PRE>

         
         and errors will be logged in the
         server
         root <FONT SIZE="-2">(<CODE>UNIX: $SERVER_ROOT/logs/error_disk_log_8080, Windows: %SERVER_ROOT%\logs\error_disk_log_8080</CODE>)</FONT> space.<BR>

        
</LI>


<LI>
         <STRONG>DIRECTIVE: &#34;ErrorDiskLogSize&#34;</STRONG><BR>

         
         <STRONG>Syntax:</STRONG> <CODE>ErrorDiskLogSize</CODE> max-bytes
         max-files<BR>
 <STRONG>Default:</STRONG> <CODE>ErrorDiskLogSize 512000
         8</CODE><BR>
 <BR>
<CODE>ErrorDiskLogSize</CODE> defines the
         properties of the <CODE>(disk_log(3))</CODE> error log file. The
         <CODE>disk_log(3)</CODE> error log file is of type <STRONG>wrap
         log</STRONG> and <CODE>max-bytes</CODE> will be written to each file
         and <CODE>max-files</CODE> will be used before the first file is
         truncated and reused.<BR>

        
</LI>


<LI>
         <STRONG>DIRECTIVE: &#34;SecurityDiskLog&#34;</STRONG><BR>

         <STRONG>Syntax:</STRONG> <CODE>SecurityDiskLog</CODE> filename<BR>

         <STRONG>Default:</STRONG> - None -<BR>

         
         <BR>
<CODE>SecurityDiskLog</CODE> defines the <CODE>filename</CODE> of the
         <CODE>(disk_log(3))</CODE> access log file which logs incoming
         security events i.e authenticated requests. 
         If the <CODE>filename</CODE> does not begin with a slash
         (<CODE>/</CODE>) it is assumed to be relative to the ServerRoot.<BR>

        
</LI>


<LI>
         <STRONG>DIRECTIVE: &#34;SecurityDiskLogSize&#34;</STRONG><BR>

         <STRONG>Syntax:</STRONG> <CODE>SecurityDiskLogSize</CODE> max-bytes max-files<BR>

         <STRONG>Default:</STRONG> <CODE>SecurityDiskLogSize 512000 8</CODE><BR>

         
         <BR>
<CODE>SecurityDiskLogSize</CODE> defines the properties of the
         <CODE>disk_log(3)</CODE> access log file. The <CODE>disk_log(3)</CODE>
         access log file is of type <STRONG>wrap log</STRONG> and
         <CODE>max-bytes</CODE> will be written to each file and
         <CODE>max-files</CODE> will be used before the first file is
         truncated and reused.<BR>

        
</LI>


<LI>
         <STRONG>DIRECTIVE: &#34;TransferDiskLog&#34;</STRONG><BR>

         <STRONG>Syntax:</STRONG> <CODE>TransferDiskLog</CODE> filename<BR>

         <STRONG>Default:</STRONG> - None -<BR>

         
<BR>
<CODE>TransferDiskLog</CODE> defines the <CODE>filename</CODE> of the
         <CODE>(disk_log(3))</CODE> access log file which logs incoming
         requests. If the <CODE>filename</CODE> does not begin with a slash
         (<CODE>/</CODE>) it is assumed to be relative to the 
         ServerRoot, for example:
         
        <BR>

<PRE>
          TransferDiskLog logs/transfer_disk_log_8080
        
</PRE>

        
         and errors will be logged in the
         server
         root <FONT SIZE="-2">(<CODE>UNIX: $SERVER_ROOT/logs/transfer_disk_log_8080, Windows: %SERVER_ROOT%\logs\transfer_disk_log_8080</CODE>)</FONT> space.<BR>

        
</LI>


<LI>
         <STRONG>DIRECTIVE: &#34;TransferDiskLogSize&#34;</STRONG><BR>

         <STRONG>Syntax:</STRONG> <CODE>TransferDiskLogSize</CODE> max-bytes max-files<BR>

         <STRONG>Default:</STRONG> <CODE>TransferDiskLogSize 512000 8</CODE><BR>

         
         <BR>
<CODE>TransferDiskLogSize</CODE> defines the properties of the
         <CODE>disk_log(3)</CODE> access log file. The <CODE>disk_log(3)</CODE>
         access log file is of type <STRONG>wrap log</STRONG> and
         <CODE>max-bytes</CODE> will be written to each file and
         <CODE>max-files</CODE> will be used before the first file is truncated
         and reused.<BR>

        
</LI>


</UL>
<A NAME="4.5"><!-- Empty --></A>
<H3>4.5 Mime Type Configuration</H3>

<P>Files delivered to the client are MIME typed according to RFC
1590. File suffixes are mapped to MIME types before file delivery.
<P>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:
<PRE>
    # MIME type                 Extension  
    text/html                   html htm
    text/plain                  asc txt
    
</PRE>
<A NAME="4.6"><!-- Empty --></A>
<H3>4.6 Htaccess - User Configurable Authentication.</H3>

<P> 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: 
<P>
<UL>

<LI>
 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. 
</LI>


<LI>
        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.

</LI>


<LI>
        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.

</LI>


<LI>
        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.

</LI>


<LI>
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.

</LI>


</UL>
<A NAME="4.6.1"><!-- Empty --></A>
<H4>4.6.1 Access Files Directives</H4>

<P>      In every directory under the <CODE>DocumentRoot</CODE> or under an
        <CODE>Alias</CODE> 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.

<P>
<UL>

<LI>
         <STRONG>DIRECTIVE: &#34;allow&#34;</STRONG>
                 <STRONG>Syntax:</STRONG> <CODE>Allow</CODE> from subnet subnet|from all<BR>

         <STRONG>Default:</STRONG> <CODE> from all </CODE><BR>

         <BR>
         Same as the directive allow for the server config file. 
         <BR>

        
</LI>


<LI>
         <STRONG>DIRECTIVE: &#34;AllowOverRide&#34;</STRONG>
                 <STRONG>Syntax:</STRONG> <CODE>AllowOverRide</CODE> all | none |
         Directives<BR>

         <STRONG>Default:</STRONG> <CODE> - None -</CODE><BR>


         <CODE>AllowOverRide</CODE> 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. 

         <BR>
         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.<BR>

        
</LI>


<LI>
         <STRONG>DIRECTIVE: &#34;AuthGroupfile&#34;</STRONG>
                 <STRONG>Syntax:</STRONG> <CODE>AuthGroupFile</CODE> Filename<BR>

         <STRONG>Default:</STRONG> <CODE> - None -</CODE><BR>

         <BR>


                 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:
         <BR>


         
<PRE>
            GroupName: Member1 Member2 .... MemberN
          
</PRE>

        
</LI>


<LI>
         <STRONG>DIRECTIVE: &#34;AuthName&#34;</STRONG>
                 <STRONG>Syntax:</STRONG> <CODE>AuthName</CODE> auth-domain<BR>

         <STRONG>Default:</STRONG> <CODE> - None -</CODE><BR>

         <BR>

                 Same as the directive AuthName for the server config file. 
         <BR>

        
</LI>


<LI>
         <STRONG>DIRECTIVE: &#34;AuthType&#34;</STRONG>
                 <STRONG>Syntax:</STRONG> <CODE>AuthType</CODE> Basic<BR>

         <STRONG>Default:</STRONG> <CODE>Basic</CODE><BR>

         <BR>

                 <CODE>AuthType</CODE> Specify which authentication scheme that shall
         be used. Today only Basic Authenticating using UUEncoding of
         the password and user ID is implemented. <BR>

        
</LI>


<LI>
         <STRONG>DIRECTIVE: &#34;AuthUserFile&#34;</STRONG>
                 <STRONG>Syntax:</STRONG> <CODE>AuthUserFile</CODE> Filename<BR>

         <STRONG>Default:</STRONG> <CODE> - None -</CODE><BR>

         <BR>

                 <CODE>AuthUserFile</CODE> 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:
         <BR>

         
<PRE>
            UserName:Password
            UserName:Password
          
</PRE>

        
</LI>


<LI>
         <STRONG>DIRECTIVE: &#34;deny&#34;</STRONG>
                 <STRONG>Syntax:</STRONG> <CODE>deny</CODE> from subnet subnet|from all<BR>

         <STRONG>Context:</STRONG> Limit
         <BR>
         Same as the directive deny for the server config file. 
         <BR>

        
</LI>


<LI>
         <STRONG>DIRECTIVE: &#34;Limit&#34;</STRONG><BR>

         <STRONG>Syntax:</STRONG> <CODE>&#60;Limit</CODE> RequestMethods<CODE>&#62;</CODE><BR>

         <STRONG>Default:</STRONG> - None -<BR>

         <BR>

         <CODE>&#60;Limit&#62;</CODE> and &#60;/Limit&#62; 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.
         <BR>

         
<PRE>
            &#60;Limit POST GET HEAD&#62;
            order allow deny
            require group group1
            allow from 123.145.244.5
            &#60;/Limit&#62;
          
</PRE>

        
</LI>


<LI>
         <STRONG>DIRECTIVE: &#34;order&#34;</STRONG><BR>

         <STRONG>Syntax:</STRONG> <CODE>order</CODE> allow deny | deny allow<BR>

         <STRONG>Default:</STRONG> allow deny<BR>

         <CODE>order</CODE>, defines if the deny or allow control shall
         be preformed first.
         <BR>

         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.
         <BR>

                 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.
         <BR>

        
</LI>


<LI>
         <STRONG>DIRECTIVE: &#34;require&#34;</STRONG>
                 <STRONG>Syntax:</STRONG> <CODE>require</CODE>
         group group1 group2...|user user1 user2...<BR>

         <STRONG>Default:</STRONG> <CODE> - None -</CODE><BR>

         <STRONG>Context:</STRONG> Limit<BR>

         <BR>


                 See the require directive in the documentation of mod_auth(3)
         for more information.
         <BR>

        
</LI>


</UL>
<A NAME="4.7"><!-- Empty --></A>
<H3>4.7 Dynamic Web Pages</H3>

<P>The Inets HTTP server provides two ways of creating dynamic web
pages, each with its own advantages and disadvantages. 
<P>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. 
<P>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. <A NAME="4.7.1"><!-- Empty --></A>
<H4>4.7.1 The Common Gateway Interface (CGI) Version 1.1,
        RFC 3875.</H4>

<P>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. 
<P> 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: 
<PRE>
&#34;Content-Type:text/plain\nAccept-Ranges:none\n\nsome very
        plain text&#34; 
</PRE>

<P> 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.
<P>Support for CGI-1.1 is implemented in accordance with the RFC
3875. <A NAME="4.7.2"><!-- Empty --></A>
<H4>4.7.2 Erlang Server Interface (ESI)</H4>

<P>The erlang server interface is implemented by the
        module mod_esi.<A NAME="4.7.2.1"><!-- Empty --></A>
<H5>4.7.2.1 ERL Scheme </H5>

<P>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): 
<PRE>
          http://your.server.org/***/Module[:/]Function(?QueryString|/PathInfo)
        
</PRE>

<P>*** above depends on how the ErlScriptAlias config
        directive has been used
<P>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 <A HREF="mod_esi.html">       mod_esi(3)</A> for implementation details of the esi
         callback function.<A NAME="4.7.2.2"><!-- Empty --></A>
<H5>4.7.2.2 EVAL Scheme </H5>

<P>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:
<PRE>
http://your.server.org/***/Mod:Func(Arg1,...,ArgN)
        
</PRE>

<P>*** above depends on how the ErlScriptAlias config
         directive has been used
<P>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 <A HREF="mod_esi.html">      mod_esi(3)</A> for implementation details of the esi
         callback function.
<P>
<TABLE CELLPADDING=4>
  <TR>
    <TD VALIGN=TOP><IMG ALT="Note!" SRC="note.gif"></TD>
    <TD>

<P> The eval scheme can seriously threaten the
         integrity of the Erlang node housing a Web server, for
         example: 
<PRE>
http://your.server.org/eval?httpd_example:print(atom_to_list(apply(erlang,halt,[])))
          
</PRE>

<P>which effectively will close down the Erlang node,
         that is use the erl scheme instead, until this
         security breach has been fixed.
<P>Today there are no good way of solving this problem
         and therefore Eval Scheme may be removed in future
         release of Inets.     </TD>
  </TR>
</TABLE>
<A NAME="4.8"><!-- Empty --></A>
<H3>4.8 Logging </H3>

<P> 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:


<P><STRONG>remotehost rfc931 authuser [date] &#34;request&#34; status bytes</STRONG>


<P>
<DL>

<DT>
<STRONG>remotehost</STRONG>

</DT>

<DD>
Remote hostname

</DD>

<DT>
<STRONG>rfc931</STRONG>

</DT>

<DD>
The client's remote username (RFC 931).

</DD>

<DT>
<STRONG>authuser</STRONG>

</DT>

<DD>
The username with which the user authenticated himself.

</DD>

<DT>
<STRONG>[date]</STRONG>

</DT>

<DD>
Date and time of the request (RFC 1123).

</DD>

<DT>
<STRONG>&#34;request&#34;</STRONG>

</DT>

<DD>
The request line exactly as it came from the client (RFC 1945).

</DD>

<DT>
<STRONG>status</STRONG>

</DT>

<DD>
The HTTP status code returned to the client (RFC 1945).

</DD>

<DT>
<STRONG>bytes</STRONG>

</DT>

<DD>
The content-length of the document transferred. 

</DD>

</DL>

<P>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:


<P><STRONG>[date]</STRONG> access to <STRONG>path</STRONG> failed for
<STRONG>remotehost</STRONG>, reason: <STRONG>reason</STRONG>
        
<A NAME="4.9"><!-- Empty --></A>
<H3>4.9 Server Side Includes</H3>

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

<P>
<TABLE CELLPADDING=4>
  <TR>
    <TD VALIGN=TOP><IMG ALT="Note!" SRC="note.gif"></TD>
    <TD>

<P>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.
    </TD>
  </TR>
</TABLE>
<A NAME="ssi_setup"><!-- Empty --></A><A NAME="4.9.1"><!-- Empty --></A>
<H4>4.9.1 SERVER-SIDE INCLUDES (SSI) SETUP</H4>

<P>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 <CODE>text/x-server-parsed-html</CODE>
        to identify parsed documents. It will then perform a format
        conversion to change these files into HTML for the
        client. Update the <CODE>mime.types</CODE> file, as described in the
        Mime Type Settings, to tell the server which extension to use
        for parsed files, for example:


<PRE>
        text/x-server-parsed-html shtml shtm
      
</PRE>

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

<PRE>
        text/x-server-parsed-html html htm
      
</PRE>
<A NAME="ssi_format"><!-- Empty --></A><A NAME="4.9.2"><!-- Empty --></A>
<H4>4.9.2 Server-Side Includes (SSI) Format</H4>

<P>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:
        

<PRE>
        &#60;!--#command tag1=&#34;value1&#34; tag2=&#34;value2&#34; --&#62;
      
</PRE>

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


<P>
<DL>

<DT>
<CODE>config</CODE>
        
</DT>

<DD>
The config directive controls various aspects of the
         file parsing. There are two valid tags:
         
        <BR>

<DL>

<DT>
<CODE>errmsg</CODE>
         
</DT>

<DD>
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. 
         <BR>

</DD>

<DT>
<CODE>sizefmt</CODE>
         
</DT>

<DD>
determines the format used to display the size of
                a file. Valid choices are <CODE>bytes</CODE> or
         <CODE>abbrev</CODE>. <CODE>bytes</CODE> for a formatted byte count
                or <CODE>abbrev</CODE> for an abbreviated version displaying
                the number of kilobytes.
        <BR>

</DD>

</DL>

         
        
</DD>

<DT>
<CODE>include</CODE>
        
</DT>

<DD>
will insert the text of a document into the parsed
         document. This command accepts two tags:

         <BR>

<DL>

<DT>
<CODE>virtual</CODE>
         
</DT>

<DD>
gives a virtual path to a document on the
                server. Only normal files and other parsed documents can
                be accessed in this way.
         <BR>

</DD>

<DT>
<CODE>file</CODE>
         
</DT>

<DD>
gives a pathname relative to the current
                directory. <CODE>../</CODE> cannot be used in this pathname, nor
                can absolute paths. As above, you can send other parsed
                documents, but you cannot send CGI scripts.
<BR>

</DD>

</DL>

         
        
</DD>

<DT>
<CODE>echo</CODE>
        
</DT>

<DD>
prints the value of one of the include variables
         (defined below). The only valid tag to this command is
         <CODE>var</CODE>, whose value is the name of the variable you wish
        to echo.
<BR>

</DD>

<DT>
<CODE>fsize</CODE>
        
</DT>

<DD>
prints the size of the specified file. Valid tags are
         the same as with the <CODE>include</CODE> command. The resulting
         format of this command is subject to the <CODE>sizefmt</CODE>
        parameter to the <CODE>config</CODE> command.
        <BR>

</DD>

<DT>
<CODE>flastmod</CODE>

</DT>

<DD>
prints the last modification date of the specified
         file. Valid tags are the same as with the <CODE>include</CODE>
         command.
        <BR>

</DD>

<DT>
<CODE>exec</CODE>
        
</DT>

<DD>
executes a given shell command or CGI script. Valid
         tags are:
         
         <BR>

<DL>

<DT>
<CODE>cmd</CODE>
         
</DT>

<DD>
executes the given string using <CODE>/bin/sh</CODE>. All
         of the variables defined below are defined, and can be
                used in the command.
         <BR>

</DD>

<DT>
<CODE>cgi</CODE>
         
</DT>

<DD>
executes the given virtual path to a CGI script and
         includes its output. The server does not perform error
                checking on the script output.
         <BR>

</DD>

</DL>

         

</DD>

</DL>
<A NAME="ssi_environment_variables"><!-- Empty --></A><A NAME="4.9.3"><!-- Empty --></A>
<H4>4.9.3 Server-Side Includes (SSI) Environment Variables</H4>

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

<P>
<DL>

<DT>
<CODE>DOCUMENT_NAME</CODE>
        
</DT>

<DD>
The current filename.
        <BR>

</DD>

<DT>
<CODE>DOCUMENT_URI</CODE>
        
</DT>

<DD>
The virtual path to this document (such as
         <CODE>/docs/tutorials/foo.shtml</CODE>).
<BR>

</DD>

<DT>
<CODE>QUERY_STRING_UNESCAPED</CODE>

        
</DT>

<DD>
The unescaped version of any search query the client
         sent, with all shell-special characters escaped with
         <CODE>\</CODE>.
        <BR>

</DD>

<DT>
<CODE>DATE_LOCAL</CODE>
        
</DT>

<DD>
The current date, local time zone.
<BR>

</DD>

<DT>
<CODE>DATE_GMT</CODE>
        
</DT>

<DD>
Same as DATE_LOCAL but in Greenwich mean time.
        <BR>

</DD>

<DT>
<CODE>LAST_MODIFIED</CODE>
        
</DT>

<DD>
The last modification date of the current document.
<BR>

</DD>

</DL>
<A NAME="4.10"><!-- Empty --></A>
<H3>4.10 The Erlang Webserver API</H3>

<P>The process of handling a HTTP request involves several steps
such as:
<P>
<UL>

<LI>
Seting up connections, sending and receiving data.
</LI>


<LI>
URI to filename translation
</LI>


<LI>
Authenication/access cheks.
</LI>


<LI>
Retriving/generating the response.
</LI>


<LI>
Logging
</LI>


</UL>

<P>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.
<P>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. 

<P>
<TABLE CELLPADDING=4>
  <TR>
    <TD VALIGN=TOP><IMG ALT="Note!" SRC="note.gif"></TD>
    <TD>

<P>Interaction data enforces module dependencies and
        should be avoided if possible. This means the order
of modules in the Modules config directive is significant.    </TD>
  </TR>
</TABLE>
<A NAME="4.10.1"><!-- Empty --></A>
<H4>4.10.1 API Description</H4>

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

<P>
<UL>

<LI>
do/1 (mandatory) - the function called when
        a request should be handled.
</LI>


<LI>
load/2
</LI>


<LI>
store/2
</LI>


<LI>
remove/1
</LI>


</UL>

<P>The latter functions are needed only when new config
        directives are to be introduced. For details see
        <A HREF="httpd.html"> httpd(3)</A><A NAME="4.11"><!-- Empty --></A>
<H3>4.11 Inets Webserver Modules</H3>

<P> 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.<A NAME="4.11.1"><!-- Empty --></A>
<H4>4.11.1 mod_action - Filetype/Method-Based Script
Execution.</H4>

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

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

<P>
<UL>

<LI>
 real_name - from mod_alias
</LI>


</UL>

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

<P>
<DL>

<DT>
<CODE>{new_request_uri, RequestURI}</CODE>
        
</DT>

<DD>
An alternative <CODE>RequestURI</CODE> has been generated.

</DD>

</DL>
<A NAME="4.11.2"><!-- Empty --></A>
<H4>4.11.2 mod_alias - URL Aliasing</H4>

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

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

<P>
<DL>

<DT>
<CODE>{real_name, PathData}</CODE> 
</DT>

<DD>
         PathData is the argument used for API function mod_alias:path/3.

</DD>

</DL>
<A NAME="4.11.3"><!-- Empty --></A>
<H4>4.11.3 mod_auth - User Authentication </H4>

<P> This module provides for basic user authentication using
textual files, dets databases as well as mnesia databases.
<P>Uses the following Erlang Webserver API interaction data, if available:


<P>
<UL>

<LI>
 real_name - from mod_alias
</LI>


</UL>

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

<P>
<DL>

<DT>
<CODE>{remote_user, User}</CODE>
        
</DT>

<DD>
The user name with which the user has authenticated himself.

</DD>

</DL>
<A NAME="4.11.4"><!-- Empty --></A>
<H4>4.11.4 mod_cgi - CGI Scripts</H4>

<P>This module handles invoking of CGI scripts<A NAME="4.11.5"><!-- Empty --></A>
<H4>4.11.5 mod_dir - Directories</H4>

<P>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.

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


<P>
<UL>

<LI>
 real_name - from mod_alias
</LI>


</UL>

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

<P>
<DL>

<DT>
<CODE>{mime_type, MimeType}</CODE>
        
</DT>

<DD>
The file suffix of the incoming URL mapped into a
         <CODE>MimeType</CODE>.

</DD>

</DL>
<A NAME="4.11.6"><!-- Empty --></A>
<H4>4.11.6 mod_disk_log - Logging Using disk_log.</H4>

<P>Standard logging using the &#34;Common Logfile Format&#34; and
        disk_log(3).
<P>Uses the following Erlang Webserver API interaction data, if available:


<P>
<UL>

<LI>
 remote_user - from mod_auth
</LI>


</UL>
<A NAME="4.11.7"><!-- Empty --></A>
<H4>4.11.7 mod_esi - Erlang Server Interface</H4>

<P> This module implements
        the Erlang Server Interface (ESI) that provides a tight and
        efficient interface to the execution of Erlang functions. 
<P>Uses the following Erlang Webserver API interaction data, if available:


<P>
<UL>

<LI>
 remote_user - from mod_auth
</LI>


</UL>

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


<P>
<DL>

<DT>
<CODE>{mime_type, MimeType}</CODE>
        
</DT>

<DD>
The file suffix of the incoming URL mapped into a
         <CODE>MimeType</CODE> 

</DD>

</DL>
<A NAME="4.11.8"><!-- Empty --></A>
<H4>4.11.8 mod_get - Regular GET Requests</H4>

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

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

<P>
<UL>

<LI>
 real_name - from mod_alias
</LI>


</UL>
<A NAME="4.11.9"><!-- Empty --></A>
<H4>4.11.9 mod_head - Regular HEAD Requests</H4>

<P>     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.

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


<P>
<UL>

<LI>
 real_name - from mod_alias
</LI>


</UL>
<A NAME="4.11.10"><!-- Empty --></A>
<H4>4.11.10 mod_htacess - User Configurable Access</H4>

<P>This module provides per-directory user configurable access
control.
<P>Uses the following Erlang Webserver API interaction data, if available:


<P>
<UL>

<LI>
 real_name - from mod_alias
</LI>


</UL>

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

<P>
<DL>

<DT>
<CODE>{remote_user_name, User}</CODE>
        
</DT>

<DD>
The user name with which the user has authenticated himself.

</DD>

</DL>
<A NAME="4.11.11"><!-- Empty --></A>
<H4>4.11.11 mod_include - SSI</H4>

<P>This module makes it possible to expand &#34;macros&#34; embedded in
HTML pages before they are delivered to the client, that is
Server-Side Includes (SSI).


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

<P>
<UL>

<LI>
 real_name - from mod_alias
</LI>


<LI>
 remote_user - from mod_auth
</LI>


</UL>

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

<P>
<DL>

<DT>
<CODE>{mime_type, MimeType}</CODE>
        
</DT>

<DD>
The file suffix of the incoming URL mapped into a
         <CODE>MimeType</CODE> as defined in the Mime Type Settings
         section.

</DD>

</DL>
<A NAME="4.11.12"><!-- Empty --></A>
<H4>4.11.12 mod_log - Logging Using Text Files.</H4>

<P> Standard logging using the &#34;Common Logfile Format&#34; and text
files.
<P>Uses the following Erlang Webserver API interaction data, if available:


<P>
<UL>

<LI>
 remote_user - from mod_auth
</LI>


</UL>
<A NAME="4.11.13"><!-- Empty --></A>
<H4>4.11.13 mod_range - Requests with Range Headers</H4>

<P>     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.
<P>Note that request for multiple parts of a document will report a
        size of zero to the log file.
<P>Uses the following Erlang Webserver API interaction data, if available:
        

<P>
<UL>

<LI>
 real_name - from mod_alias
</LI>


</UL>
<A NAME="4.11.14"><!-- Empty --></A>
<H4>4.11.14 mod_response_control - Requests with If* Headers</H4>

<P>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.

<P>     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.<BR>

        1.If-modified<BR>

        2.If-Unmodified<BR>

        3.If-Match<BR>

        4.If-Nomatch<BR>


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

<P>
<UL>

<LI>
 real_name - from mod_alias
</LI>


</UL>

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

<P>
<DL>

<DT>
<CODE>{if_range, send_file}</CODE>
        
</DT>

<DD>
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.

</DD>

</DL>
<A NAME="4.11.15"><!-- Empty --></A>
<H4>4.11.15 mod_security - Security Filter</H4>

<P>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. 
<P>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.
<A NAME="4.11.16"><!-- Empty --></A>
<H4>4.11.16 mod_trace - TRACE Request</H4>

<P>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.<CENTER>
<HR>
<SMALL>
Copyright &copy; 1991-2006
<A HREF="http://www.erlang.se">Ericsson AB</A><BR>
</SMALL>
</CENTER>
</BODY>
</HTML>