diff options
Diffstat (limited to 'lib/inets/doc/src/http_server.xml')
| -rw-r--r-- | lib/inets/doc/src/http_server.xml | 1078 |
1 files changed, 442 insertions, 636 deletions
diff --git a/lib/inets/doc/src/http_server.xml b/lib/inets/doc/src/http_server.xml index f29b505bc7..aeda961714 100644 --- a/lib/inets/doc/src/http_server.xml +++ b/lib/inets/doc/src/http_server.xml @@ -1,97 +1,87 @@ -<?xml version="1.0" encoding="iso-8859-1" ?> +<?xml version="1.0" encoding="utf-8" ?> <!DOCTYPE chapter SYSTEM "chapter.dtd"> <chapter> <header> <copyright> - <year>2004</year><year>2011</year> + <year>2004</year><year>2015</year> <holder>Ericsson AB. All Rights Reserved.</holder> </copyright> <legalnotice> - The contents of this file are subject to the Erlang Public License, - Version 1.1, (the "License"); you may not use this file except in - compliance with the License. You should have received a copy of the - Erlang Public License along with this software. If not, it can be - retrieved online at http://www.erlang.org/. - - Software distributed under the License is distributed on an "AS IS" - basis, WITHOUT WARRANTY OF ANY KIND, either express or implied. See - the License for the specific language governing rights and limitations - under the License. + Licensed under the Apache License, Version 2.0 (the "License"); + you may not use this file except in compliance with the License. + You may obtain a copy of the License at + + http://www.apache.org/licenses/LICENSE-2.0 + + Unless required by applicable law or agreed to in writing, software + distributed under the License is distributed on an "AS IS" BASIS, + WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + See the License for the specific language governing permissions and + limitations under the License. </legalnotice> - - <title>HTTP server </title> - <prepared>Ingela Anderton Andin</prepared> - <responsible></responsible> - <docno></docno> - <approved></approved> - <checked></checked> - <date></date> - <rev></rev> + <title>HTTP server</title> <file>http_server.xml</file> - - <marker id="intro"></marker> </header> <section> - <title>Introduction</title> - + <title>Configuration</title> + <marker id="config"></marker> <p>The HTTP server, also referred to as httpd, handles HTTP requests - as described in RFC 2616 with a few exceptions such as gateway - and proxy functionality. The server supports ipv6 as long as the - underlying mechanisms also do so. </p> - - <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> - - <p>The configuration of the server is provided as an erlang - property list, and for backwards compatibility also a configuration + as described in + <url href="http://www.ietf.org/rfc/rfc2616.txt">RFC 2616</url> + with a few exceptions, such as gateway + and proxy functionality. The server supports IPv6 as long as the + underlying mechanisms also do so.</p> + + <p>The server implements numerous features, such as:</p> + <list type="bulleted"> + <item>Secure Sockets Layer (SSL)</item> + <item>Erlang Scripting Interface (ESI)</item> + <item>Common Gateway Interface (CGI)</item> + <item>User Authentication (using <c>Mnesia</c>, + <c>Dets</c> or plain text database)</item> + <item>Common Logfile Format (with or without disk_log(3) support)</item> + <item>URL Aliasing</item> + <item>Action Mappings</item> + <item>Directory Listings</item> + </list> + + <p>The configuration of the server is provided as an Erlang + property list. For backwards compatibility, a configuration file using apache-style configuration directives is supported.</p> - <p>As of inets version 5.0 the HTTP server is an easy to - start/stop and customize web server that provides the most basic - web server functionality. Depending on your needs there - are also other erlang based web servers that may be of interest - such as Yaws, http://yaws.hyber.org, that for instance has its own - markup support to generate html, and supports certain buzzword - technologies such as SOAP.</p> + <p>As of <c>Inets</c> 5.0 the HTTP server is an easy to + start/stop and customize web server providing the most basic + web server functionality. Inets is designed for embedded systems + and if you want a full-fledged web server there are exists other + erlang open source alternatives.</p> - <p>Allmost all server functionality has been implemented using an - especially crafted server API which is described in the Erlang Web - Server API. This API can be used to advantage by all who wish + <p>Almost all server functionality has been implemented using an + especially crafted server API, which is described in the Erlang Web + Server API. This API can be used to enhance the core server functionality, for example with custom logging and authentication.</p> - <marker id="config"></marker> - </section> - - <section> - <title>Configuration</title> - - <p> What to put in the erlang node application configuration file - in order to start a http server at application startup.</p> + <p>The following is to be put in the Erlang node application configuration + file to start an HTTP server at application startup:</p> <code type="erl"> [{inets, [{services, [{httpd, [{proplist_file, "/var/tmp/server_root/conf/8888_props.conf"}]}, {httpd, [{proplist_file, - "/var/tmp/server_root/conf/8080_props.conf"}]}]}]}]. - </code> - - <p>The server is configured using an erlang property list. - For the available properties see - <seealso marker="httpd">httpd(3)</seealso> - For backwards compatibility also apache-like config files - are supported. + "/var/tmp/server_root/conf/8080_props.conf"}]}]}]}].</code> + + <p>The server is configured using an Erlang property list. + For the available properties, see + <seealso marker="httpd">httpd(3)</seealso>. + For backwards compatibility, apache-like configuration files + are also supported. </p> - <p>All possible config properties are as follows </p> + <p>The available configuration properties are as follows:</p> <code type="none"> httpd_service() -> {httpd, httpd()} httpd() -> [httpd_config()] @@ -103,40 +93,43 @@ debug_options() -> {all_functions, modules()} | {exported_functions, modules()} | {disable, modules()} - modules() -> [atom()] - </code> - <p>{proplist_file, file()} File containing an erlang property + modules() -> [atom()]</code> + <p>Here:</p> + <taglist> + <tag><c>{file, file()}</c></tag> + <item><p>If you use an old apace-like configuration file.</p></item> + <tag><c>{proplist_file, file()}</c></tag> + <item><p>File containing an Erlang property list, followed by a full stop, describing the HTTP server - configuration.</p> - <p>{file, file()} If you use an old apace-like configuration file.</p> - <p>{debug, debug()} - Can enable trace on all - functions or only exported functions on chosen modules.</p> - <p>{accept_timeout, integer()} sets the wanted timeout value for - the server to set up a request connection.</p> - - <marker id="using_http_server_api"></marker> + configuration.</p></item> + <tag><c>{debug, debug()}</c></tag> + <item><p>Can enable trace on all functions or only exported functions + on chosen modules.</p></item> + <tag><c>{accept_timeout, integer()}</c></tag> + <item><p>Sets the wanted time-out value for + the server to set up a request connection.</p></item> + </taglist> </section> <section> - <title>Using the HTTP Server API</title> + <title>Getting Started</title> + <marker id="using_http_server_api"></marker> + <p>Start <c>Inets</c>:</p> <code type="none"> 1 > inets:start(). - ok - </code> - <p> Start a HTTP server with minimal - required configuration. Note that if you - specify port 0 an arbitrary available port will be - used and you can use the info function to find out - which port number that was picked. - </p> + ok</code> + <p>Start an HTTP server with minimal required configuration. + If you specify port <c>0</c>, an arbitrary available port is + used, and you can use function <c>info</c> to find which port + number that was picked:</p> <code type="none"> 2 > {ok, Pid} = inets:start(httpd, [{port, 0}, {server_name,"httpd_test"}, {server_root,"/tmp"}, {document_root,"/tmp/htdocs"}, {bind_address, "localhost"}]). - {ok, 0.79.0} - </code> + {ok, 0.79.0} </code> + <p>Call <c>info</c>:</p> <code type="none"> 3 > httpd:info(Pid). [{mime_types,[{"html","text/html"},{"htm","text/html"}]}, @@ -144,571 +137,404 @@ {bind_address, {127,0,0,1}}, {server_root,"/tmp"}, {port,59408}, - {document_root,"/tmp/htdocs"}] - </code> + {document_root,"/tmp/htdocs"}]</code> - <p> Reload the configuration without restarting the server. - Note port and bind_address can not be changed. Clients - trying to access the server during the reload will - get a service temporary unavailable answer. + <p>Reload the configuration without restarting the server: + </p> <code type="none"> 4 > httpd:reload_config([{port, 59408}, {server_name,"httpd_test"}, {server_root,"/tmp/www_test"}, {document_root,"/tmp/www_test/htdocs"}, {bind_address, "localhost"}], non_disturbing). - ok. - </code> + ok.</code> + + <note><p><c>port</c> and <c>bind_address</c> cannot be changed. + Clients trying to access the server during the reload + get a service temporary unavailable answer.</p></note> <code type="none"> 5 > httpd:info(Pid, [server_root, document_root]). - [{server_root,"/tmp/www_test"},{document_root,"/tmp/www_test/htdocs"}] - </code> + [{server_root,"/tmp/www_test"},{document_root,"/tmp/www_test/htdocs"}] </code> <code type="none"> - 6 > ok = inets:stop(httpd, Pid). - </code> + 6 > ok = inets:stop(httpd, Pid).</code> - <p> Alternative:</p> + <p>Alternative:</p> <code type="none"> - 6 > ok = inets:stop(httpd, {{127,0,0,1}, 59408}). - </code> + 6 > ok = inets:stop(httpd, {{127,0,0,1}, 59408}).</code> - <p>Note that bind_address has to be - the ip address reported by the info function and can - not be the hostname that is allowed when inputting bind_address.</p> - - <marker id="htaccess"></marker> + <p>Notice that <c>bind_address</c> must be the IP address reported + by function <c>info</c> and cannot be the hostname that is allowed + when putting in <c>bind_address</c>.</p> </section> <section> - <title>Htaccess - User Configurable Authentication.</title> - <p>If users of the web server needs to manage authentication of - web pages 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> + <title>Htaccess - User Configurable Authentication</title> + <marker id="htaccess"></marker> + <p>Web server users without server administrative privileges + that need to manage authentication of web pages that are local + to their user can use the per-directory runtime configurable + user-authentication scheme <c>htaccess</c>. + It works as follows:</p> <list type="bulleted"> <item>Each directory in the path to the requested asset is - searched for an access-file (default .htaccess), that restricts - the web servers rights to respond to a request. If an access-file - is found the rules in that file is applied to the - request. </item> - <item>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.</item> - <item>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.</item> - <item>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.</item> - <item>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 succeed.</item> + searched for an access file (default is <c>.htaccess</c>), which + restricts the web servers rights to respond to a request. + If an access file is found, the rules in that file is applied to the + request.</item> + <item>The rules in an access file apply to files in the same + directory 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 is applied.</item> + <item>To change the rules that restrict the use of + an asset, the user only needs write access + to the directory where the asset is.</item> + <item>All access files in the path to a requested asset are read + once per request. This means that the load on the server + increases when <c>htaccess</c> is used.</item> + <item>If a directory is limited both by authentication directives + in the HTTP server configuration file and by the <c>htaccess</c> + files, the user must be allowed to get access to the file by both + methods for the request to succeed.</item> </list> <section> <title>Access Files Directives</title> - <p>In every directory under the <c>DocumentRoot</c> or under an - <c>Alias</c> 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 web server 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> - <list type="bulleted"> + <p>In every directory under <c>DocumentRoot</c> or under an + <c>Alias</c> a user can place an access file. An access file + is a plain text file that specifies the restrictions to + consider before the web server answers 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 is used.</p> + <taglist> + <tag><em>"allow"</em></tag> <item> - <p><em>DIRECTIVE: "allow"</em></p> - <p><em>Syntax:</em><c>Allow</c> from subnet subnet|from all <br></br> -<em>Default:</em><c>from all </c> <br></br> -</p> - <p>Same as the directive allow for the server config file. </p> + <p><em>Syntax:</em> <c>Allow</c> from subnet <c>subnet | from all</c></p> + <p><em>Default:</em> <c>from all</c></p> + <p>Same as directive <c>allow</c> for the server configuration file.</p> </item> - <item> - <p><em>DIRECTIVE: "AllowOverRide"</em></p> - <p><em>Syntax:</em><c>AllowOverRide</c> all | none | - Directives <br></br> -<em>Default:</em><c>- None -</c> <br></br> -<c>AllowOverRide</c> 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. + <tag><em>"AllowOverRide"</em></tag> + <item> + <p><em>Syntax:</em> <c>AllowOverRide</c> <c>all | none | Directives</c></p> + <p><em>Default:</em> <c>none</c></p> + <p><c>AllowOverRide</c> specifies the parameters that + access files in subdirectories are not allowed to alter the value + for. If the parameter is set to <c>none</c>, no further + access files is parsed. </p> - <p>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.</p> + <p>If only one access file exists, setting this parameter to + <c>none</c> can ease the burden on the server as the server + then stops looking for access files.</p> </item> + <tag><em>"AuthGroupfile"</em></tag> <item> - <p><em>DIRECTIVE: "AuthGroupfile"</em></p> - <p><em>Syntax:</em><c>AuthGroupFile</c> Filename <br></br> -<em>Default:</em><c>- None -</c> <br></br> -</p> - <p>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 + <p><em>Syntax:</em> <c>AuthGroupFile</c> Filename</p> + <p><em>Default:</em> <c>none</c></p> + <p><c>AuthGroupFile</c> indicates which file that contains the list + of groups. The 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:</p> + of the group, separated by a space, for example:</p> <pre> -GroupName: Member1 Member2 .... MemberN - </pre> +GroupName: Member1 Member2 .... MemberN</pre> </item> + <tag><em>"AuthName"</em></tag> <item> - <p><em>DIRECTIVE: "AuthName"</em></p> - <p><em>Syntax:</em><c>AuthName</c> auth-domain <br></br> -<em>Default:</em><c>- None -</c> <br></br> -</p> - <p>Same as the directive AuthName for the server config file. </p> + <p><em>Syntax:</em> <c>AuthName</c> auth-domain</p> + <p><em>Default:</em> <c>none</c></p> + <p>Same as directive <c>AuthName</c> for the server + configuration file.</p> </item> + <tag><em>"AuthType"</em></tag> <item> - <p><em>DIRECTIVE: "AuthType"</em></p> - <p><em>Syntax:</em><c>AuthType</c> Basic <br></br> -<em>Default:</em><c>Basic</c> <br></br> -</p> - <p><c>AuthType</c> Specify which authentication scheme that shall - be used. Today only Basic Authenticating using UUEncoding of - the password and user ID is implemented. </p> + <p><em>Syntax:</em> <c>AuthType</c> <c>Basic</c></p> + <p><em>Default:</em> <c>Basic</c></p> + <p><c>AuthType</c> specifies which authentication scheme to + be used. Only Basic Authenticating using UUEncoding of + the password and user ID is implemented.</p> </item> + <tag><em>"AuthUserFile"</em></tag> <item> - <p><em>DIRECTIVE: "AuthUserFile"</em></p> - <p><em>Syntax:</em><c>AuthUserFile</c> Filename <br></br> -<em>Default:</em><c>- None -</c> <br></br> -</p> - <p><c>AuthUserFile</c> 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 + <p><em>Syntax:</em> <c>AuthUserFile</c> Filename</p> + <p><em>Default:</em><c>none</c></p> + <p><c>AuthUserFile</c> indicates which file that contains the list + of users. The filename must contain the absolute path to the + file. The username and password are not encrypted so do not place the file with users in a directory that is accessible - via the web server. The format of the file is one user per row - and every row contains User Name and Password separated by a - colon, for example:</p> + through the web server. The format of the file is one user per row. + Every row contains <c>UserName</c> and <c>Password</c> separated + by a colon, for example:</p> <pre> UserName:Password -UserName:Password - </pre> +UserName:Password</pre> </item> + <tag><em>"deny"</em></tag> <item> - <p><em>DIRECTIVE: "deny"</em></p> - <p><em>Syntax:</em><c>deny</c> from subnet subnet|from all <br></br> -<em>Context:</em> Limit</p> - <p>Same as the directive deny for the server config file. </p> + <p><em>Syntax:</em> <c>deny</c> from subnet <c>subnet | from all</c></p> + <p><em>Context:</em> Limit</p> + <p>Same as directive <c>deny</c> for the server configuration file.</p> </item> - <item> - <p><em>DIRECTIVE: "Limit"</em> <br></br> -</p> - <p><em>Syntax:</em><c><![CDATA[<Limit]]></c> RequestMethods<c>></c> <br></br> -<em>Default:</em> - None - <br></br> -</p> - <p><c><![CDATA[<Limit>]]></c> 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 + <tag><em>"Limit"</em></tag> + <item> + <p><em>Syntax:</em> <c><![CDATA[<Limit]]></c> RequestMethods<c>></c></p> + <p><em>Default:</em> <c>none</c></p> + <p><c><![CDATA[<Limit>]]></c> and <c></Limit></c> are used to enclose + a group of directives applying only to requests using + the specified methods. If no request method is specified, all request methods are verified against the restrictions.</p> + <p>Example:</p> <pre> <Limit POST GET HEAD> order allow deny require group group1 allow from 123.145.244.5 -</Limit> - </pre> +</Limit></pre> </item> - <item> - <p><em>DIRECTIVE: "order"</em> <br></br> -<em>Syntax:</em><c>order</c> allow deny | deny allow <br></br> -<em>Default:</em> allow deny <br></br> -</p> - <p><c>order</c>, defines if the deny or allow control shall - be preformed first.</p> - <p>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.</p> - <p>If the order is set to deny allow then only users from networks - specified to be in the allowed subset will succeed to request + <tag><em>"order"</em></tag> + <item> + <p><em>Syntax:</em> <c>order</c> <c>allow deny | deny allow</c></p> + <p><em>Default:</em> <c>allow deny</c></p> + <p><c>order</c> defines if the deny or allow control is to + be performed first.</p> + <p>If the order is set to <c>allow deny</c>, the users + network address is first controlled to be in the allow subset. + If the user network address is not in the allowed subset, the user + is denied to get the asset. If the network address is in the + allowed subset, a second control is performed. That is, + the user network address is not in the subset of network + addresses to be denied as specified by parameter <c>deny</c>.</p> + <p>If the order is set to <c>deny allow</c>, only users from networks + specified to be in the allowed subset succeeds to request assets in the limited area.</p> </item> - <item> - <p><em>DIRECTIVE: "require"</em></p> - <p><em>Syntax:</em><c>require</c> - group group1 group2...|user user1 user2... <br></br> -<em>Default:</em><c>- None -</c> <br></br> -<em>Context:</em> Limit <br></br> -</p> - <p>See the require directive in the documentation of mod_auth(3) - for more information.</p> + <tag><em>"require"</em></tag> + <item> + <p><em>Syntax:</em> <c>require</c> + <c>group group1 group2... | user user1 user2...</c></p> + <p><em>Default:</em> <c>none</c></p> + <p><em>Context:</em> Limit</p> + <p>For more information, see directive <c>require</c> in + <seealso marker="mod_auth">mod_auth(3)</seealso>.</p> </item> - </list> + </taglist> </section> - - <marker id="dynamic_we_pages"></marker> </section> <section> <title>Dynamic Web Pages</title> - <p>The Inets HTTP server provides two ways of creating dynamic web - pages, each with its own advantages and disadvantages. </p> - <p>First there are CGI-scripts that can be written in any programming - language. CGI-scripts are standardized and supported by most - web servers. 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> - <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. </p> - + <marker id="dynamic_we_pages"></marker> + <p><c>Inets</c> HTTP server provides two ways of creating dynamic web + pages, each with its own advantages and disadvantages:</p> + <taglist> + <tag><em>CGI scripts</em></tag> + <item><p>Common Gateway Interface (CGI) scripts can be written + in any programming language. CGI scripts are standardized and + supported by most web servers. 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></item> + <tag><em>ESI-functions</em></tag> + <item><p>Erlang Server Interface (ESI) functions provide a tight and efficient + interface to the execution of Erlang functions. This interface, + on the other hand, is <c>Inets</c> specific.</p></item> + </taglist> + <section> - <title>The Common Gateway Interface (CGI) Version 1.1, RFC 3875.</title> - <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 + <title>CGI Version 1.1, RFC 3875</title> + <p>The module <c>mod_cgi</c> enables execution of + <url href="http://www.ietf.org/rfc/rfc3875.txt">CGI scripts</url> + on the server. A file matching the definition of a + ScriptAlias config directive is treated as a CGI script. A CGI script is executed by the server and its output is returned to - the client. </p> - <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: </p> + the client.</p> + <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 can be + empty.</p> + <p>Example:</p> <code>"Content-Type:text/plain\nAccept-Ranges:none\n\nsome very - plain text" </code> + plain text"</code> - <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> - <p>Support for CGI-1.1 is implemented in accordance with the RFC - 3875. </p> + <p>The server interprets the message headers and most of them + are transformed into HTTP headers and sent back to the + client together with the message-body.</p> + <p>Support for CGI-1.1 is implemented in accordance with + <url href="http://www.ietf.org/rfc/rfc3875.txt">RFC 3875</url>.</p> </section> <section> - <title>Erlang Server Interface (ESI)</title> - <p>The erlang server interface is implemented by the - module mod_esi.</p> + <title>ESI</title> + <p>The Erlang server interface is implemented by + module <c>mod_esi</c>.</p> <section> - <title>ERL Scheme </title> + <title>ERL Scheme</title> <p>The erl scheme is designed to mimic plain CGI, but without - the extra overhead. An URL which calls an Erlang erl function + the extra overhead. An URL that calls an Erlang <c>erl</c> function has the following syntax (regular expression): </p> <code type="none"> -http://your.server.org/***/Module[:/]Function(?QueryString|/PathInfo) - </code> - <p>*** above depends on how the ErlScriptAlias config - directive has been used</p> - <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 permits you to send chunks of the - webpage beeing generated to the client during the generation +http://your.server.org/***/Module[:/]Function(?QueryString|/PathInfo)</code> + <p>*** depends on how the ErlScriptAlias config + directive has been used.</p> + <p>The module <c>Module</c> referred to must be found in the code + path, and it must define a function <c>Function</c> with an arity + of two or three. It is preferable to implement a function + with arity three, as it permits to send chunks of the + web page 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 kept for backwards compatibility reasons. - See <seealso marker="mod_esi">mod_esi(3)</seealso> for - implementation details of the esi callback function.</p> + For implementation details of the ESI callback function, + see <seealso marker="mod_esi">mod_esi(3)</seealso>.</p> </section> <section> - <title>EVAL Scheme </title> + <title>EVAL Scheme</title> <p>The eval scheme is straight-forward and does not mimic the - behavior of plain CGI. An URL which calls an Erlang eval + behavior of plain CGI. An URL that calls an Erlang <c>eval</c> function has the following syntax:</p> <code type="none"> -http://your.server.org/***/Mod:Func(Arg1,...,ArgN) - </code> - <p>*** above depends on how the ErlScriptAlias config - directive has been used</p> - <p>The module (Mod) referred to must be found in the code - path, and data returned by the function (Func) is passed +http://your.server.org/***/Mod:Func(Arg1,...,ArgN)</code> + <p>*** depends on how the ErlScriptAlias config + directive has been used.</p> + <p>The module <c>Mod</c> referred to must be found in the code + path and data returned by the function <c>Func</c> is passed back to the client. Data returned from the - function must furthermore take the form as specified in - the CGI specification. See <seealso marker="mod_esi">mod_esi(3)</seealso> for implementation details of the esi - callback function.</p> + function must take the form as specified in + the CGI specification. For implementation details of the ESI + callback function, + see <seealso marker="mod_esi">mod_esi(3)</seealso>.</p> <note> <p>The eval scheme can seriously threaten the - integrity of the Erlang node housing a Web server, for - example: </p> + integrity of the Erlang node housing a web server, for + example:</p> <code type="none"> -http://your.server.org/eval?httpd_example:print(atom_to_list(apply(erlang,halt,[]))) - </code> - <p>which effectively will close down the Erlang node, - therefor, use the erl scheme instead, until this - security breach has been fixed.</p> - <p>Today there are no good way of solving this problem - and therefore Eval Scheme may be removed in future - release of Inets. </p> +http://your.server.org/eval?httpd_example:print(atom_to_list(apply(erlang,halt,[])))</code> + <p>This effectively closes down the Erlang node. + Therefore, use the erl scheme instead, until this + security breach is fixed.</p> + <p>Today there are no good ways of solving this problem + and therefore the eval scheme can be removed in future + release of <c>Inets</c>.</p> </note> </section> </section> - - <marker id="logging"></marker> </section> <section> - <title>Logging </title> - <p>There are three types of logs supported. Transfer logs, - security logs and error logs. The de-facto standard Common + <title>Logging</title> + <marker id="logging"></marker> + <p>Three types of logs are 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> <p><em>remotehost rfc931 authuser [date] "request" status bytes</em></p> + <p>Here:</p> <taglist> <tag><em>remotehost</em></tag> - <item>Remote hostname</item> + <item>Remote hostname.</item> <tag><em>rfc931</em></tag> - <item>The client's remote username (RFC 931).</item> + <item>The client remote username (<url href="http://www.ietf.org/rfc/rfc931.txt">RFC 931</url>).</item> <tag><em>authuser</em></tag> - <item>The username with which the user authenticated himself.</item> + <item>The username used for authentication.</item> <tag><em>[date]</em></tag> - <item>Date and time of the request (RFC 1123).</item> + <item>Date and time of the request (<url href="http://www.ietf.org/rfc/rfc1123.txt">RFC 1123</url>).</item> <tag><em>"request"</em></tag> - <item>The request line exactly as it came from the client (RFC 1945).</item> + <item>The request line exactly as it came from the client (<url href="http://www.ietf.org/rfc/rfc1945.txt">RFC 1945</url>).</item> <tag><em>status</em></tag> - <item>The HTTP status code returned to the client (RFC 1945).</item> + <item>The HTTP status code returned to the client (<url href="http://www.ietf.org/rfc/rfc1945.txt">RFC 1945</url>).</item> <tag><em>bytes</em></tag> <item>The content-length of the document transferred. </item> </taglist> <p>Internal server errors are recorded in the error log file. The - format of this file is a more ad hoc format than the logs using + format of this file is a more unplanned format than the logs using Common Logfile Format, but conforms to the following syntax: </p> <p><em>[date]</em> access to <em>path</em> failed for <em>remotehost</em>, reason: <em>reason</em></p> - - <marker id="ssi"></marker> </section> - + <section> - <title>Server Side Includes</title> - <p>Server Side Includes enables the server to run code embedded - in HTML pages to generate the response to the client.</p> - <note> - <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.</p> - </note> - - <section> - <marker id="ssi_setup"></marker> - <title>SERVER-SIDE INCLUDES (SSI) SETUP</title> - <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 <c>text/x-server-parsed-html</c> - to identify parsed documents. It will then perform a format - conversion to change these files into HTML for the - client. Update the <c>mime.types</c> file, as described in the - Mime Type Settings, to tell the server which extension to use - for parsed files, for example: - </p> - <pre> - text/x-server-parsed-html shtml shtm - </pre> - <p>This makes files ending with <c>.shtml</c> and <c>.shtm</c> - into parsed files. Alternatively, if the performance hit is not a - problem, <em>all</em> HTML pages can be marked as parsed: - </p> - <pre> - text/x-server-parsed-html html htm - </pre> - </section> - - <section> - <marker id="ssi_format"></marker> - <title>Server-Side Includes (SSI) Format</title> - <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: - </p> - <pre> - <!--#command tag1="value1" tag2="value2" --> - </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> - <p>The config directive controls various aspects of the - file parsing. There are two valid tags: - </p> - <taglist> - <tag><c>errmsg</c></tag> - <item> - <p>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.</p> - </item> - <tag><c>sizefmt</c></tag> - <item> - <p>determines the format used to display the size of - a file. Valid choices are <c>bytes</c> or - <c>abbrev</c>. <c>bytes</c> for a formatted byte count - or <c>abbrev</c> for an abbreviated version displaying - the number of kilobytes.</p> - </item> - </taglist> - <p>The include directory - will insert the text of a document into the parsed - document. This command accepts two tags:</p> - <taglist> - <tag><c>virtual</c></tag> - <item> - <p>gives a virtual path to a document on the - server. Only normal files and other parsed documents can - be accessed in this way.</p> - </item> - <tag><c>file</c></tag> - <item> - <p>gives a pathname relative to the current - directory. <c>../</c> cannot be used in this pathname, nor - can absolute paths. As above, you can send other parsed - documents, but you cannot send CGI scripts.</p> - </item> - </taglist> - <p>The echo directive prints the value of one of the include - variables (defined below). The only valid tag to this - command is <c>var</c>, whose value is the name of the - variable you wish to echo.</p> - <p>The fsize directive prints the size of the specified - file. Valid tags are the same as with the <c>include</c> - command. The resulting format of this command is subject - to the <c>sizefmt</c> parameter to the <c>config</c> - command.</p> - <p>The lastmod directive prints the last modification date of - the specified file. Valid tags are the same as with the - <c>include</c> command.</p> - <p>The exec directive executes a given shell command or CGI - script. Valid tags are:</p> - <taglist> - <tag><c>cmd</c></tag> - <item> - <p>executes the given string using <c>/bin/sh</c>. All - of the variables defined below are defined, and can be - used in the command.</p> - </item> - <tag><c>cgi</c></tag> - <item> - <p>executes the given virtual path to a CGI script and - includes its output. The server does not perform error - checking on the script output.</p> - </item> - </taglist> - </section> - - <section> - <marker id="ssi_environment_variables"></marker> - <title>Server-Side Includes (SSI) Environment Variables</title> - <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> - <taglist> - <tag><c>DOCUMENT_NAME</c></tag> - <item> - <p>The current filename.</p> - </item> - <tag><c>DOCUMENT_URI</c></tag> - <item> - <p>The virtual path to this document (such as - <c>/docs/tutorials/foo.shtml</c>).</p> - </item> - <tag><c>QUERY_STRING_UNESCAPED</c></tag> - <item> - <p>The unescaped version of any search query the client - sent, with all shell-special characters escaped with - <c>\</c>.</p> - </item> - <tag><c>DATE_LOCAL</c></tag> - <item> - <p>The current date, local time zone.</p> - </item> - <tag><c>DATE_GMT</c></tag> - <item> - <p>Same as DATE_LOCAL but in Greenwich mean time.</p> - </item> - <tag><c>LAST_MODIFIED</c></tag> - <item> - <p>The last modification date of the current document.</p> - </item> - </taglist> - </section> - </section> - - <section> - <title>The Erlang Web Server API</title> - <p>The process of handling a HTTP request involves several steps + <title>Erlang Web Server API</title> + <p>The process of handling an HTTP request involves several steps, such as:</p> <list type="bulleted"> - <item>Seting up connections, sending and receiving data.</item> - <item>URI to filename translation</item> - <item>Authenication/access checks.</item> - <item>Retriving/generating the response.</item> - <item>Logging</item> + <item>Setting up connections, sending and receiving data.</item> + <item>URI to filename translation.</item> + <item>Authentication/access checks.</item> + <item>Retrieving/generating the response.</item> + <item>Logging.</item> </list> - <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 of course - 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 functionality and are - not implemented using the Erlang Web Server API. A description of - functionality implemented by the Erlang Webserver API is described - in the section Inets Webserver Modules.</p> + <p>To provide customization and extensibility of the request + handling of the HTTP servers, most of these steps are handled by + one or more modules. These modules can be replaced or removed at + runtime and new ones can be added. For each request, all modules are + traversed in the order specified by the module directive in the + server configuration file. Some parts, mainly the communication- + related steps, are considered server core functionality and are + not implemented using the Erlang web server API. A description of + functionality implemented by the Erlang webserver API is described + in <seealso marker="#Inets_Web_Server_Modules">Section + Inets Web Server Modules</seealso>.</p> + <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 Web Server API modules. This is made - possible due to an internal list of key-value tuples, also referred to - as interaction data. </p> + Erlang webserver API module sequence or generate data to be used + by consecutive Erlang Web Server API modules. This is + possible owing to an internal list of key-value tuples, referred to + as interaction data.</p> <note> <p>Interaction data enforces module dependencies and - should be avoided if possible. This means the order - of modules in the Modules property is significant.</p> + is to be avoided if possible. This means that the order + of modules in the modules property is significant.</p> </note> <section> <title>API Description</title> - <p>Each module implements server functionality - using the Erlang Web Server API should implement the following + <p>Each module that implements server functionality + using the Erlang web server API is to implement the following call back functions:</p> <list type="bulleted"> - <item>do/1 (mandatory) - the function called when - a request should be handled.</item> - <item>load/2</item> - <item>store/2</item> - <item>remove/1</item> + <item><c>do/1</c> (mandatory) - the function called when + a request is to be handled</item> + <item><c>load/2</c></item> + <item><c>store/2</c></item> + <item><c>remove/1</c></item> </list> <p>The latter functions are needed only when new config - directives are to be introduced. For details see - <seealso marker="httpd">httpd(3)</seealso></p> + directives are to be introduced. For details, see + <seealso marker="httpd">httpd(3)</seealso>.</p> </section> </section> <section> - <title>Inets Web Server Modules</title> <p>The convention is that - all modules implementing some webserver functionality has the - name mod_*. When configuring the web server an appropriate - selection of these modules should be present in the Module - directive. Please note that there are some interaction dependencies - to take into account so the order of the modules can not be - totally random.</p> + <title>Inets Web Server Modules</title> + <marker id="Inets_Web_Server_Modules"></marker> + <p>The convention is that + all modules implementing some web server functionality has the + name <c>mod_*</c>. When configuring the web server, an appropriate + selection of these modules is to be present in the module + directive. Notice that there are some interaction dependencies + to take into account, so the order of the modules cannot be + random.</p> <section> - <title>mod_action - Filetype/Method-Based Script Execution.</title> - <p>Runs CGI scripts whenever a file of a - certain type or HTTP method (See RFC 1945) is requested. + <title>mod_action - Filetype/Method-Based Script Execution</title> + <p>This module runs CGI scripts whenever a file of a + certain type or HTTP method (see + <url href="http://tools.ietf.org/html/rfc1945">RFC 1945</url>) + is requested. </p> <p>Uses the following Erlang Web Server API interaction data: </p> <list type="bulleted"> - <item>real_name - from mod_alias</item> + <item><c>real_name</c> - from <seealso marker="mod_alias">mod_alias</seealso>.</item> </list> <p>Exports the following Erlang Web Server API interaction data, if possible: </p> @@ -720,48 +546,51 @@ http://your.server.org/eval?httpd_example:print(atom_to_list(apply(erlang,halt,[ <section> <title>mod_alias - URL Aliasing</title> - <p>This module makes it possible to map different parts of the - host file system into the document tree e.i. creates aliases and + <p>The <seealso marker="mod_alias">mod_alias</seealso> + module makes it possible to map different parts of the + host file system into the document tree, that is, creates aliases and redirections.</p> <p>Exports the following Erlang Web Server API interaction data, if possible: </p> <taglist> <tag><c>{real_name, PathData}</c></tag> - <item>PathData is the argument used for API function mod_alias:path/3.</item> + <item><c>PathData</c> is the argument used for API function + <seealso marker="mod_alias#path/3">mod_alias:path/3</seealso>.</item> </taglist> </section> <section> - <title>mod_auth - User Authentication </title> - <p>This module provides for basic user authentication using - textual files, dets databases as well as mnesia databases.</p> + <title>mod_auth - User Authentication</title> + <p>The <seealso marker="mod_auth">mod_auth(3)</seealso> + module provides for basic user authentication using + textual files, <c>Dets</c> databases as well as <c>Mnesia</c> databases.</p> <p>Uses the following Erlang Web Server API interaction data: </p> <list type="bulleted"> - <item>real_name - from mod_alias</item> + <item><c>real_name</c> - from <seealso marker="mod_alias">mod_alias</seealso></item> </list> <p>Exports the following Erlang Web Server API interaction data: </p> <taglist> <tag><c>{remote_user, User}</c></tag> - <item>The user name with which the user has authenticated himself.</item> + <item>The username used for authentication.</item> </taglist> <section> - <title>Mnesia as Authentication Database</title> + <title>Mnesia As Authentication Database</title> - <p> If Mnesia is used as storage method, Mnesia must be - started prio to the HTTP server. 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 used 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 + <p>If <c>Mnesia</c> is used as storage method, <c>Mnesia</c> must be + started before the HTTP server. The first time <c>Mnesia</c> is + started, the schema and the tables must be created before + <c>Mnesia</c> is started. A simple example of a module with two + functions that creates and start <c>Mnesia</c> is provided + here. Function <c>first_start/0</c> is to be used the first + time. It creates the schema and the tables. + <c>start/0</c> is to be used in consecutive startups. + <c>start/0</c> starts <c>Mnesia</c> and waits for the tables to be initiated. This function must only be used when the - schema and the tables already is created. </p> + schema and the tables are already created.</p> <code> -module(mnesia_test). @@ -785,28 +614,28 @@ first_start() -> start() -> mnesia:start(), - mnesia:wait_for_tables([httpd_user, httpd_group], 60000). - </code> + mnesia:wait_for_tables([httpd_user, httpd_group], 60000). </code> - <p>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 HTTP 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 + <p>To create the <c>Mnesia</c> tables, we use two records defined in + <c>mod_auth.hrl</c>, so that file must be included. <c>first_start/0</c> + creates a schema that specifies on which nodes the database is to reside. + Then it starts <c>Mnesia</c> and creates the tables. The first argument + is the name of the tables, the second argument is a list of options of + how to create the table, see + <seealso marker="mnesia:mnesia"><c>mnesia</c></seealso>, documentation for + more information. As the implementation of the <c>mod_auth_mnesia</c> + saves one row for each user, the type must be <c>bag</c>. + When the schema and the tables are created, function + <seealso marker="mnesia:mnesia#start-0">mnesia:start/0</seealso> + is used to start <c>Mnesia</c> and + waits for the tables to be loaded. <c>Mnesia</c> uses the + directory specified as <c>mnesia_dir</c> at startup if specified, + otherwise <c>Mnesia</c> uses the current directory. For security + reasons, ensure that the <c>Mnesia</c> tables are stored outside + the document tree of the HTTP server. If they are placed in the + directory which it protects, clients can download the tables. + Only the <c>Dets</c> and <c>Mnesia</c> storage + methods allow writing of dynamic user data to disk. <c>plain</c> is a read only method.</p> </section> @@ -814,19 +643,19 @@ start() -> <section> <title>mod_cgi - CGI Scripts</title> - <p>This module handles invoking of CGI scripts</p> + <p>This module handles invoking of CGI scripts.</p> </section> <section> <title>mod_dir - Directories</title> <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 + instead of a file. This module must be removed from the Modules config directive if directory listings is unwanted.</p> <p>Uses the following Erlang Web Server API interaction data: </p> <list type="bulleted"> - <item>real_name - from mod_alias</item> + <item><c>real_name</c> - from <seealso marker="mod_alias">mod_alias</seealso></item> </list> <p>Exports the following Erlang Web Server API interaction data: </p> @@ -838,27 +667,27 @@ start() -> </section> <section> - <title>mod_disk_log - Logging Using disk_log.</title> + <title>mod_disk_log - Logging Using Disk_Log.</title> <p>Standard logging using the "Common Logfile Format" and - disk_log(3).</p> + <seealso marker="kernel:disk_log">kernel:disk_log(3)</seealso>.</p> <p>Uses the following Erlang Web Server API interaction data: </p> <list type="bulleted"> - <item>remote_user - from mod_auth</item> + <item><c>remote_user</c> - from <c>mod_auth</c></item> </list> </section> <section> <title>mod_esi - Erlang Server Interface</title> - <p>This module implements - the Erlang Server Interface (ESI) that provides a tight and - efficient interface to the execution of Erlang functions. </p> - <p>Uses the following Erlang Web Server API interaction data: + <p>The <seealso marker="mod_esi">mod_esi(3)</seealso> + module implements the Erlang Server Interface (ESI) providing a + tight and efficient interface to the execution of Erlang functions.</p> + <p>Uses the following Erlang web server API interaction data: </p> <list type="bulleted"> - <item>remote_user - from mod_auth</item> + <item><c>remote_user</c> - from <c>mod_auth</c></item> </list> - <p>Exports the following Erlang Web Server API interaction data: + <p>Exports the following Erlang web server API interaction data: </p> <taglist> <tag><c>{mime_type, MimeType}</c></tag> @@ -870,11 +699,11 @@ start() -> <section> <title>mod_get - Regular GET Requests</title> <p>This module is responsible for handling GET requests to regular - files. GET requests for parts of files is handled by mod_range.</p> - <p>Uses the following Erlang Web Server API interaction data: + files. GET requests for parts of files is handled by <c>mod_range</c>.</p> + <p>Uses the following Erlang web server API interaction data: </p> <list type="bulleted"> - <item>real_name - from mod_alias</item> + <item><c>real_name</c> - from <seealso marker="mod_alias">mod_alias</seealso></item> </list> </section> @@ -886,7 +715,7 @@ start() -> <p>Uses the following Erlang Web Server API interaction data: </p> <list type="bulleted"> - <item>real_name - from mod_alias</item> + <item><c>real_name</c> - from <seealso marker="mod_alias">mod_alias</seealso></item> </list> </section> @@ -897,120 +726,97 @@ start() -> <p>Uses the following Erlang Web Server API interaction data: </p> <list type="bulleted"> - <item>real_name - from mod_alias</item> + <item><c>real_name</c> - from <seealso marker="mod_alias">mod_alias</seealso></item> </list> <p>Exports the following Erlang Web Server API interaction data: </p> <taglist> <tag><c>{remote_user_name, User}</c></tag> - <item>The user name with which the user has authenticated himself.</item> + <item>The username used for authentication.</item> </taglist> </section> - <section> - <title>mod_include - SSI</title> - <p>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). - </p> - <p>Uses the following Erlang Webserver API interaction data: - </p> - <list type="bulleted"> - <item>real_name - from mod_alias</item> - <item>remote_user - from mod_auth</item> - </list> - <p>Exports the following Erlang Webserver API interaction data: - </p> - <taglist> - <tag><c>{mime_type, MimeType}</c></tag> - <item>The file suffix of the incoming URL mapped into a - <c>MimeType</c> as defined in the Mime Type Settings - section.</item> - </taglist> - </section> - <section> <title>mod_log - Logging Using Text Files.</title> <p>Standard logging using the "Common Logfile Format" and text files.</p> - <p>Uses the following Erlang Webserver API interaction data: + <p>Uses the following Erlang Web Server API interaction data: </p> <list type="bulleted"> - <item>remote_user - from mod_auth</item> + <item><c>remote_user</c> - from <c>mod_auth</c></item> </list> </section> <section> <title>mod_range - Requests with Range Headers</title> - <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> - <p>Note that request for multiple parts of a document will report a + <p>This module responses to requests for one or many ranges of a + file. This is especially useful when downloading large files, + as a broken download can be resumed.</p> + <p>Notice that request for multiple parts of a document report a size of zero to the log file.</p> - <p>Uses the following Erlang Webserver API interaction data: + <p>Uses the following Erlang Web Server API interaction data: </p> <list type="bulleted"> - <item>real_name - from mod_alias</item> + <item><c>real_name</c> - from <seealso marker="mod_alias">mod_alias</seealso></item> </list> </section> <section> <title>mod_response_control - Requests with If* Headers</title> - <p>This module controls that the conditions in the requests is - fulfilled. 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> <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></br> + <p>This module controls that the conditions in the requests are + fulfilled. For example, a request can specify that the answer + only is of interest if the content is unchanged since the last + retrieval. If the content is changed, the range request is to + be converted to a request for the whole file instead.</p> + <p>If a client sends more than one of the header fields that + restricts the servers right to respond, the standard does not + specify how this is to be handled. + <seealso marker="httpd">httpd(3)</seealso> controls each + field in the following order and if one of the fields does not + match the current state, the request is rejected with a proper + response:</p> + <p><c>If-modified</c></p> + <p><c>If-Unmodified</c></p> + <p><c>If-Match</c></p> + <p><c>If-Nomatch</c></p> - 1.If-modified <br></br> - - 2.If-Unmodified <br></br> - - 3.If-Match <br></br> - - 4.If-Nomatch <br></br> -</p> - <p>Uses the following Erlang Webserver API interaction data: + <p>Uses the following Erlang Web Server API interaction data: </p> <list type="bulleted"> - <item>real_name - from mod_alias</item> + <item><c>real_name</c> - from <seealso marker="mod_alias">mod_alias</seealso></item> </list> - <p>Exports the following Erlang Webserver API interaction data: + <p>Exports the following Erlang Web Server API interaction data: </p> <taglist> <tag><c>{if_range, send_file}</c></tag> - <item>The conditions for the range request was not fulfilled. + <item>The conditions for the range request are not fulfilled. The response must not be treated as a range request, instead it - must be treated as a ordinary get request. </item> + must be treated as an ordinary get request.</item> </taglist> </section> <section> <title>mod_security - Security Filter</title> - <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 + <p>The <seealso marker="mod_security">mod_security</seealso> + module serves as a filter for authenticated requests + handled in <seealso marker="mod_auth">mod_auth(3)</seealso>. + It provides a 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> + well as blocking of users, and it calls a configurable + callback module when the events occur.</p> <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.</p> + API to block or unblock users manually. This API can also list + blocked users or users who have been authenticated within a + configurable amount of time.</p> </section> <section> <title>mod_trace - TRACE Request</title> - <p>mod_trace is responsible for handling of TRACE requests. + <p><c>mod_trace</c> 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 + the request message that the responding web server or proxy received.</p> </section> </section> |