<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html xmlns:fn="http://www.w3.org/2005/02/xpath-functions">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<link rel="stylesheet" href="../../../../doc/otp_doc.css" type="text/css">
<title>Erlang -- HTTP server </title>
</head>
<body bgcolor="white" text="#000000" link="#0000ff" vlink="#ff00ff" alink="#ff0000"><div id="container">
<script id="js" type="text/javascript" language="JavaScript" src="../../../../doc/js/flipmenu/flipmenu.js"></script><script id="js2" type="text/javascript" src="../../../../doc/js/erlresolvelinks.js"></script><script language="JavaScript" type="text/javascript">
<!--
function getWinHeight() {
var myHeight = 0;
if( typeof( window.innerHeight ) == 'number' ) {
//Non-IE
myHeight = window.innerHeight;
} else if( document.documentElement && ( document.documentElement.clientWidth ||
document.documentElement.clientHeight ) ) {
//IE 6+ in 'standards compliant mode'
myHeight = document.documentElement.clientHeight;
} else if( document.body && ( document.body.clientWidth || document.body.clientHeight ) ) {
//IE 4 compatible
myHeight = document.body.clientHeight;
}
return myHeight;
}
function setscrollpos() {
var objf=document.getElementById('loadscrollpos');
document.getElementById("leftnav").scrollTop = objf.offsetTop - getWinHeight()/2;
}
function addEvent(obj, evType, fn){
if (obj.addEventListener){
obj.addEventListener(evType, fn, true);
return true;
} else if (obj.attachEvent){
var r = obj.attachEvent("on"+evType, fn);
return r;
} else {
return false;
}
}
addEvent(window, 'load', setscrollpos);
//--></script><div id="leftnav"><div class="innertube">
<img alt="Erlang logo" src="../../../../doc/erlang-logo.png"><br><small><a href="users_guide.html">User's Guide</a><br><a href="index.html">Reference Manual</a><br><a href="release_notes.html">Release Notes</a><br><a href="../pdf/inets-5.9.2.pdf">PDF</a><br><a href="../../../../doc/index.html">Top</a></small><p><strong>inets</strong><br><strong>User's Guide</strong><br><small>Version 5.9.2</small></p>
<br><a href="javascript:openAllFlips()">Expand All</a><br><a href="javascript:closeAllFlips()">Contract All</a><p><small><strong>Chapters</strong></small></p>
<ul class="flipMenu" imagepath="../../../../doc/js/flipmenu">
<li id="no" title="Introduction" expanded="false">Introduction<ul>
<li><a href="inets_services.html">
Top of chapter
</a></li>
<li title="Purpose"><a href="inets_services.html#id57726">Purpose</a></li>
<li title="Prerequisites"><a href="inets_services.html#id63179">Prerequisites</a></li>
<li title="The Service Concept"><a href="inets_services.html#id59584">The Service Concept</a></li>
</ul>
</li>
<li id="no" title="FTP Client" expanded="false">FTP Client<ul>
<li><a href="ftp_client.html">
Top of chapter
</a></li>
<li title="Introduction"><a href="ftp_client.html#id61235">Introduction</a></li>
<li title="Using the FTP Client API"><a href="ftp_client.html#id57000">Using the FTP Client API</a></li>
</ul>
</li>
<li id="no" title="HTTP Client" expanded="false">HTTP Client<ul>
<li><a href="http_client.html">
Top of chapter
</a></li>
<li title="Introduction"><a href="http_client.html#id60140">Introduction</a></li>
<li title="Configuration"><a href="http_client.html#id61256">Configuration</a></li>
<li title="Using the HTTP Client API"><a href="http_client.html#id60633">Using the HTTP Client API</a></li>
</ul>
</li>
<li id="loadscrollpos" title="HTTP server " expanded="true">HTTP server <ul>
<li><a href="http_server.html">
Top of chapter
</a></li>
<li title="Introduction"><a href="http_server.html#id61031">Introduction</a></li>
<li title="Configuration"><a href="http_server.html#id60316">Configuration</a></li>
<li title="Using the HTTP Server API"><a href="http_server.html#id60564">Using the HTTP Server API</a></li>
<li title="Htaccess - User Configurable Authentication."><a href="http_server.html#id61824">Htaccess - User Configurable Authentication.</a></li>
<li title="Dynamic Web Pages"><a href="http_server.html#id60221">Dynamic Web Pages</a></li>
<li title="Logging "><a href="http_server.html#id62487">Logging </a></li>
<li title="Server Side Includes"><a href="http_server.html#id62597">Server Side Includes</a></li>
<li title="The Erlang Web Server API"><a href="http_server.html#id62269">The Erlang Web Server API</a></li>
<li title="Inets Web Server Modules"><a href="http_server.html#id62373">Inets Web Server Modules</a></li>
</ul>
</li>
</ul>
</div></div>
<div id="content">
<div class="innertube">
<h1>4 HTTP server </h1>
<h3><a name="id61031">4.1
Introduction</a></h3>
<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
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>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
to enhance the core server functionality, for example with custom
logging and authentication.</p>
<a name="config"></a>
<h3><a name="id60316">4.2
Configuration</a></h3>
<p> What to put in the erlang node application configuration file
in order to start a http server at application startup.</p>
<div class="example"><pre>
[{inets, [{services, [{httpd, [{proplist_file,
"/var/tmp/server_root/conf/8888_props.conf"}]},
{httpd, [{proplist_file,
"/var/tmp/server_root/conf/8080_props.conf"}]}]}]}].
</pre></div>
<p>The server is configured using an erlang property list.
For the available properties see
<span class="bold_code"><a href="httpd.html">httpd(3)</a></span>
For backwards compatibility also apache-like config files
are supported.
</p>
<p>All possible config properties are as follows </p>
<div class="example"><pre>
httpd_service() -> {httpd, httpd()}
httpd() -> [httpd_config()]
httpd_config() -> {file, file()} |
{proplist_file, file()}
{debug, debug()} |
{accept_timeout, integer()}
debug() -> disable | [debug_options()]
debug_options() -> {all_functions, modules()} |
{exported_functions, modules()} |
{disable, modules()}
modules() -> [atom()]
</pre></div>
<p>{proplist_file, file()} 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>
<a name="using_http_server_api"></a>
<h3><a name="id60564">4.3
Using the HTTP Server API</a></h3>
<div class="example"><pre>
1 > inets:start().
ok
</pre></div>
<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>
<div class="example"><pre>
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}
</pre></div>
<div class="example"><pre>
3 > httpd:info(Pid).
[{mime_types,[{"html","text/html"},{"htm","text/html"}]},
{server_name,"httpd_test"},
{bind_address, {127,0,0,1}},
{server_root,"/tmp"},
{port,59408},
{document_root,"/tmp/htdocs"}]
</pre></div>
<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>
<div class="example"><pre>
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.
</pre></div>
<div class="example"><pre>
5 > httpd:info(Pid, [server_root, document_root]).
[{server_root,"/tmp/www_test"},{document_root,"/tmp/www_test/htdocs"}]
</pre></div>
<div class="example"><pre>
6 > ok = inets:stop(httpd, Pid).
</pre></div>
<p> Alternative:</p>
<div class="example"><pre>
6 > ok = inets:stop(httpd, {{127,0,0,1}, 59408}).
</pre></div>
<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>
<a name="htaccess"></a>
<h3><a name="id61824">4.4
Htaccess - User Configurable Authentication.</a></h3>
<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>
<ul>
<li>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. </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 succeed.</li>
</ul>
<h4>Access Files Directives</h4>
<p>In every directory under the <span class="code">DocumentRoot</span> or under an
<span class="code">Alias</span> 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>
<ul>
<li>
<p><strong>DIRECTIVE: "allow"</strong></p>
<p><strong>Syntax:</strong><span class="code">Allow</span> from subnet subnet|from all <br>
<strong>Default:</strong><span class="code">from all </span> <br>
</p>
<p>Same as the directive allow for the server config file. </p>
</li>
<li>
<p><strong>DIRECTIVE: "AllowOverRide"</strong></p>
<p><strong>Syntax:</strong><span class="code">AllowOverRide</span> all | none |
Directives <br>
<strong>Default:</strong><span class="code">- None -</span> <br>
<span class="code">AllowOverRide</span> 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.
</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>
</li>
<li>
<p><strong>DIRECTIVE: "AuthGroupfile"</strong></p>
<p><strong>Syntax:</strong><span class="code">AuthGroupFile</span> Filename <br>
<strong>Default:</strong><span class="code">- None -</span> <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
every row contains the name of the group and the members
of the group separated by a space, for example:</p>
<div class="example"><pre>
GroupName: Member1 Member2 .... MemberN
</pre></div>
</li>
<li>
<p><strong>DIRECTIVE: "AuthName"</strong></p>
<p><strong>Syntax:</strong><span class="code">AuthName</span> auth-domain <br>
<strong>Default:</strong><span class="code">- None -</span> <br>
</p>
<p>Same as the directive AuthName for the server config file. </p>
</li>
<li>
<p><strong>DIRECTIVE: "AuthType"</strong></p>
<p><strong>Syntax:</strong><span class="code">AuthType</span> Basic <br>
<strong>Default:</strong><span class="code">Basic</span> <br>
</p>
<p><span class="code">AuthType</span> Specify which authentication scheme that shall
be used. Today only Basic Authenticating using UUEncoding of
the password and user ID is implemented. </p>
</li>
<li>
<p><strong>DIRECTIVE: "AuthUserFile"</strong></p>
<p><strong>Syntax:</strong><span class="code">AuthUserFile</span> Filename <br>
<strong>Default:</strong><span class="code">- None -</span> <br>
</p>
<p><span class="code">AuthUserFile</span> 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 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>
<div class="example"><pre>
UserName:Password
UserName:Password
</pre></div>
</li>
<li>
<p><strong>DIRECTIVE: "deny"</strong></p>
<p><strong>Syntax:</strong><span class="code">deny</span> from subnet subnet|from all <br>
<strong>Context:</strong> Limit</p>
<p>Same as the directive deny for the server config file. </p>
</li>
<li>
<p><strong>DIRECTIVE: "Limit"</strong> <br>
</p>
<p><strong>Syntax:</strong><span class="code"><Limit</span> RequestMethods<span class="code">></span> <br>
<strong>Default:</strong> - None - <br>
</p>
<p><span class="code"><Limit></span> and </Limit> are used to enclose
a group of directives which applies only to requests using
the specified methods. If no request method is specified
all request methods are verified against the restrictions.</p>
<div class="example"><pre>
<Limit POST GET HEAD>
order allow deny
require group group1
allow from 123.145.244.5
</Limit>
</pre></div>
</li>
<li>
<p><strong>DIRECTIVE: "order"</strong> <br>
<strong>Syntax:</strong><span class="code">order</span> allow deny | deny allow <br>
<strong>Default:</strong> allow deny <br>
</p>
<p><span class="code">order</span>, 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
assets in the limited area.</p>
</li>
<li>
<p><strong>DIRECTIVE: "require"</strong></p>
<p><strong>Syntax:</strong><span class="code">require</span>
group group1 group2...|user user1 user2... <br>
<strong>Default:</strong><span class="code">- None -</span> <br>
<strong>Context:</strong> Limit <br>
</p>
<p>See the require directive in the documentation of mod_auth(3)
for more information.</p>
</li>
</ul>
<a name="dynamic_we_pages"></a>
<h3><a name="id60221">4.5
Dynamic Web Pages</a></h3>
<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>
<h4>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 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>
<div class="example"><pre>"Content-Type:text/plain\nAccept-Ranges:none\n\nsome very
plain text" </pre></div>
<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>
<h4>Erlang Server Interface (ESI)</h4>
<p>The erlang server interface is implemented by the
module mod_esi.</p>
<h4>ERL Scheme </h4>
<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): </p>
<div class="example"><pre>
http://your.server.org/***/Module[:/]Function(?QueryString|/PathInfo)
</pre></div>
<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
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 <span class="bold_code"><a href="mod_esi.html">mod_esi(3)</a></span> for
implementation details of the esi callback function.</p>
<h4>EVAL Scheme </h4>
<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:</p>
<div class="example"><pre>
http://your.server.org/***/Mod:Func(Arg1,...,ArgN)
</pre></div>
<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
back to the client. Data returned from the
function must furthermore take the form as specified in
the CGI specification. See <span class="bold_code"><a href="mod_esi.html">mod_esi(3)</a></span> for implementation details of the esi
callback function.</p>
<div class="note">
<div class="label">Note</div>
<div class="content"><p>
<p>The eval scheme can seriously threaten the
integrity of the Erlang node housing a Web server, for
example: </p>
<div class="example"><pre>
http://your.server.org/eval?httpd_example:print(atom_to_list(apply(erlang,halt,[])))
</pre></div>
<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>
</p></div>
</div>
<a name="logging"></a>
<h3><a name="id62487">4.6
Logging </a></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>
<p><strong>remotehost rfc931 authuser [date] "request" status bytes</strong></p>
<dl>
<dt><strong><strong>remotehost</strong></strong></dt>
<dd>Remote hostname</dd>
<dt><strong><strong>rfc931</strong></strong></dt>
<dd>The client's remote username (RFC 931).</dd>
<dt><strong><strong>authuser</strong></strong></dt>
<dd>The username with which the user authenticated himself.</dd>
<dt><strong><strong>[date]</strong></strong></dt>
<dd>Date and time of the request (RFC 1123).</dd>
<dt><strong><strong>"request"</strong></strong></dt>
<dd>The request line exactly as it came from the client (RFC 1945).</dd>
<dt><strong><strong>status</strong></strong></dt>
<dd>The HTTP status code returned to the client (RFC 1945).</dd>
<dt><strong><strong>bytes</strong></strong></dt>
<dd>The content-length of the document transferred. </dd>
</dl>
<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
Common Logfile Format, but conforms to the following syntax:
</p>
<p><strong>[date]</strong> access to <strong>path</strong> failed for
<strong>remotehost</strong>, reason: <strong>reason</strong></p>
<a name="ssi"></a>
<h3><a name="id62597">4.7
Server Side Includes</a></h3>
<p>Server Side Includes enables the server to run code embedded
in HTML pages to generate the response to the client.</p>
<div class="note">
<div class="label">Note</div>
<div class="content"><p>
<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>
</p></div>
</div>
<h4>SERVER-SIDE INCLUDES (SSI) SETUP</h4>
<a name="ssi_setup"></a>
<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 <span class="code">text/x-server-parsed-html</span>
to identify parsed documents. It will then perform a format
conversion to change these files into HTML for the
client. Update the <span class="code">mime.types</span> file, as described in the
Mime Type Settings, to tell the server which extension to use
for parsed files, for example:
</p>
<div class="example"><pre>
text/x-server-parsed-html shtml shtm
</pre></div>
<p>This makes files ending with <span class="code">.shtml</span> and <span class="code">.shtm</span>
into parsed files. Alternatively, if the performance hit is not a
problem, <strong>all</strong> HTML pages can be marked as parsed:
</p>
<div class="example"><pre>
text/x-server-parsed-html html htm
</pre></div>
<h4>Server-Side Includes (SSI) Format</h4>
<a name="ssi_format"></a>
<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>
<div class="example"><pre>
<!--#command tag1="value1" tag2="value2" -->
</pre></div>
<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>
<dl>
<dt><strong><span class="code">errmsg</span></strong></dt>
<dd>
<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>
</dd>
<dt><strong><span class="code">sizefmt</span></strong></dt>
<dd>
<p>determines the format used to display the size of
a file. Valid choices are <span class="code">bytes</span> or
<span class="code">abbrev</span>. <span class="code">bytes</span> for a formatted byte count
or <span class="code">abbrev</span> for an abbreviated version displaying
the number of kilobytes.</p>
</dd>
</dl>
<p>The include directory
will insert the text of a document into the parsed
document. This command accepts two tags:</p>
<dl>
<dt><strong><span class="code">virtual</span></strong></dt>
<dd>
<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>
</dd>
<dt><strong><span class="code">file</span></strong></dt>
<dd>
<p>gives a pathname relative to the current
directory. <span class="code">../</span> 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>
</dd>
</dl>
<p>The echo directive prints the value of one of the include
variables (defined below). The only valid tag to this
command is <span class="code">var</span>, 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 <span class="code">include</span>
command. The resulting format of this command is subject
to the <span class="code">sizefmt</span> parameter to the <span class="code">config</span>
command.</p>
<p>The lastmod directive prints the last modification date of
the specified file. Valid tags are the same as with the
<span class="code">include</span> command.</p>
<p>The exec directive executes a given shell command or CGI
script. Valid tags are:</p>
<dl>
<dt><strong><span class="code">cmd</span></strong></dt>
<dd>
<p>executes the given string using <span class="code">/bin/sh</span>. All
of the variables defined below are defined, and can be
used in the command.</p>
</dd>
<dt><strong><span class="code">cgi</span></strong></dt>
<dd>
<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>
</dd>
</dl>
<h4>Server-Side Includes (SSI) Environment Variables</h4>
<a name="ssi_environment_variables"></a>
<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><strong><span class="code">DOCUMENT_NAME</span></strong></dt>
<dd>
<p>The current filename.</p>
</dd>
<dt><strong><span class="code">DOCUMENT_URI</span></strong></dt>
<dd>
<p>The virtual path to this document (such as
<span class="code">/docs/tutorials/foo.shtml</span>).</p>
</dd>
<dt><strong><span class="code">QUERY_STRING_UNESCAPED</span></strong></dt>
<dd>
<p>The unescaped version of any search query the client
sent, with all shell-special characters escaped with
<span class="code">\</span>.</p>
</dd>
<dt><strong><span class="code">DATE_LOCAL</span></strong></dt>
<dd>
<p>The current date, local time zone.</p>
</dd>
<dt><strong><span class="code">DATE_GMT</span></strong></dt>
<dd>
<p>Same as DATE_LOCAL but in Greenwich mean time.</p>
</dd>
<dt><strong><span class="code">LAST_MODIFIED</span></strong></dt>
<dd>
<p>The last modification date of the current document.</p>
</dd>
</dl>
<h3><a name="id62269">4.8
The Erlang Web Server API</a></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 checks.</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 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>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>
<div class="note">
<div class="label">Note</div>
<div class="content"><p>
<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>
</p></div>
</div>
<h4>API Description</h4>
<p>Each module implements server functionality
using the Erlang Web Server 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
<span class="bold_code"><a href="httpd.html">httpd(3)</a></span></p>
<h3><a name="id62373">4.9
Inets Web Server Modules</a></h3>
<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>
<h4>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>
<p>Uses the following Erlang Web Server API interaction data:
</p>
<ul>
<li>real_name - from mod_alias</li>
</ul>
<p>Exports the following Erlang Web Server API interaction data, if possible:
</p>
<dl>
<dt><strong><span class="code">{new_request_uri, RequestURI}</span></strong></dt>
<dd>An alternative <span class="code">RequestURI</span> has been generated.</dd>
</dl>
<h4>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>
<p>Exports the following Erlang Web Server API interaction data, if possible:
</p>
<dl>
<dt><strong><span class="code">{real_name, PathData}</span></strong></dt>
<dd>PathData is the argument used for API function mod_alias:path/3.</dd>
</dl>
<h4>mod_auth - User Authentication </h4>
<p>This module provides for basic user authentication using
textual files, dets databases as well as mnesia databases.</p>
<p>Uses the following Erlang Web Server API interaction data:
</p>
<ul>
<li>real_name - from mod_alias</li>
</ul>
<p>Exports the following Erlang Web Server API interaction data:
</p>
<dl>
<dt><strong><span class="code">{remote_user, User}</span></strong></dt>
<dd>The user name with which the user has authenticated himself.</dd>
</dl>
<h4>Mnesia as Authentication Database</h4>
<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
be initiated. This function must only be used when the
schema and the tables already is created. </p>
<div class="example"><pre>
-module(mnesia_test).
-export([start/0,load_data/0]).
-include_lib("mod_auth.hrl").
first_start() ->
mnesia:create_schema([node()]),
mnesia:start(),
mnesia:create_table(httpd_user,
[{type, bag},
{disc_copies, [node()]},
{attributes, record_info(fields,
httpd_user)}]),
mnesia:create_table(httpd_group,
[{type, bag},
{disc_copies, [node()]},
{attributes, record_info(fields,
httpd_group)}]),
mnesia:wait_for_tables([httpd_user, httpd_group], 60000).
start() ->
mnesia:start(),
mnesia:wait_for_tables([httpd_user, httpd_group], 60000).
</pre></div>
<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
a read only method.</p>
<h4>mod_cgi - CGI Scripts</h4>
<p>This module handles invoking of CGI scripts</p>
<h4>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>
<p>Uses the following Erlang Web Server API interaction data:
</p>
<ul>
<li>real_name - from mod_alias</li>
</ul>
<p>Exports the following Erlang Web Server API interaction data:
</p>
<dl>
<dt><strong><span class="code">{mime_type, MimeType}</span></strong></dt>
<dd>The file suffix of the incoming URL mapped into a
<span class="code">MimeType</span>.</dd>
</dl>
<h4>mod_disk_log - Logging Using disk_log.</h4>
<p>Standard logging using the "Common Logfile Format" and
disk_log(3).</p>
<p>Uses the following Erlang Web Server API interaction data:
</p>
<ul>
<li>remote_user - from mod_auth</li>
</ul>
<h4>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>
<p>Uses the following Erlang Web Server API interaction data:
</p>
<ul>
<li>remote_user - from mod_auth</li>
</ul>
<p>Exports the following Erlang Web Server API interaction data:
</p>
<dl>
<dt><strong><span class="code">{mime_type, MimeType}</span></strong></dt>
<dd>The file suffix of the incoming URL mapped into a
<span class="code">MimeType</span>
</dd>
</dl>
<h4>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>
<p>Uses the following Erlang Web Server API interaction data:
</p>
<ul>
<li>real_name - from mod_alias</li>
</ul>
<h4>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>
<p>Uses the following Erlang Web Server API interaction data:
</p>
<ul>
<li>real_name - from mod_alias</li>
</ul>
<h4>mod_htaccess - User Configurable Access</h4>
<p>This module provides per-directory user configurable access
control.</p>
<p>Uses the following Erlang Web Server API interaction data:
</p>
<ul>
<li>real_name - from mod_alias</li>
</ul>
<p>Exports the following Erlang Web Server API interaction data:
</p>
<dl>
<dt><strong><span class="code">{remote_user_name, User}</span></strong></dt>
<dd>The user name with which the user has authenticated himself.</dd>
</dl>
<h4>mod_include - SSI</h4>
<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>
<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:
</p>
<dl>
<dt><strong><span class="code">{mime_type, MimeType}</span></strong></dt>
<dd>The file suffix of the incoming URL mapped into a
<span class="code">MimeType</span> as defined in the Mime Type Settings
section.</dd>
</dl>
<h4>mod_log - Logging Using Text Files.</h4>
<p>Standard logging using the "Common Logfile Format" and text
files.</p>
<p>Uses the following Erlang Webserver API interaction data:
</p>
<ul>
<li>remote_user - from mod_auth</li>
</ul>
<h4>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>
<p>Note that request for multiple parts of a document will report a
size of zero to the log file.</p>
<p>Uses the following Erlang Webserver API interaction data:
</p>
<ul>
<li>real_name - from mod_alias</li>
</ul>
<h4>mod_response_control - Requests with If* Headers</h4>
<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>
1.If-modified <br>
2.If-Unmodified <br>
3.If-Match <br>
4.If-Nomatch <br>
</p>
<p>Uses the following Erlang Webserver API interaction data:
</p>
<ul>
<li>real_name - from mod_alias</li>
</ul>
<p>Exports the following Erlang Webserver API interaction data:
</p>
<dl>
<dt><strong><span class="code">{if_range, send_file}</span></strong></dt>
<dd>The conditions for the range request was not fulfilled.
The response must not be treated as a range request, instead it
must be treated as a ordinary get request. </dd>
</dl>
<h4>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>
<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>
<h4>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.</p>
</div>
<div class="footer">
<hr>
<p>Copyright © 1997-2012 Ericsson AB. All Rights Reserved.</p>
</div>
</div>
</div></body>
</html>
