-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<HTML>
-<HEAD>
-<TITLE>Apache Core Features</TITLE>
-</HEAD>
-
-<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
-<BODY
- BGCOLOR="#FFFFFF"
- TEXT="#000000"
- LINK="#0000FF"
- VLINK="#000080"
- ALINK="#FF0000"
->
-<!--#include virtual="header.html" -->
-
-<H1 ALIGN="CENTER">Apache Core Features</H1>
-<P>
-These configuration parameters control the core Apache features, and are
-always available.
-</P>
-<H2>Directives</H2>
-<UL>
-<LI><A HREF="#accessfilename">AccessFileName</A>
-<LI><A HREF="#adddefaultcharset">AddDefaultCharset</A>
-<LI><A HREF="#addmodule">AddModule</A>
-<LI><A HREF="#allowoverride">AllowOverride</A>
-<LI><A HREF="#authname">AuthName</A>
-<LI><A HREF="#authtype">AuthType</A>
-<LI><A HREF="#clearmodulelist">ClearModuleList</A>
-<LI><A HREF="#contentdigest">ContentDigest</A>
-<LI><A HREF="#coredumpdirectory">CoreDumpDirectory</A>
-<LI><A HREF="#defaulttype">DefaultType</A>
-<LI><A HREF="#directory"><Directory></A>
-<LI><A HREF="#directorymatch"><DirectoryMatch></A>
-<LI><A HREF="#documentroot">DocumentRoot</A>
-<LI><A HREF="#errordocument">ErrorDocument</A>
-<LI><A HREF="#errorlog">ErrorLog</A>
-<LI><A HREF="#files"><Files></A>
-<LI><A HREF="#filesmatch"><FilesMatch></A>
-<LI><a href="#forcetype">ForceType</a>
-<LI><A HREF="#hostnamelookups">HostNameLookups</A>
-<LI><A HREF="#identitycheck">IdentityCheck</A>
-<LI><A HREF="#ifdefine"><IfDefine></A>
-<LI><A HREF="#ifmodule"><IfModule></A>
-<LI><A HREF="#include">Include</A>
-<LI><A HREF="#keepalive">KeepAlive</A>
-<LI><A HREF="#keepalivetimeout">KeepAliveTimeout</A>
-<LI><A HREF="#limit"><Limit></A>
-<LI><A HREF="#limitexcept"><LimitExcept></A>
-<LI><A HREF="#limitrequestbody">LimitRequestBody</A>
-<LI><A HREF="#limitrequestfields">LimitRequestFields</A>
-<LI><A HREF="#limitrequestfieldsize">LimitRequestFieldsize</A>
-<LI><A HREF="#limitrequestline">LimitRequestLine</A>
-<LI><A HREF="#limitxmlrequestbody">LimitXMLRequestBody</A>
-<LI><A HREF="#location"><Location></A>
-<LI><A HREF="#locationmatch"><LocationMatch></A>
-<LI><A HREF="#loglevel">LogLevel</A>
-<LI><A HREF="#maxkeepaliverequests">MaxKeepAliveRequests</A>
-<LI><A HREF="#namevirtualhost">NameVirtualHost</A>
-<LI><A HREF="#options">Options</A>
-<LI><A HREF="#port">Port</A>
-<LI><A HREF="#require">Require</A>
-<LI><A HREF="#rlimitcpu">RLimitCPU</A>
-<LI><A HREF="#rlimitmem">RLimitMEM</A>
-<LI><A HREF="#rlimitnproc">RLimitNPROC</A>
-<LI><A HREF="#satisfy">Satisfy</A>
-<LI><A HREF="#scriptinterpretersource">ScriptInterpreterSource</A>
-<LI><A HREF="#serveradmin">ServerAdmin</A>
-<LI><A HREF="#serveralias">ServerAlias</A>
-<LI><A HREF="#servername">ServerName</A>
-<LI><A HREF="#serverpath">ServerPath</A>
-<LI><A HREF="#serverroot">ServerRoot</A>
-<LI><A HREF="#serversignature">ServerSignature</A>
-<LI><A HREF="#servertokens">ServerTokens</A>
-<LI><a href="#sethandler">SetHandler</a>
-<LI><A HREF="#setinputfilter">SetInputFilter</A>
-<LI><A HREF="#setoutputfilter">SetOutputFilter</A>
-<LI><A HREF="#timeout">TimeOut</A>
-<LI><A HREF="#usecanonicalname">UseCanonicalName</A>
-<LI><A HREF="#virtualhost"><VirtualHost></A>
-</UL>
-<HR>
-
-<H2><A NAME="accessfilename">AccessFileName directive</A></H2>
-<!--%plaintext <?INDEX {\tt AccessFileName} directive> -->
-<A
- HREF="directive-dict.html#Syntax"
- REL="Help"
-><STRONG>Syntax:</STRONG></A> AccessFileName <EM>filename</em>
-[<em>filename</em>] ...<BR>
-<A
- HREF="directive-dict.html#Default"
- REL="Help"
-><STRONG>Default:</STRONG></A> <CODE>AccessFileName .htaccess</CODE><BR>
-<A
- HREF="directive-dict.html#Context"
- REL="Help"
-><STRONG>Context:</STRONG></A> server config, virtual host<BR>
-<A
- HREF="directive-dict.html#Status"
- REL="Help"
-><STRONG>Status:</STRONG></A> core<BR>
-<A
- HREF="directive-dict.html#Compatibility"
- REL="Help"
-><STRONG>Compatibility:</STRONG></A> AccessFileName can accept more than
-one filename only in Apache 1.3 and later<P>
-
-When returning a document to the client the server looks for the first existing
-access control file from this list of names in every directory of the path to
-the document, if access control files are enabled for that directory.
-
-For example:
-<BLOCKQUOTE><CODE>AccessFileName .acl</CODE></BLOCKQUOTE>
-before returning the document /usr/local/web/index.html, the
-server will read /.acl, /usr/.acl, /usr/local/.acl and /usr/local/web/.acl
-for directives, unless they have been disabled with
-<BLOCKQUOTE><CODE>
-<Directory /><BR>
-AllowOverride None<BR>
-</Directory></CODE>
-</BLOCKQUOTE><P>
-
-<P><STRONG>See Also:</STRONG>
-<A HREF="#allowoverride">AllowOverride</a></P>
-<HR>
-
-<H2><A NAME="adddefaultcharset">AddDefaultCharset directive</A></H2>
-<A HREF="directive-dict.html#Syntax" REL="Help"><STRONG>Syntax:</STRONG></A>
-AddDefaultCharset On|Off|<em>charset</em><BR>
-<A HREF="directive-dict.html#Context" REL="Help" ><STRONG>Context:</STRONG></A>
-all<BR>
-<A HREF="directive-dict.html#Status" REL="Help" ><STRONG>Status:</STRONG></A>
-core<BR>
-<A HREF="directive-dict.html#Default" REL="Help"><STRONG>Default:</STRONG></A>
-<CODE>AddDefaultCharset Off</CODE><BR>
-<A HREF="directive-dict.html#Compatibility" REL="Help"><STRONG>Compatibility:
-</STRONG></A> AddDefaultCharset is only available in Apache 1.3.12 and
-later<P>
-This directive specifies the name of the character set that will be added
-to any response that does not have any parameter on the content
-type in the HTTP headers. This will override any character set specified
-in the body of the document via a <CODE>META</CODE> tag. A setting
-of <CODE>AddDefaultCharset Off</CODE> disables this functionality.
-<CODE>AddDefaultCharset On</CODE> enables Apache's internal
-default charset of <code>iso-8859-1</code> as required by the
-directive. You can also specify an alternate <em>charset</em> to be used;
-e.g. <code>AddDefaultCharset utf-8</code>.
-<P><HR>
-
-<H2><A NAME="addmodule">AddModule directive</A></H2>
-<!--%plaintext <?INDEX {\tt AddModule} directive> -->
-<A
- HREF="directive-dict.html#Syntax"
- REL="Help"
-><STRONG>Syntax:</STRONG></A> AddModule <EM>module</em> [<em>module</em>] ...<BR>
-<A
- HREF="directive-dict.html#Context"
- REL="Help"
-><STRONG>Context:</STRONG></A> server config <BR>
-<A
- HREF="directive-dict.html#Status"
- REL="Help"
-><STRONG>Status:</STRONG></A> core<BR>
-<A
- HREF="directive-dict.html#Compatibility"
- REL="Help"
-><STRONG>Compatibility:</STRONG></A> AddModule is only available in
-Apache 1.2 and later<P>
-
-The server can have modules compiled in which are not actively in use.
-This directive can be used to enable the use of those modules. The
-server comes with a pre-loaded list of active modules; this list can
-be cleared with the <A HREF="#clearmodulelist">ClearModuleList</A>
-directive.<P><HR>
-
-<H2><A NAME="allowoverride">AllowOverride directive</A></H2>
-<!--%plaintext <?INDEX {\tt AllowOverride} directive> -->
-<A
- HREF="directive-dict.html#Syntax"
- REL="Help"
-><STRONG>Syntax:</STRONG></A> AllowOverride All|None|<EM>directive-type</em>
-[<em>directive-type</em>] ...<BR>
-<A
- HREF="directive-dict.html#Default"
- REL="Help"
-><STRONG>Default:</STRONG></A> <CODE>AllowOverride All</CODE><BR>
-<A
- HREF="directive-dict.html#Context"
- REL="Help"
-><STRONG>Context:</STRONG></A> directory<BR>
-<A
- HREF="directive-dict.html#Status"
- REL="Help"
-><STRONG>Status:</STRONG></A> core<P>
-
-<p>When the server finds an .htaccess file (as specified by
-<A HREF="#accessfilename">AccessFileName</A>) it needs to know which
-directives declared in that file can override earlier access information.</p>
-
-<p>When this directive is set to <code>None</code>, then
-.htaccess files are completely ignored. In this case, the server
-will not even attempt to read .htaccess files in the filesystem.</p>
-
-<p>When this directive is set to <code>All</code>, then any directive
-which has the .htaccess <a
-href="directive-dict.html#Context">Context</a> is allowed in .htaccess
-files.</p>
-
-<p>The <em>directive-type</em> can be one of the following groupings
-of directives.</p>
-<DL>
-<DT>AuthConfig
-<DD>
-<!--%plaintext <?INDEX {\tt AuthConfig} override> -->
-Allow use of the authorization directives
-(<A HREF="mod_auth_dbm.html#authdbmgroupfile">AuthDBMGroupFile</A>,
-<A HREF="mod_auth_dbm.html#authdbmuserfile">AuthDBMUserFile</A>,
-<A HREF="mod_auth.html#authgroupfile">AuthGroupFile</A>,
-<A HREF="#authname">AuthName</A>, <A HREF="#authtype">AuthType</A>,
-<A HREF="mod_auth.html#authuserfile">AuthUserFile</A>,
-<A HREF="#require">Require</A>, <EM>etc.</EM>).
-<DT>FileInfo
-<DD>
-<!--%plaintext <?INDEX {\tt FileInfo} override> -->
-Allow use of the directives controlling document types
-(<A HREF="#defaulttype">DefaultType</A>,
-<A HREF="#errordocument">ErrorDocument</A>,
-<A href="#forcetype">ForceType</A>,
-<A HREF="mod_negotiation.html#languagepriority">LanguagePriority</A>,
-<A href="#sethandler">SetHandler</A>,
-<A HREF="#setinputfilter">SetInputFilter</A>,
-<A HREF="#setoutputfilter">SetOutputFilter</A>,
-and <A HREF="mod_mime.html">mod_mime Add* and Remove* directives</A>,
-<EM>etc.</EM>).
-<DT>Indexes
-<DD>
-<!--%plaintext <?INDEX {\tt Indexes} override> -->
-Allow use of the directives controlling directory indexing
-(<A HREF="mod_autoindex.html#adddescription">AddDescription</A>,
-<A HREF="mod_autoindex.html#addicon">AddIcon</A>,
-<A HREF="mod_autoindex.html#addiconbyencoding">AddIconByEncoding</A>,
-<A HREF="mod_autoindex.html#addiconbytype">AddIconByType</A>,
-<A HREF="mod_autoindex.html#defaulticon">DefaultIcon</A>,
-<A HREF="mod_dir.html#directoryindex">DirectoryIndex</A>,
-<A HREF="mod_autoindex.html#fancyindexing">FancyIndexing</A>,
-<A HREF="mod_autoindex.html#headername">HeaderName</A>,
-<A HREF="mod_autoindex.html#indexignore">IndexIgnore</A>,
-<A HREF="mod_autoindex.html#indexoptions">IndexOptions</A>,
-<A HREF="mod_autoindex.html#readmename">ReadmeName</A>, <EM>etc.</EM>).
-<DT>Limit
-<DD>
-<!--%plaintext <?INDEX {\tt Limit} override> -->
-Allow use of the directives controlling host access (Allow, Deny and Order).
-<DT>Options
-<DD>
-<!--%plaintext <?INDEX {\tt Options} override> -->
-Allow use of the directives controlling specific directory features
-(<A HREF="#options">Options</A> and
-<A HREF="mod_include.html#xbithack">XBitHack</A>).
-</DL><P>
-
-<P><STRONG>See Also:</STRONG>
-<A HREF="#accessfilename">AccessFileName</A></P>
-<HR>
-
-<H2><A NAME="authname">AuthName directive</A></H2>
-<!--%plaintext <?INDEX {\tt AuthName} directive> -->
-<A
- HREF="directive-dict.html#Syntax"
- REL="Help"
-><STRONG>Syntax:</STRONG></A> AuthName <EM>auth-domain</EM><BR>
-<A
- HREF="directive-dict.html#Context"
- REL="Help"
-><STRONG>Context:</STRONG></A> directory, .htaccess<BR>
-<A
- HREF="directive-dict.html#Override"
- REL="Help"
-><STRONG>Override:</STRONG></A> AuthConfig<BR>
-<A
- HREF="directive-dict.html#Status"
- REL="Help"
-><STRONG>Status:</STRONG></A> core<P>
-
-This directive sets the name of the authorization realm for a directory.
-This realm is given to the client so that the user knows which username and
-password to send. <SAMP>AuthName</SAMP> takes a single argument;
-if the realm name contains spaces, it must be enclosed in quotation marks.
-It must be accompanied by <A HREF="#authtype">AuthType</A> and
-<A HREF="#require">Require</A> directives, and directives such as
-<A HREF="mod_auth.html#authuserfile">AuthUserFile</A> and
-<A HREF="mod_auth.html#authgroupfile">AuthGroupFile</A> to work.<P><HR>
-
-<H2><A NAME="authtype">AuthType directive</A></H2>
-<!--%plaintext <?INDEX {\tt AuthType} directive> -->
-<A
- HREF="directive-dict.html#Syntax"
- REL="Help"
-><STRONG>Syntax:</STRONG></A> AuthType Basic|Digest<BR>
-<A
- HREF="directive-dict.html#Context"
- REL="Help"
-><STRONG>Context:</STRONG></A> directory, .htaccess<BR>
-<A
- HREF="directive-dict.html#Override"
- REL="Help"
-><STRONG>Override:</STRONG></A> AuthConfig<BR>
-<A
- HREF="directive-dict.html#Status"
- REL="Help"
-><STRONG>Status:</STRONG></A> core<P>
-
-This directive selects the type of user authentication for a directory.
-Only <CODE>Basic</CODE> and <CODE>Digest</CODE> are currently implemented.
-<!--%plaintext <?INDEX {\tt Basic} authentication scheme> -->
-It must be accompanied by <A HREF="#authname">AuthName</A> and
-<A HREF="#require">Require</A> directives, and directives such as
-<A HREF="mod_auth.html#authuserfile">AuthUserFile</A> and
-<A HREF="mod_auth.html#authgroupfile">AuthGroupFile</A> to work.<P><HR>
-
-<H2><A NAME="clearmodulelist">ClearModuleList directive</A></H2>
-<!--%plaintext <?INDEX {\tt ClearModuleList} directive> -->
-<A
- HREF="directive-dict.html#Syntax"
- REL="Help"
-><STRONG>Syntax:</STRONG></A> ClearModuleList<BR>
-<A
- HREF="directive-dict.html#Context"
- REL="Help"
-><STRONG>Context:</STRONG></A> server config<BR>
-<A
- HREF="directive-dict.html#Status"
- REL="Help"
-><STRONG>Status:</STRONG></A> core<BR>
-<A
- HREF="directive-dict.html#Compatibility"
- REL="Help"
-><STRONG>Compatibility:</STRONG></A> ClearModuleList is only available in
-Apache 1.2 and later<P>
-
-The server comes with a built-in list of active modules. This
-directive clears the list. It is assumed that the list will then be
-re-populated using the <A HREF="#addmodule">AddModule</A> directive.<P><HR>
-
-<H2><A NAME="contentdigest">ContentDigest directive</A></H2>
-<!--%plaintext <?INDEX {\tt ContentDigest} directive> -->
-<A
- HREF="directive-dict.html#Syntax"
- REL="Help"
-><STRONG>Syntax:</STRONG></A> ContentDigest on|off<BR>
-<A
- HREF="directive-dict.html#Default"
- REL="Help"
-><STRONG>Default:</STRONG></A> <CODE>ContentDigest off</CODE><BR>
-<A
- HREF="directive-dict.html#Context"
- REL="Help"
-><STRONG>Context:</STRONG></A> server config, virtual host, directory,
-.htaccess<BR>
-<A
- HREF="directive-dict.html#Override"
- REL="Help"
-><STRONG>Override:</STRONG></A> Options<BR>
-<A
- HREF="directive-dict.html#Status"
- REL="Help"
-><STRONG>Status:</STRONG></A> experimental<BR>
-<A
- HREF="directive-dict.html#Compatibility"
- REL="Help"
-><STRONG>Compatibility:</STRONG></A> ContentDigest is only available in
-Apache 1.1 and later<P>
-
-This directive enables the generation of <CODE>Content-MD5</CODE> headers
-as defined in RFC1864 respectively RFC2068.<P>
-
-MD5 is an algorithm for computing a "message digest" (sometimes called
-"fingerprint") of arbitrary-length data, with a high degree of confidence
-that any alterations in the data will be reflected in alterations in the
-message digest.<P>
-
-The <CODE>Content-MD5</CODE> header provides an end-to-end message
-integrity check (MIC) of the entity-body. A proxy or client may check this
-header for detecting accidental modification of the entity-body
-in transit.
-Example header:
-<PRE> Content-MD5: AuLb7Dp1rqtRtxz2m9kRpA==</PRE><P>
-
-Note that this can cause performance problems on your server
-since the message digest is computed on every request
-(the values are not cached).<P>
-
-<CODE>Content-MD5</CODE> is only sent for documents served by the
-core, and not by any module. For example, SSI documents, output from
-CGI scripts, and byte range responses do not have this header.
-
-<HR>
-
-<H2><A NAME="defaulttype">DefaultType directive</A></H2>
-<!--%plaintext <?INDEX {\tt DefaultType} directive> -->
-<A
- HREF="directive-dict.html#Syntax"
- REL="Help"
-><STRONG>Syntax:</STRONG></A> DefaultType <EM>MIME-type</EM><BR>
-<A
- HREF="directive-dict.html#Default"
- REL="Help"
-><STRONG>Default:</STRONG></A> <CODE>DefaultType text/html</CODE><BR>
-<A
- HREF="directive-dict.html#Context"
- REL="Help"
-><STRONG>Context:</STRONG></A> server config, virtual host, directory,
-.htaccess<BR>
-<A
- HREF="directive-dict.html#Override"
- REL="Help"
-><STRONG>Override:</STRONG></A> FileInfo<BR>
-<A
- HREF="directive-dict.html#Status"
- REL="Help"
-><STRONG>Status:</STRONG></A> core<P>
-
-There will be times when the server is asked to provide a document
-whose type cannot be determined by its MIME types mappings.<P>
-
-The server must inform the client of the content-type of the document, so in
-the event of an unknown type it uses the <CODE>DefaultType</CODE>. For
-example:
-<BLOCKQUOTE><CODE>DefaultType image/gif</CODE></BLOCKQUOTE>
-would be appropriate for a directory which contained many gif images
-with filenames missing the .gif extension.
-
-<P>Note that unlike <A HREF="#forcetype">ForceType</A>, this directive
-is only provides the default mime-type. All other mime-type definitions,
-including filename extensions, that might identify the media type will
-override this default.</P>
-
-<HR>
-
-<H2><A NAME="directory"><Directory> directive</A></H2>
-<!--%plaintext <?INDEX {\tt Directory} section directive> -->
-<A
- HREF="directive-dict.html#Syntax"
- REL="Help"
-><STRONG>Syntax:</STRONG></A> <Directory <EM>directory-path</EM>>
- ... </Directory> <BR>
-<A
- HREF="directive-dict.html#Context"
- REL="Help"
-><STRONG>Context:</STRONG></A> server config, virtual host<BR>
-<A
- HREF="directive-dict.html#Status"
- REL="Help"
-><STRONG>Status:</STRONG></A> Core. <P>
-
-<Directory> and </Directory> are used to enclose a group
-of directives which will apply only to the named directory and
-sub-directories of that directory. Any directive which is allowed in a
-directory context may be used. <EM>Directory-path</EM> is either the
-full path to a directory, or a wild-card string. In a wild-card
-string, `?' matches any single character, and `*' matches any
-sequences of characters. As of Apache 1.3, you may also use `[]'
-character ranges like in the shell. Also as of Apache 1.3 none of the
-wildcards match a `/' character, which more closely mimics the
-behaviour of Unix shells. Example: <PRE>
+<html>
+ <head>
+ <title>Apache Core Features</title>
+ </head>
+ <!-- Background white, links blue (unvisited), navy (visited), red (active) -->
+
+ <body bgcolor="#FFFFFF" text="#000000" link="#0000FF" vlink=
+ "#000080" alink="#FF0000">
+ <!--#include virtual="header.html" -->
+
+ <h1 align="CENTER">Apache Core Features</h1>
+
+ <p>These configuration parameters control the core Apache
+ features, and are always available.</p>
+
+ <h2>Directives</h2>
+
+ <ul>
+ <li><a href="#accessfilename">AccessFileName</a></li>
+
+ <li><a href="#adddefaultcharset">AddDefaultCharset</a></li>
+
+ <li><a href="#addmodule">AddModule</a></li>
+
+ <li><a href="#allowoverride">AllowOverride</a></li>
+
+ <li><a href="#authname">AuthName</a></li>
+
+ <li><a href="#authtype">AuthType</a></li>
+
+ <li><a href="#clearmodulelist">ClearModuleList</a></li>
+
+ <li><a href="#contentdigest">ContentDigest</a></li>
+
+ <li><a href="#coredumpdirectory">CoreDumpDirectory</a></li>
+
+ <li><a href="#defaulttype">DefaultType</a></li>
+
+ <li><a href="#directory"><Directory></a></li>
+
+ <li><a href="#directorymatch"><DirectoryMatch></a></li>
+
+ <li><a href="#documentroot">DocumentRoot</a></li>
+
+ <li><a href="#errordocument">ErrorDocument</a></li>
+
+ <li><a href="#errorlog">ErrorLog</a></li>
+
+ <li><a href="#files"><Files></a></li>
+
+ <li><a href="#filesmatch"><FilesMatch></a></li>
+
+ <li><a href="#forcetype">ForceType</a></li>
+
+ <li><a href="#hostnamelookups">HostNameLookups</a></li>
+
+ <li><a href="#identitycheck">IdentityCheck</a></li>
+
+ <li><a href="#ifdefine"><IfDefine></a></li>
+
+ <li><a href="#ifmodule"><IfModule></a></li>
+
+ <li><a href="#include">Include</a></li>
+
+ <li><a href="#keepalive">KeepAlive</a></li>
+
+ <li><a href="#keepalivetimeout">KeepAliveTimeout</a></li>
+
+ <li><a href="#limit"><Limit></a></li>
+
+ <li><a href="#limitexcept"><LimitExcept></a></li>
+
+ <li><a href="#limitrequestbody">LimitRequestBody</a></li>
+
+ <li><a href="#limitrequestfields">LimitRequestFields</a></li>
+
+ <li><a href=
+ "#limitrequestfieldsize">LimitRequestFieldsize</a></li>
+
+ <li><a href="#limitrequestline">LimitRequestLine</a></li>
+
+ <li><a href=
+ "#limitxmlrequestbody">LimitXMLRequestBody</a></li>
+
+ <li><a href="#location"><Location></a></li>
+
+ <li><a href="#locationmatch"><LocationMatch></a></li>
+
+ <li><a href="#loglevel">LogLevel</a></li>
+
+ <li><a href=
+ "#maxkeepaliverequests">MaxKeepAliveRequests</a></li>
+
+ <li><a href="#namevirtualhost">NameVirtualHost</a></li>
+
+ <li><a href="#options">Options</a></li>
+
+ <li><a href="#port">Port</a></li>
+
+ <li><a href="#require">Require</a></li>
+
+ <li><a href="#rlimitcpu">RLimitCPU</a></li>
+
+ <li><a href="#rlimitmem">RLimitMEM</a></li>
+
+ <li><a href="#rlimitnproc">RLimitNPROC</a></li>
+
+ <li><a href="#satisfy">Satisfy</a></li>
+
+ <li><a href=
+ "#scriptinterpretersource">ScriptInterpreterSource</a></li>
+
+ <li><a href="#serveradmin">ServerAdmin</a></li>
+
+ <li><a href="#serveralias">ServerAlias</a></li>
+
+ <li><a href="#servername">ServerName</a></li>
+
+ <li><a href="#serverpath">ServerPath</a></li>
+
+ <li><a href="#serverroot">ServerRoot</a></li>
+
+ <li><a href="#serversignature">ServerSignature</a></li>
+
+ <li><a href="#servertokens">ServerTokens</a></li>
+
+ <li><a href="#sethandler">SetHandler</a></li>
+
+ <li><a href="#setinputfilter">SetInputFilter</a></li>
+
+ <li><a href="#setoutputfilter">SetOutputFilter</a></li>
+
+ <li><a href="#timeout">TimeOut</a></li>
+
+ <li><a href="#usecanonicalname">UseCanonicalName</a></li>
+
+ <li><a href="#virtualhost"><VirtualHost></a></li>
+ </ul>
+ <hr>
+
+ <h2><a name="accessfilename">AccessFileName directive</a></h2>
+ <!--%plaintext <?INDEX {\tt AccessFileName} directive> -->
+ <a href="directive-dict.html#Syntax" rel=
+ "Help"><strong>Syntax:</strong></a> AccessFileName
+ <em>filename</em> [<em>filename</em>] ...<br>
+ <a href="directive-dict.html#Default" rel=
+ "Help"><strong>Default:</strong></a> <code>AccessFileName
+ .htaccess</code><br>
+ <a href="directive-dict.html#Context" rel=
+ "Help"><strong>Context:</strong></a> server config, virtual
+ host<br>
+ <a href="directive-dict.html#Status" rel=
+ "Help"><strong>Status:</strong></a> core<br>
+ <a href="directive-dict.html#Compatibility" rel=
+ "Help"><strong>Compatibility:</strong></a> AccessFileName can
+ accept more than one filename only in Apache 1.3 and later
+
+ <p>When returning a document to the client the server looks for
+ the first existing access control file from this list of names
+ in every directory of the path to the document, if access
+ control files are enabled for that directory. For example:</p>
+
+ <blockquote>
+ <code>AccessFileName .acl</code>
+ </blockquote>
+ before returning the document /usr/local/web/index.html, the
+ server will read /.acl, /usr/.acl, /usr/local/.acl and
+ /usr/local/web/.acl for directives, unless they have been
+ disabled with
+
+ <blockquote>
+ <code><Directory /><br>
+ AllowOverride None<br>
+ </Directory></code>
+ </blockquote>
+
+ <p><strong>See Also:</strong> <a href=
+ "#allowoverride">AllowOverride</a></p>
+ <hr>
+
+ <h2><a name="adddefaultcharset">AddDefaultCharset
+ directive</a></h2>
+ <a href="directive-dict.html#Syntax" rel=
+ "Help"><strong>Syntax:</strong></a> AddDefaultCharset
+ On|Off|<em>charset</em><br>
+ <a href="directive-dict.html#Context" rel=
+ "Help"><strong>Context:</strong></a> all<br>
+ <a href="directive-dict.html#Status" rel=
+ "Help"><strong>Status:</strong></a> core<br>
+ <a href="directive-dict.html#Default" rel=
+ "Help"><strong>Default:</strong></a> <code>AddDefaultCharset
+ Off</code><br>
+ <a href="directive-dict.html#Compatibility" rel=
+ "Help"><strong>Compatibility:</strong></a> AddDefaultCharset is
+ only available in Apache 1.3.12 and later
+
+ <p>This directive specifies the name of the character set that
+ will be added to any response that does not have any parameter
+ on the content type in the HTTP headers. This will override any
+ character set specified in the body of the document via a
+ <code>META</code> tag. A setting of <code>AddDefaultCharset
+ Off</code> disables this functionality. <code>AddDefaultCharset
+ On</code> enables Apache's internal default charset of
+ <code>iso-8859-1</code> as required by the directive. You can
+ also specify an alternate <em>charset</em> to be used; e.g.
+ <code>AddDefaultCharset utf-8</code>.</p>
+ <hr>
+
+ <h2><a name="addmodule">AddModule directive</a></h2>
+ <!--%plaintext <?INDEX {\tt AddModule} directive> -->
+ <a href="directive-dict.html#Syntax" rel=
+ "Help"><strong>Syntax:</strong></a> AddModule <em>module</em>
+ [<em>module</em>] ...<br>
+ <a href="directive-dict.html#Context" rel=
+ "Help"><strong>Context:</strong></a> server config <br>
+ <a href="directive-dict.html#Status" rel=
+ "Help"><strong>Status:</strong></a> core<br>
+ <a href="directive-dict.html#Compatibility" rel=
+ "Help"><strong>Compatibility:</strong></a> AddModule is only
+ available in Apache 1.2 and later
+
+ <p>The server can have modules compiled in which are not
+ actively in use. This directive can be used to enable the use
+ of those modules. The server comes with a pre-loaded list of
+ active modules; this list can be cleared with the <a href=
+ "#clearmodulelist">ClearModuleList</a> directive.</p>
+ <hr>
+
+ <h2><a name="allowoverride">AllowOverride directive</a></h2>
+ <!--%plaintext <?INDEX {\tt AllowOverride} directive> -->
+ <a href="directive-dict.html#Syntax" rel=
+ "Help"><strong>Syntax:</strong></a> AllowOverride
+ All|None|<em>directive-type</em> [<em>directive-type</em>]
+ ...<br>
+ <a href="directive-dict.html#Default" rel=
+ "Help"><strong>Default:</strong></a> <code>AllowOverride
+ All</code><br>
+ <a href="directive-dict.html#Context" rel=
+ "Help"><strong>Context:</strong></a> directory<br>
+ <a href="directive-dict.html#Status" rel=
+ "Help"><strong>Status:</strong></a> core
+
+ <p>When the server finds an .htaccess file (as specified by <a
+ href="#accessfilename">AccessFileName</a>) it needs to know
+ which directives declared in that file can override earlier
+ access information.</p>
+
+ <p>When this directive is set to <code>None</code>, then
+ .htaccess files are completely ignored. In this case, the
+ server will not even attempt to read .htaccess files in the
+ filesystem.</p>
+
+ <p>When this directive is set to <code>All</code>, then any
+ directive which has the .htaccess <a href=
+ "directive-dict.html#Context">Context</a> is allowed in
+ .htaccess files.</p>
+
+ <p>The <em>directive-type</em> can be one of the following
+ groupings of directives.</p>
+
+ <dl>
+ <dt>AuthConfig</dt>
+
+ <dd>
+ <!--%plaintext <?INDEX {\tt AuthConfig} override> -->
+ Allow use of the authorization directives (<a href=
+ "mod_auth_dbm.html#authdbmgroupfile">AuthDBMGroupFile</a>, <a
+ href="mod_auth_dbm.html#authdbmuserfile">AuthDBMUserFile</a>,
+ <a href="mod_auth.html#authgroupfile">AuthGroupFile</a>, <a
+ href="#authname">AuthName</a>, <a href=
+ "#authtype">AuthType</a>, <a href=
+ "mod_auth.html#authuserfile">AuthUserFile</a>, <a href=
+ "#require">Require</a>, <em>etc.</em>).</dd>
+
+ <dt>FileInfo</dt>
+
+ <dd><!--%plaintext <?INDEX {\tt FileInfo} override> -->
+ Allow use of the directives controlling document types (<a
+ href="#defaulttype">DefaultType</a>, <a href=
+ "#errordocument">ErrorDocument</a>, <a href=
+ "#forcetype">ForceType</a>, <a href=
+ "mod_negotiation.html#languagepriority">LanguagePriority</a>,
+ <a href="#sethandler">SetHandler</a>, <a href=
+ "#setinputfilter">SetInputFilter</a>, <a href=
+ "#setoutputfilter">SetOutputFilter</a>, and <a href=
+ "mod_mime.html">mod_mime Add* and Remove* directives</a>,
+ <em>etc.</em>).</dd>
+
+ <dt>Indexes</dt>
+
+ <dd><!--%plaintext <?INDEX {\tt Indexes} override> -->
+ Allow use of the directives controlling directory indexing
+ (<a href=
+ "mod_autoindex.html#adddescription">AddDescription</a>, <a
+ href="mod_autoindex.html#addicon">AddIcon</a>, <a href=
+ "mod_autoindex.html#addiconbyencoding">AddIconByEncoding</a>,
+ <a href="mod_autoindex.html#addiconbytype">AddIconByType</a>,
+ <a href="mod_autoindex.html#defaulticon">DefaultIcon</a>, <a
+ href="mod_dir.html#directoryindex">DirectoryIndex</a>, <a
+ href="mod_autoindex.html#fancyindexing">FancyIndexing</a>, <a
+ href="mod_autoindex.html#headername">HeaderName</a>, <a href=
+ "mod_autoindex.html#indexignore">IndexIgnore</a>, <a href=
+ "mod_autoindex.html#indexoptions">IndexOptions</a>, <a href=
+ "mod_autoindex.html#readmename">ReadmeName</a>,
+ <em>etc.</em>).</dd>
+
+ <dt>Limit</dt>
+
+ <dd><!--%plaintext <?INDEX {\tt Limit} override> -->
+ Allow use of the directives controlling host access (Allow,
+ Deny and Order).</dd>
+
+ <dt>Options</dt>
+
+ <dd><!--%plaintext <?INDEX {\tt Options} override> -->
+ Allow use of the directives controlling specific directory
+ features (<a href="#options">Options</a> and <a href=
+ "mod_include.html#xbithack">XBitHack</a>).</dd>
+ </dl>
+
+ <p><strong>See Also:</strong> <a href=
+ "#accessfilename">AccessFileName</a></p>
+ <hr>
+
+ <h2><a name="authname">AuthName directive</a></h2>
+ <!--%plaintext <?INDEX {\tt AuthName} directive> -->
+ <a href="directive-dict.html#Syntax" rel=
+ "Help"><strong>Syntax:</strong></a> AuthName
+ <em>auth-domain</em><br>
+ <a href="directive-dict.html#Context" rel=
+ "Help"><strong>Context:</strong></a> directory, .htaccess<br>
+ <a href="directive-dict.html#Override" rel=
+ "Help"><strong>Override:</strong></a> AuthConfig<br>
+ <a href="directive-dict.html#Status" rel=
+ "Help"><strong>Status:</strong></a> core
+
+ <p>This directive sets the name of the authorization realm for
+ a directory. This realm is given to the client so that the user
+ knows which username and password to send.
+ <samp>AuthName</samp> takes a single argument; if the realm
+ name contains spaces, it must be enclosed in quotation marks.
+ It must be accompanied by <a href="#authtype">AuthType</a> and
+ <a href="#require">Require</a> directives, and directives such
+ as <a href="mod_auth.html#authuserfile">AuthUserFile</a> and <a
+ href="mod_auth.html#authgroupfile">AuthGroupFile</a> to
+ work.</p>
+ <hr>
+
+ <h2><a name="authtype">AuthType directive</a></h2>
+ <!--%plaintext <?INDEX {\tt AuthType} directive> -->
+ <a href="directive-dict.html#Syntax" rel=
+ "Help"><strong>Syntax:</strong></a> AuthType Basic|Digest<br>
+ <a href="directive-dict.html#Context" rel=
+ "Help"><strong>Context:</strong></a> directory, .htaccess<br>
+ <a href="directive-dict.html#Override" rel=
+ "Help"><strong>Override:</strong></a> AuthConfig<br>
+ <a href="directive-dict.html#Status" rel=
+ "Help"><strong>Status:</strong></a> core
+
+ <p>This directive selects the type of user authentication for a
+ directory. Only <code>Basic</code> and <code>Digest</code> are
+ currently implemented.
+ <!--%plaintext <?INDEX {\tt Basic} authentication scheme> -->
+ It must be accompanied by <a href="#authname">AuthName</a> and
+ <a href="#require">Require</a> directives, and directives such
+ as <a href="mod_auth.html#authuserfile">AuthUserFile</a> and <a
+ href="mod_auth.html#authgroupfile">AuthGroupFile</a> to
+ work.</p>
+ <hr>
+
+ <h2><a name="clearmodulelist">ClearModuleList
+ directive</a></h2>
+ <!--%plaintext <?INDEX {\tt ClearModuleList} directive> -->
+ <a href="directive-dict.html#Syntax" rel=
+ "Help"><strong>Syntax:</strong></a> ClearModuleList<br>
+ <a href="directive-dict.html#Context" rel=
+ "Help"><strong>Context:</strong></a> server config<br>
+ <a href="directive-dict.html#Status" rel=
+ "Help"><strong>Status:</strong></a> core<br>
+ <a href="directive-dict.html#Compatibility" rel=
+ "Help"><strong>Compatibility:</strong></a> ClearModuleList is
+ only available in Apache 1.2 and later
+
+ <p>The server comes with a built-in list of active modules.
+ This directive clears the list. It is assumed that the list
+ will then be re-populated using the <a href=
+ "#addmodule">AddModule</a> directive.</p>
+ <hr>
+
+ <h2><a name="contentdigest">ContentDigest directive</a></h2>
+ <!--%plaintext <?INDEX {\tt ContentDigest} directive> -->
+ <a href="directive-dict.html#Syntax" rel=
+ "Help"><strong>Syntax:</strong></a> ContentDigest on|off<br>
+ <a href="directive-dict.html#Default" rel=
+ "Help"><strong>Default:</strong></a> <code>ContentDigest
+ off</code><br>
+ <a href="directive-dict.html#Context" rel=
+ "Help"><strong>Context:</strong></a> server config, virtual
+ host, directory, .htaccess<br>
+ <a href="directive-dict.html#Override" rel=
+ "Help"><strong>Override:</strong></a> Options<br>
+ <a href="directive-dict.html#Status" rel=
+ "Help"><strong>Status:</strong></a> experimental<br>
+ <a href="directive-dict.html#Compatibility" rel=
+ "Help"><strong>Compatibility:</strong></a> ContentDigest is
+ only available in Apache 1.1 and later
+
+ <p>This directive enables the generation of
+ <code>Content-MD5</code> headers as defined in RFC1864
+ respectively RFC2068.</p>
+
+ <p>MD5 is an algorithm for computing a "message digest"
+ (sometimes called "fingerprint") of arbitrary-length data, with
+ a high degree of confidence that any alterations in the data
+ will be reflected in alterations in the message digest.</p>
+
+ <p>The <code>Content-MD5</code> header provides an end-to-end
+ message integrity check (MIC) of the entity-body. A proxy or
+ client may check this header for detecting accidental
+ modification of the entity-body in transit. Example header:</p>
+<pre>
+ Content-MD5: AuLb7Dp1rqtRtxz2m9kRpA==
+</pre>
+
+ <p>Note that this can cause performance problems on your server
+ since the message digest is computed on every request (the
+ values are not cached).</p>
+
+ <p><code>Content-MD5</code> is only sent for documents served
+ by the core, and not by any module. For example, SSI documents,
+ output from CGI scripts, and byte range responses do not have
+ this header.</p>
+ <hr>
+
+ <h2><a name="defaulttype">DefaultType directive</a></h2>
+ <!--%plaintext <?INDEX {\tt DefaultType} directive> -->
+ <a href="directive-dict.html#Syntax" rel=
+ "Help"><strong>Syntax:</strong></a> DefaultType
+ <em>MIME-type</em><br>
+ <a href="directive-dict.html#Default" rel=
+ "Help"><strong>Default:</strong></a> <code>DefaultType
+ text/html</code><br>
+ <a href="directive-dict.html#Context" rel=
+ "Help"><strong>Context:</strong></a> server config, virtual
+ host, directory, .htaccess<br>
+ <a href="directive-dict.html#Override" rel=
+ "Help"><strong>Override:</strong></a> FileInfo<br>
+ <a href="directive-dict.html#Status" rel=
+ "Help"><strong>Status:</strong></a> core
+
+ <p>There will be times when the server is asked to provide a
+ document whose type cannot be determined by its MIME types
+ mappings.</p>
+
+ <p>The server must inform the client of the content-type of the
+ document, so in the event of an unknown type it uses the
+ <code>DefaultType</code>. For example:</p>
+
+ <blockquote>
+ <code>DefaultType image/gif</code>
+ </blockquote>
+ would be appropriate for a directory which contained many gif
+ images with filenames missing the .gif extension.
+
+ <p>Note that unlike <a href="#forcetype">ForceType</a>, this
+ directive is only provides the default mime-type. All other
+ mime-type definitions, including filename extensions, that
+ might identify the media type will override this default.</p>
+ <hr>
+
+ <h2><a name="directory"><Directory> directive</a></h2>
+ <!--%plaintext <?INDEX {\tt Directory} section directive> -->
+ <a href="directive-dict.html#Syntax" rel=
+ "Help"><strong>Syntax:</strong></a> <Directory
+ <em>directory-path</em>> ... </Directory> <br>
+ <a href="directive-dict.html#Context" rel=
+ "Help"><strong>Context:</strong></a> server config, virtual
+ host<br>
+ <a href="directive-dict.html#Status" rel=
+ "Help"><strong>Status:</strong></a> Core.
+
+ <p><Directory> and </Directory> are used to enclose
+ a group of directives which will apply only to the named
+ directory and sub-directories of that directory. Any directive
+ which is allowed in a directory context may be used.
+ <em>Directory-path</em> is either the full path to a directory,
+ or a wild-card string. In a wild-card string, `?' matches any
+ single character, and `*' matches any sequences of characters.
+ As of Apache 1.3, you may also use `[]' character ranges like
+ in the shell. Also as of Apache 1.3 none of the wildcards match
+ a `/' character, which more closely mimics the behavior of
+ Unix shells. Example:</p>
+<pre>
<Directory /usr/local/httpd/htdocs>
Options Indexes FollowSymLinks
</Directory>
-</PRE>
-
-<P><STRONG>Apache 1.2 and above:</STRONG>
-Extended regular expressions can also be used, with the addition of the
-<CODE>~</CODE> character. For example:</P>
-
-<PRE>
- <Directory ~ "^/www/.*/[0-9]{3}">
-</PRE>
-
-would match directories in /www/ that consisted of three numbers.
-
-<P>If multiple (non-regular expression) directory sections match the
-directory (or its parents) containing
-a document, then the directives are applied in the order of shortest match
-first, interspersed with the directives from the
-<A HREF="#accessfilename">.htaccess</A> files. For example, with
-<BLOCKQUOTE><CODE>
-<Directory /><BR>
-AllowOverride None<BR>
-</Directory><BR><BR>
-<Directory /home/*><BR>
-AllowOverride FileInfo<BR>
-</Directory></CODE></BLOCKQUOTE>
-for access to the document <CODE>/home/web/dir/doc.html</CODE> the
-steps are:
-<MENU>
-<LI>Apply directive <CODE>AllowOverride None</CODE> (disabling
-<CODE>.htaccess</CODE> files).
-<LI>Apply directive <CODE>AllowOverride FileInfo</CODE> (for directory
-<CODE>/home/web</CODE>).
-<LI>Apply any FileInfo directives in <CODE>/home/web/.htaccess</CODE>
-</MENU>
-
-<P>
-Regular expression directory sections are handled slightly differently
-by Apache 1.2 and 1.3. In Apache 1.2 they are interspersed with the normal
-directory sections and applied in the order they appear in the configuration
-file. They are applied only once, and apply when the shortest match
-possible occurs. In Apache 1.3 regular expressions are not considered
-until after all of the normal sections have been applied. Then all of
-the regular expressions are tested in the order they appeared in the
-configuration file. For example, with
-<BLOCKQUOTE><CODE>
-<Directory ~ abc$><BR>
-... directives here ...<BR>
-</Directory><BR>
-</CODE></BLOCKQUOTE>
-Suppose that the filename being accessed is
-<CODE>/home/abc/public_html/abc/index.html</CODE>. The server
-considers each of <CODE>/</CODE>, <CODE>/home</CODE>, <CODE>/home/abc</CODE>,
-<CODE>/home/abc/public_html</CODE>, and <CODE>/home/abc/public_html/abc</CODE>
-in that order. In Apache 1.2, when
-<CODE>/home/abc</CODE> is considered, the regular expression will match
-and be applied. In Apache 1.3 the regular expression isn't considered
-at all at that point in the tree. It won't be considered until after
-all normal <Directory>s and <CODE>.htaccess</CODE> files have
-been applied. Then the regular expression will
-match on <CODE>/home/abc/public_html/abc</CODE> and be applied.
-
-<P>
-
-<STRONG>
-Note that the default Apache access for <Directory /> is
-<SAMP>Allow from All</SAMP>. This means that Apache will serve any file
-mapped from an URL. It is recommended that you change this with a block
-such as
-</STRONG>
-<PRE>
+</pre>
+
+ <p><strong>Apache 1.2 and above:</strong> Extended regular
+ expressions can also be used, with the addition of the
+ <code>~</code> character. For example:</p>
+<pre>
+ <Directory ~ "^/www/.*/[0-9]{3}">
+</pre>
+ would match directories in /www/ that consisted of three
+ numbers.
+
+ <p>If multiple (non-regular expression) directory sections
+ match the directory (or its parents) containing a document,
+ then the directives are applied in the order of shortest match
+ first, interspersed with the directives from the <a href=
+ "#accessfilename">.htaccess</a> files. For example, with</p>
+
+ <blockquote>
+ <code><Directory /><br>
+ AllowOverride None<br>
+ </Directory><br>
+ <br>
+ <Directory /home/*><br>
+ AllowOverride FileInfo<br>
+ </Directory></code>
+ </blockquote>
+ for access to the document <code>/home/web/dir/doc.html</code>
+ the steps are:
+
+ <ul>
+ <li>Apply directive <code>AllowOverride None</code>
+ (disabling <code>.htaccess</code> files).</li>
+
+ <li>Apply directive <code>AllowOverride FileInfo</code> (for
+ directory <code>/home/web</code>).</li>
+
+ <li>Apply any FileInfo directives in
+ <code>/home/web/.htaccess</code></li>
+ </ul>
+
+ <p>Regular expression directory sections are handled slightly
+ differently by Apache 1.2 and 1.3. In Apache 1.2 they are
+ interspersed with the normal directory sections and applied in
+ the order they appear in the configuration file. They are
+ applied only once, and apply when the shortest match possible
+ occurs. In Apache 1.3 regular expressions are not considered
+ until after all of the normal sections have been applied. Then
+ all of the regular expressions are tested in the order they
+ appeared in the configuration file. For example, with</p>
+
+ <blockquote>
+ <code><Directory ~ abc$><br>
+ ... directives here ...<br>
+ </Directory><br>
+ </code>
+ </blockquote>
+ Suppose that the filename being accessed is
+ <code>/home/abc/public_html/abc/index.html</code>. The server
+ considers each of <code>/</code>, <code>/home</code>,
+ <code>/home/abc</code>, <code>/home/abc/public_html</code>, and
+ <code>/home/abc/public_html/abc</code> in that order. In Apache
+ 1.2, when <code>/home/abc</code> is considered, the regular
+ expression will match and be applied. In Apache 1.3 the regular
+ expression isn't considered at all at that point in the tree.
+ It won't be considered until after all normal
+ <Directory>s and <code>.htaccess</code> files have been
+ applied. Then the regular expression will match on
+ <code>/home/abc/public_html/abc</code> and be applied.
+
+ <p><strong>Note that the default Apache access for
+ <Directory /> is <samp>Allow from All</samp>. This means
+ that Apache will serve any file mapped from an URL. It is
+ recommended that you change this with a block such
+ as</strong></p>
+<pre>
<Directory />
Order Deny,Allow
Deny from All
</Directory>
-</PRE>
-<P>
-<STRONG>
-and then override this for directories you <EM>want</EM> accessible.
-See the
-<A
- HREF="../misc/security_tips.html"
->Security Tips</A>
-page for more details.
-</STRONG>
-</P>
-
-The directory sections typically occur in the access.conf file, but they
-may appear in any configuration file. <Directory> directives cannot
-nest, and cannot appear in a <A HREF="#limit"><Limit></A> or
-<A HREF="#limitexcept"><LimitExcept></A> section.
-<P>
-
-<STRONG>See also</STRONG>: <A HREF="../sections.html">How Directory,
-Location and Files sections work</A> for an explanation of how these
-different sections are combined when a request is received
-
-<HR>
-
-<H2><A NAME="directorymatch"><DirectoryMatch></A></H2>
-<A
- HREF="directive-dict.html#Syntax"
- REL="Help"
-><STRONG>Syntax:</STRONG></A> <DirectoryMatch <EM>regex</EM>>
- ... </DirectoryMatch> <BR>
-<A
- HREF="directive-dict.html#Context"
- REL="Help"
-><STRONG>Context:</STRONG></A> server config, virtual host<BR>
-<A
- HREF="directive-dict.html#Status"
- REL="Help"
-><STRONG>Status:</STRONG></A> Core.<BR>
-<A
- HREF="directive-dict.html#Compatibility"
- REL="Help"
-><STRONG>Compatibility:</STRONG></A> Available in Apache 1.3 and later
-
-<P><DirectoryMatch> and </DirectoryMatch> are used to enclose a
-group of
-directives which will apply only to the named directory and sub-directories
-of that directory, the same as <A
-HREF="#directory"><Directory></A>. However, it takes as an
-argument a regular expression. For example:</P>
-
-<PRE>
- <DirectoryMatch "^/www/.*/[0-9]{3}">
-</PRE>
-
-<P>would match directories in /www/ that consisted of three numbers.</P>
-
-<P><STRONG>See Also:</STRONG>
-<A HREF="#directory"><Directory></A> for a description of how
-regular expressions are mixed in with normal <Directory>s.
-<BR>
-<STRONG>See also</STRONG>: <A HREF="../sections.html">How Directory,
-Location and Files sections work</A> for an explanation of how these
-different sections are combined when a request is received
-
-<HR>
-
-<H2><A NAME="documentroot">DocumentRoot directive</A></H2>
-<!--%plaintext <?INDEX {\tt DocumentRoot} directive> -->
-<A
- HREF="directive-dict.html#Syntax"
- REL="Help"
-><STRONG>Syntax:</STRONG></A> DocumentRoot <EM>directory-path</EM><BR>
-<A
- HREF="directive-dict.html#Default"
- REL="Help"
-><STRONG>Default:</STRONG></A> <CODE>DocumentRoot
-/usr/local/apache/htdocs</CODE><BR>
-<A
- HREF="directive-dict.html#Context"
- REL="Help"
-><STRONG>Context:</STRONG></A> server config, virtual host<BR>
-<A
- HREF="directive-dict.html#Status"
- REL="Help"
-><STRONG>Status:</STRONG></A> core<P>
-
-This directive sets the directory from which httpd will serve files.
-Unless matched by a directive like Alias, the server appends the path
-from the requested URL to the document root to make the path to the
-document. Example:
-<BLOCKQUOTE><CODE>DocumentRoot /usr/web</CODE></BLOCKQUOTE>
-then an access to <CODE>http://www.my.host.com/index.html</CODE> refers
-to <CODE>/usr/web/index.html</CODE>.
-
-<P>There appears to be a bug in mod_dir which causes problems when the
-DocumentRoot has a trailing slash (<EM>i.e.</EM>, "DocumentRoot /usr/web/") so
-please avoid that.
-
-<P><HR>
-
-<H2><A NAME="errordocument">ErrorDocument directive</A></H2>
-<!--%plaintext <?INDEX {\tt ErrorDocument} directive> -->
-<A
- HREF="directive-dict.html#Syntax"
- REL="Help"
-><STRONG>Syntax:</STRONG></A> ErrorDocument <EM>error-code document</EM><BR>
-<A
- HREF="directive-dict.html#Context"
- REL="Help"
-><STRONG>Context:</STRONG></A> server config, virtual host, directory,
-.htaccess<BR>
-<A
- HREF="directive-dict.html#Status"
- REL="Help"
-><STRONG>Status:</STRONG></A> core<BR>
-<A
- HREF="directive-dict.html#Override"
- REL="Help"
-><STRONG>Override:</STRONG></A> FileInfo<BR>
-<A
- HREF="directive-dict.html#Compatibility"
- REL="Help"
-><STRONG>Compatibility:</STRONG></A> The directory and .htaccess contexts
-are only available in Apache 1.1 and later. The quoting syntax prior to
-Apache 2.0 was different.<P>
-
-In the event of a problem or error, Apache can be configured to do
-one of four things,
-
-<OL>
-<LI>output a simple hardcoded error message
-<LI>output a customized message
-<LI>redirect to a local <em>URL-path</em> to handle the problem/error
-<LI>redirect to an external <em>URL</em> to handle the problem/error
-</OL>
-
-<P>The first option is the default, while options 2-4 are configured
-using the <CODE>ErrorDocument</CODE> directive, which is followed by
-the HTTP response code and a URL or a message. Apache will sometimes
-offer additional information regarding the problem/error.
-
-<P>URLs can begin with a slash (/) for local URLs, or be a full
-URL which the client can resolve. Alternatively, a message can be
-provided to be displayed by the browser. Examples:
-<BLOCKQUOTE><CODE>
-ErrorDocument 500 http://foo.example.com/cgi-bin/tester<BR>
-ErrorDocument 404 /cgi-bin/bad_urls.pl<BR>
-ErrorDocument 401 /subscription_info.html<BR>
-ErrorDocument 403 "Sorry can't allow you access today"
-</CODE></BLOCKQUOTE>
-
-<P>Note that when you specify an <CODE>ErrorDocument</CODE> that
-points to a remote URL (ie. anything with a method such as "http" in
-front of it), Apache will send a redirect to the client to tell it
-where to find the document, even if the document ends up being on the
-same server. This has several implications, the most important being
-that the client will not receive the original error status code, but
-instead will receive a redirect status code. This in turn can confuse
-web robots and other clients which try to determine if a URL is valid
-using the status code. In addition, if you use a remote URL in an
-<code>ErrorDocument 401</code>, the client will not know to prompt the
-user for a password since it will not receive the 401 status
-code. Therefore, <STRONG>if you use an "ErrorDocument 401" directive
-then it must refer to a local document.</STRONG>
-
-
-<P>Prior to version 2.0, messages were indicated by prefixing them
-with a single unmatched double quote character.
-
-<P>See Also: <A HREF="../custom-error.html">documentation of customizable
-responses.</A><P><HR>
-
-<H2><A NAME="errorlog">ErrorLog directive</A></H2>
-<!--%plaintext <?INDEX {\tt ErrorLog} directive> -->
-<A
- HREF="directive-dict.html#Syntax"
- REL="Help"
-><STRONG>Syntax:</STRONG></A> ErrorLog <EM>file-path</EM>|syslog[:<em>facility</em>]
-<BR>
-<A
- HREF="directive-dict.html#Default"
- REL="Help"
-><STRONG>Default:</STRONG></A> <CODE>ErrorLog logs/error_log</CODE> (Unix)<BR>
-<A
- HREF="directive-dict.html#Default"
- REL="Help"
-><STRONG>Default:</STRONG></A> <CODE>ErrorLog logs/error.log</CODE>
- (Windows and OS/2)<BR>
-<A
- HREF="directive-dict.html#Context"
- REL="Help"
-><STRONG>Context:</STRONG></A> server config, virtual host<BR>
-<A
- HREF="directive-dict.html#Status"
- REL="Help"
-><STRONG>Status:</STRONG></A> core<P>
-
-The error log directive sets the name of the file to which the server
-will log any errors it encounters. If the <em>file-path</em> does not
-begin with a slash (/) then it is assumed to be relative to the <A
-HREF="#serverroot">ServerRoot</A>. If the <em>file-path</em> begins
-with a pipe (|) then it is assumed to be a command to spawn to handle
-the error log.
-
-<P><STRONG>Apache 1.3 and above:</STRONG>
-Using <CODE>syslog</CODE> instead of a filename enables logging via syslogd(8)
-if the system supports it. The default is to use syslog facility
-<CODE>local7</CODE>, but you can override this by using the
-<CODE>syslog:</CODE><EM>facility</EM> syntax where <EM>facility</EM> can be
-one of the names usually documented in syslog(1).
-
-<P>
-SECURITY: See the
-<A HREF="../misc/security_tips.html#serverroot">security tips</A>
-document for details on why your security could be compromised if
-the directory where logfiles are stored is writable by anyone other
-than the user that starts the server.
-
-<P><STRONG>See also:</STRONG> <A HREF="#loglevel">LogLevel</A> and
-<a href="../logs.html">Apache Log Files</a>
-<P><HR>
-
-<H2><A NAME="files"><Files> directive</A></H2>
-<A
- HREF="directive-dict.html#Syntax"
- REL="Help"
-><STRONG>Syntax:</STRONG></A> <Files <EM>filename</EM>>
-... </Files><BR>
-<A
- HREF="directive-dict.html#Context"
- REL="Help"
-><STRONG>Context:</STRONG></A> server config, virtual host, .htaccess<BR>
-<A
- HREF="directive-dict.html#Status"
- REL="Help"
-><STRONG>Status:</STRONG></A> core<BR>
-<A
- HREF="directive-dict.html#Compatibility"
- REL="Help"
-><STRONG>Compatibility:</STRONG></A> only available in Apache
-1.2 and above.<P>
-
-<P>The <Files> directive provides for access control by
-filename. It is comparable to the <A
-HREF="#directory"><Directory></A> directive and
-<A HREF="#location"><Location></A> directives. It
-should be matched with a </Files> directive. The
-directives given within this section will be applied to any
-object with a basename (last component of filename) matching
-the specified filename.
-<CODE><Files></CODE> sections are processed in the
-order they appear in the configuration file, after the
-<Directory> sections and <CODE>.htaccess</CODE> files are
-read, but before <Location> sections. Note that
-<Files> can be nested inside <Directory>
-sections to restrict the portion of the filesystem they
-apply to.</P>
-
-<P>The <EM>filename</EM> argument should include a filename, or a
-wild-card string, where `?' matches any single character, and `*' matches any
-sequences of characters. Extended regular expressions can also be used,
-with the addition of
-the <CODE>~</CODE> character. For example:</P>
-
-<PRE>
- <Files ~ "\.(gif|jpe?g|png)$">
-</PRE>
-
-would match most common Internet graphics formats. In Apache 1.3 and
-later, <A HREF="#filesmatch"><FilesMatch></A> is preferred,
-however.
-
-<P>Note that unlike <A
-HREF="#directory"><CODE><Directory></CODE></A> and <A
-HREF="#location"><CODE><Location></CODE></A> sections,
-<CODE><Files></CODE> sections can be used inside .htaccess
-files. This allows users to control access to their own files, at a
-file-by-file level.
-
-<P>
-
-<STRONG>See also</STRONG>: <A HREF="../sections.html">How Directory,
-Location and Files sections work</A> for an explanation of how these
-different sections are combined when a request is received
-
-<HR>
-
-<H2><A NAME="filesmatch"><FilesMatch></A></H2>
-<A
- HREF="directive-dict.html#Syntax"
- REL="Help"
-><STRONG>Syntax:</STRONG></A> <FilesMatch <EM>regex</EM>>
-... </FilesMatch><BR>
-<A
- HREF="directive-dict.html#Context"
- REL="Help"
-><STRONG>Context:</STRONG></A> server config, virtual host, .htaccess<BR>
-<A
- HREF="directive-dict.html#Status"
- REL="Help"
-><STRONG>Status:</STRONG></A> core<BR>
-<A
- HREF="directive-dict.html#Compatibility"
- REL="Help"
-><STRONG>Compatibility:</STRONG></A> only available in Apache
-1.3 and above.<P>
-
-<P>The <FilesMatch> directive provides for access control by
-filename, just as the <A HREF="#files"><Files></A> directive
-does. However, it accepts a regular expression. For example:</P>
-
-<PRE>
- <FilesMatch "\.(gif|jpe?g|png)$">
-</PRE>
-
-<P>would match most common Internet graphics formats.</P>
-
-<STRONG>See also</STRONG>: <A HREF="../sections.html">How Directory,
-Location and Files sections work</A> for an explanation of how these
-different sections are combined when a request is received
-
-<HR>
-
-<h2><a name="forcetype">ForceType</a> directive</h2>
-
-<a
- href="directive-dict.html#Syntax"
- rel="Help"
-><strong>Syntax:</strong></a> ForceType <em>mime-type</em><br>
-<a
- href="directive-dict.html#Context"
- rel="Help"
-><strong>Context:</strong></a> directory, .htaccess<br>
-<a
- href="directive-dict.html#Status"
- rel="Help"
-><strong>Status:</strong></a> Base<br>
-<a
- href="directive-dict.html#Module"
- rel="Help"
-><strong>Module:</strong></a> core<br>
-<a
- href="directive-dict.html#Compatibility"
- rel="Help"
-><strong>Compatibility:</strong></a> ForceType was introduced in mod_mime
-with Apache 1.1, and moved to the core in Apache 2.0.<P>
-
-<P>When placed into an <code>.htaccess</code> file or a
-<code><Directory></code>, or <code><Location></code> or
-or <code><Files></code> section, this directive forces all matching
-files to be served with the content type identification given by
-<em>mime-type</em>. For example, if you had a directory full of GIF
-files, but did not want to label them all with ".gif", you might want to use:
+</pre>
+
+ <p><strong>and then override this for directories you
+ <em>want</em> accessible. See the <a href=
+ "../misc/security_tips.html">Security Tips</a> page for more
+ details.</strong></p>
+ The directory sections typically occur in the access.conf file,
+ but they may appear in any configuration file.
+ <Directory> directives cannot nest, and cannot appear in
+ a <a href="#limit"><Limit></a> or <a href=
+ "#limitexcept"><LimitExcept></a> section.
+
+ <p><strong>See also</strong>: <a href="../sections.html">How
+ Directory, Location and Files sections work</a> for an
+ explanation of how these different sections are combined when a
+ request is received</p>
+ <hr>
+
+ <h2><a name="directorymatch"><DirectoryMatch></a></h2>
+ <a href="directive-dict.html#Syntax" rel=
+ "Help"><strong>Syntax:</strong></a> <DirectoryMatch
+ <em>regex</em>> ... </DirectoryMatch> <br>
+ <a href="directive-dict.html#Context" rel=
+ "Help"><strong>Context:</strong></a> server config, virtual
+ host<br>
+ <a href="directive-dict.html#Status" rel=
+ "Help"><strong>Status:</strong></a> Core.<br>
+ <a href="directive-dict.html#Compatibility" rel=
+ "Help"><strong>Compatibility:</strong></a> Available in Apache
+ 1.3 and later
+
+ <p><DirectoryMatch> and </DirectoryMatch> are used
+ to enclose a group of directives which will apply only to the
+ named directory and sub-directories of that directory, the same
+ as <a href="#directory"><Directory></a>. However, it
+ takes as an argument a regular expression. For example:</p>
+<pre>
+ <DirectoryMatch "^/www/.*/[0-9]{3}">
+</pre>
+
+ <p>would match directories in /www/ that consisted of three
+ numbers.</p>
+
+ <p><strong>See Also:</strong> <a href=
+ "#directory"><Directory></a> for a description of how
+ regular expressions are mixed in with normal
+ <Directory>s.<br>
+ <strong>See also</strong>: <a href="../sections.html">How
+ Directory, Location and Files sections work</a> for an
+ explanation of how these different sections are combined when a
+ request is received</p>
+ <hr>
+
+ <h2><a name="documentroot">DocumentRoot directive</a></h2>
+ <!--%plaintext <?INDEX {\tt DocumentRoot} directive> -->
+ <a href="directive-dict.html#Syntax" rel=
+ "Help"><strong>Syntax:</strong></a> DocumentRoot
+ <em>directory-path</em><br>
+ <a href="directive-dict.html#Default" rel=
+ "Help"><strong>Default:</strong></a> <code>DocumentRoot
+ /usr/local/apache/htdocs</code><br>
+ <a href="directive-dict.html#Context" rel=
+ "Help"><strong>Context:</strong></a> server config, virtual
+ host<br>
+ <a href="directive-dict.html#Status" rel=
+ "Help"><strong>Status:</strong></a> core
+
+ <p>This directive sets the directory from which httpd will
+ serve files. Unless matched by a directive like Alias, the
+ server appends the path from the requested URL to the document
+ root to make the path to the document. Example:</p>
+
+ <blockquote>
+ <code>DocumentRoot /usr/web</code>
+ </blockquote>
+ then an access to
+ <code>http://www.my.host.com/index.html</code> refers to
+ <code>/usr/web/index.html</code>.
+
+ <p>There appears to be a bug in mod_dir which causes problems
+ when the DocumentRoot has a trailing slash (<em>i.e.</em>,
+ "DocumentRoot /usr/web/") so please avoid that.</p>
+ <hr>
+
+ <h2><a name="errordocument">ErrorDocument directive</a></h2>
+ <!--%plaintext <?INDEX {\tt ErrorDocument} directive> -->
+ <a href="directive-dict.html#Syntax" rel=
+ "Help"><strong>Syntax:</strong></a> ErrorDocument
+ <em>error-code document</em><br>
+ <a href="directive-dict.html#Context" rel=
+ "Help"><strong>Context:</strong></a> server config, virtual
+ host, directory, .htaccess<br>
+ <a href="directive-dict.html#Status" rel=
+ "Help"><strong>Status:</strong></a> core<br>
+ <a href="directive-dict.html#Override" rel=
+ "Help"><strong>Override:</strong></a> FileInfo<br>
+ <a href="directive-dict.html#Compatibility" rel=
+ "Help"><strong>Compatibility:</strong></a> The directory and
+ .htaccess contexts are only available in Apache 1.1 and later.
+ The quoting syntax prior to Apache 2.0 was different.
+
+ <p>In the event of a problem or error, Apache can be configured
+ to do one of four things,</p>
+
+ <ol>
+ <li>output a simple hardcoded error message</li>
+
+ <li>output a customized message</li>
+
+ <li>redirect to a local <em>URL-path</em> to handle the
+ problem/error</li>
+
+ <li>redirect to an external <em>URL</em> to handle the
+ problem/error</li>
+ </ol>
+
+ <p>The first option is the default, while options 2-4 are
+ configured using the <code>ErrorDocument</code> directive,
+ which is followed by the HTTP response code and a URL or a
+ message. Apache will sometimes offer additional information
+ regarding the problem/error.</p>
+
+ <p>URLs can begin with a slash (/) for local URLs, or be a full
+ URL which the client can resolve. Alternatively, a message can
+ be provided to be displayed by the browser. Examples:</p>
+
+ <blockquote>
+ <code>ErrorDocument 500
+ http://foo.example.com/cgi-bin/tester<br>
+ ErrorDocument 404 /cgi-bin/bad_urls.pl<br>
+ ErrorDocument 401 /subscription_info.html<br>
+ ErrorDocument 403 "Sorry can't allow you access
+ today"</code>
+ </blockquote>
+
+ <p>Note that when you specify an <code>ErrorDocument</code>
+ that points to a remote URL (ie. anything with a method such as
+ "http" in front of it), Apache will send a redirect to the
+ client to tell it where to find the document, even if the
+ document ends up being on the same server. This has several
+ implications, the most important being that the client will not
+ receive the original error status code, but instead will
+ receive a redirect status code. This in turn can confuse web
+ robots and other clients which try to determine if a URL is
+ valid using the status code. In addition, if you use a remote
+ URL in an <code>ErrorDocument 401</code>, the client will not
+ know to prompt the user for a password since it will not
+ receive the 401 status code. Therefore, <strong>if you use an
+ "ErrorDocument 401" directive then it must refer to a local
+ document.</strong></p>
+
+ <p>Prior to version 2.0, messages were indicated by prefixing
+ them with a single unmatched double quote character.</p>
+
+ <p>See Also: <a href="../custom-error.html">documentation of
+ customizable responses.</a></p>
+ <hr>
+
+ <h2><a name="errorlog">ErrorLog directive</a></h2>
+ <!--%plaintext <?INDEX {\tt ErrorLog} directive> -->
+ <a href="directive-dict.html#Syntax" rel=
+ "Help"><strong>Syntax:</strong></a> ErrorLog
+ <em>file-path</em>|syslog[:<em>facility</em>] <br>
+ <a href="directive-dict.html#Default" rel=
+ "Help"><strong>Default:</strong></a> <code>ErrorLog
+ logs/error_log</code> (Unix)<br>
+ <a href="directive-dict.html#Default" rel=
+ "Help"><strong>Default:</strong></a> <code>ErrorLog
+ logs/error.log</code> (Windows and OS/2)<br>
+ <a href="directive-dict.html#Context" rel=
+ "Help"><strong>Context:</strong></a> server config, virtual
+ host<br>
+ <a href="directive-dict.html#Status" rel=
+ "Help"><strong>Status:</strong></a> core
+
+ <p>The error log directive sets the name of the file to which
+ the server will log any errors it encounters. If the
+ <em>file-path</em> does not begin with a slash (/) then it is
+ assumed to be relative to the <a href=
+ "#serverroot">ServerRoot</a>. If the <em>file-path</em> begins
+ with a pipe (|) then it is assumed to be a command to spawn to
+ handle the error log.</p>
+
+ <p><strong>Apache 1.3 and above:</strong> Using
+ <code>syslog</code> instead of a filename enables logging via
+ syslogd(8) if the system supports it. The default is to use
+ syslog facility <code>local7</code>, but you can override this
+ by using the <code>syslog:</code><em>facility</em> syntax where
+ <em>facility</em> can be one of the names usually documented in
+ syslog(1).</p>
+
+ <p>SECURITY: See the <a href=
+ "../misc/security_tips.html#serverroot">security tips</a>
+ document for details on why your security could be compromised
+ if the directory where logfiles are stored is writable by
+ anyone other than the user that starts the server.</p>
+
+ <p><strong>See also:</strong> <a href="#loglevel">LogLevel</a>
+ and <a href="../logs.html">Apache Log Files</a></p>
+ <hr>
+
+ <h2><a name="files"><Files> directive</a></h2>
+ <a href="directive-dict.html#Syntax" rel=
+ "Help"><strong>Syntax:</strong></a> <Files
+ <em>filename</em>> ... </Files><br>
+ <a href="directive-dict.html#Context" rel=
+ "Help"><strong>Context:</strong></a> server config, virtual
+ host, .htaccess<br>
+ <a href="directive-dict.html#Status" rel=
+ "Help"><strong>Status:</strong></a> core<br>
+ <a href="directive-dict.html#Compatibility" rel=
+ "Help"><strong>Compatibility:</strong></a> only available in
+ Apache 1.2 and above.
+
+ <p>The <Files> directive provides for access control by
+ filename. It is comparable to the <a href=
+ "#directory"><Directory></a> directive and <a href=
+ "#location"><Location></a> directives. It should be
+ matched with a </Files> directive. The directives given
+ within this section will be applied to any object with a
+ basename (last component of filename) matching the specified
+ filename. <code><Files></code> sections are processed in
+ the order they appear in the configuration file, after the
+ <Directory> sections and <code>.htaccess</code> files are
+ read, but before <Location> sections. Note that
+ <Files> can be nested inside <Directory> sections
+ to restrict the portion of the filesystem they apply to.</p>
+
+ <p>The <em>filename</em> argument should include a filename, or
+ a wild-card string, where `?' matches any single character, and
+ `*' matches any sequences of characters. Extended regular
+ expressions can also be used, with the addition of the
+ <code>~</code> character. For example:</p>
+<pre>
+ <Files ~ "\.(gif|jpe?g|png)$">
+</pre>
+ would match most common Internet graphics formats. In Apache
+ 1.3 and later, <a href="#filesmatch"><FilesMatch></a> is
+ preferred, however.
+
+ <p>Note that unlike <a href=
+ "#directory"><code><Directory></code></a> and <a href=
+ "#location"><code><Location></code></a> sections,
+ <code><Files></code> sections can be used inside
+ .htaccess files. This allows users to control access to their
+ own files, at a file-by-file level.</p>
+
+ <p><strong>See also</strong>: <a href="../sections.html">How
+ Directory, Location and Files sections work</a> for an
+ explanation of how these different sections are combined when a
+ request is received</p>
+ <hr>
+
+ <h2><a name="filesmatch"><FilesMatch></a></h2>
+ <a href="directive-dict.html#Syntax" rel=
+ "Help"><strong>Syntax:</strong></a> <FilesMatch
+ <em>regex</em>> ... </FilesMatch><br>
+ <a href="directive-dict.html#Context" rel=
+ "Help"><strong>Context:</strong></a> server config, virtual
+ host, .htaccess<br>
+ <a href="directive-dict.html#Status" rel=
+ "Help"><strong>Status:</strong></a> core<br>
+ <a href="directive-dict.html#Compatibility" rel=
+ "Help"><strong>Compatibility:</strong></a> only available in
+ Apache 1.3 and above.
+
+ <p>The <FilesMatch> directive provides for access control
+ by filename, just as the <a href="#files"><Files></a>
+ directive does. However, it accepts a regular expression. For
+ example:</p>
+<pre>
+ <FilesMatch "\.(gif|jpe?g|png)$">
+</pre>
+
+ <p>would match most common Internet graphics formats.</p>
+ <strong>See also</strong>: <a href="../sections.html">How
+ Directory, Location and Files sections work</a> for an
+ explanation of how these different sections are combined when a
+ request is received
+ <hr>
+
+ <h2><a name="forcetype">ForceType</a> directive</h2>
+ <a href="directive-dict.html#Syntax" rel=
+ "Help"><strong>Syntax:</strong></a> ForceType
+ <em>mime-type</em><br>
+ <a href="directive-dict.html#Context" rel=
+ "Help"><strong>Context:</strong></a> directory, .htaccess<br>
+ <a href="directive-dict.html#Status" rel=
+ "Help"><strong>Status:</strong></a> Base<br>
+ <a href="directive-dict.html#Module" rel=
+ "Help"><strong>Module:</strong></a> core<br>
+ <a href="directive-dict.html#Compatibility" rel=
+ "Help"><strong>Compatibility:</strong></a> ForceType was
+ introduced in mod_mime with Apache 1.1, and moved to the core
+ in Apache 2.0.
+
+ <p>When placed into an <code>.htaccess</code> file or a
+ <code><Directory></code>, or
+ <code><Location></code> or or <code><Files></code>
+ section, this directive forces all matching files to be served
+ with the content type identification given by
+ <em>mime-type</em>. For example, if you had a directory full of
+ GIF files, but did not want to label them all with ".gif", you
+ might want to use:</p>
<pre>
ForceType image/gif
</pre>
-<P>Note that unlike <A HREF="#defaulttype">DefaultType</A>, this directive
-overrides all mime-type associations, including filename extensions, that
-might identify the media type.</P>
-
-<HR>
-
-<H2><A NAME="hostnamelookups">HostNameLookups directive</A></H2>
-<!--%plaintext <?INDEX {\tt HostNameLookups} directive> -->
-<A
- HREF="directive-dict.html#Syntax"
- REL="Help"
-><STRONG>Syntax:</STRONG></A> HostNameLookups on|off|double<BR>
-<A
- HREF="directive-dict.html#Default"
- REL="Help"
-><STRONG>Default:</STRONG></A> <CODE>HostNameLookups off</CODE><BR>
-<A
- HREF="directive-dict.html#Context"
- REL="Help"
-><STRONG>Context:</STRONG></A> server config, virtual host, directory<BR>
-<A
- HREF="directive-dict.html#Status"
- REL="Help"
-><STRONG>Status:</STRONG></A> core<BR>
-<A
- HREF="directive-dict.html#Compatibility"
- REL="Help"
-><STRONG>Compatibility:</STRONG></A> <CODE>double</CODE> available only in
-Apache
-1.3 and above.<BR>
-<A
- HREF="directive-dict.html#Compatibility"
- REL="Help"
-><STRONG>Compatibility:</STRONG></A> Default was <CODE>on</CODE> prior to
-Apache 1.3.<P>
-
-This directive enables DNS lookups so that host names can be logged (and
-passed to CGIs/SSIs in <CODE>REMOTE_HOST</CODE>).
-The value <CODE>double</CODE> refers to doing double-reverse DNS.
-That is, after a reverse lookup is performed, a forward lookup is then
-performed on that result. At least one of the ip addresses in the forward
-lookup must match the original address. (In "tcpwrappers" terminology
-this is called <CODE>PARANOID</CODE>.)<P>
-
-Regardless of the setting, when <A HREF="mod_access.html">mod_access</A>
-is used for controlling access by hostname, a double reverse lookup
-will be performed. This is necessary for security. Note that the
-result of this double-reverse isn't generally available unless
-you set <CODE>HostnameLookups double</CODE>. For example, if only
-<CODE>HostnameLookups on</CODE> and a request is made to an object that
-is protected by hostname restrictions, regardless of whether the
-double-reverse fails or not, CGIs will still be passed the single-reverse
-result in <CODE>REMOTE_HOST</CODE>.<P>
-
-The default for this directive was previously <CODE>on</CODE> in
-versions of Apache prior to 1.3. It was changed to <CODE>off</CODE>
-in order to save the network traffic for those sites that don't truly
-need the reverse lookups done. It is also better for the end users
-because they don't have to suffer the extra latency that a lookup
-entails. Heavily loaded sites should leave this directive
-<CODE>off</CODE>, since DNS lookups can take considerable amounts of
-time. The utility <a
-href="../programs/logresolve.html">logresolve</a>, provided in the
-<EM>/support</EM> directory, can be used to look up host names from
-logged IP addresses offline.<P><HR>
-
-<H2><A NAME="identitycheck">IdentityCheck directive</A></H2>
-<!--%plaintext <?INDEX {\tt IdentityCheck} directive> -->
-<A
- HREF="directive-dict.html#Syntax"
- REL="Help"
-><STRONG>Syntax:</STRONG></A> IdentityCheck on|off<BR>
-<A
- HREF="directive-dict.html#Default"
- REL="Help"
-><STRONG>Default:</STRONG></A> <CODE>IdentityCheck off</CODE><BR>
-<A
- HREF="directive-dict.html#Context"
- REL="Help"
-><STRONG>Context:</STRONG></A> server config, virtual host, directory<BR>
-<A
- HREF="directive-dict.html#Status"
- REL="Help"
-><STRONG>Status:</STRONG></A> core<P>
-
-This directive enables RFC1413-compliant logging of the remote user name
-for each connection, where the client machine runs identd or something similar.
-This information is logged in the access log. <EM>Boolean</EM> is either
-<CODE>on</CODE> or <CODE>off</CODE>.<P>
-
-The information should not be trusted in any way except for rudimentary usage
-tracking.<P>
-
-Note that this can cause serious latency problems accessing your server
-since every request requires one of these lookups to be performed. When
-firewalls are involved each lookup might possibly fail and add 30 seconds
-of latency to each hit. So in general this is not very useful on public
-servers accessible from the Internet.
-<P><HR>
-
-<H2><A NAME="ifdefine"><IfDefine> directive</A></H2>
-<A
- HREF="directive-dict.html#Syntax"
- REL="Help"
-><STRONG>Syntax:</STRONG></A> <IfDefine [!]<EM>parameter-name</EM>> <EM>...</EM>
-</IfDefine><BR>
-<A
- HREF="directive-dict.html#Default"
- REL="Help"
-><STRONG>Default:</STRONG></A> None<BR>
-<A
- HREF="directive-dict.html#Context"
- REL="Help"
-><STRONG>Context:</STRONG></A> all<BR>
-<A
- HREF="directive-dict.html#Status"
- REL="Help"
-><STRONG>Status:</STRONG></A> Core<BR>
-<A
- HREF="directive-dict.html#Compatibility"
- REL="Help"
-><STRONG>Compatibility:</STRONG></A> <IfDefine> is only available in
-1.3.1 and later.<P>
-
-<P>
-
-The <IfDefine <EM>test</EM>>...</IfDefine>
-section is used to mark directives that are conditional. The
-directives within an IfDefine section are only
-processed if the <EM>test</EM> is true. If <EM>test</EM>
-is false, everything between the start and end markers
-is ignored.<P>
-
-The <EM>test</EM> in the <IfDefine> section directive
-can be one of two forms:
-
-<UL>
-<LI><EM>parameter-name</EM>
-<LI><CODE>!</CODE><EM>parameter-name</EM>
-</UL>
-
-<P>In the former case, the directives between the start and end markers are
-only processed if the parameter named <EM>parameter-name</EM> is defined.
-The second format reverses the test, and only processes the directives if
-<EM>parameter-name</EM> is <STRONG>not</STRONG> defined.
-
-<P>The <EM>parameter-name</EM> argument is a define as given on the
-<CODE>httpd</CODE> command line via <CODE>-D</CODE><EM>parameter-</EM>, at the
-time the server was started.
-
-<P><IfDefine> sections are nest-able, which can be used to implement
-simple multiple-parameter tests.
-
-Example:
-
-<PRE>
+
+ <p>Note that unlike <a href="#defaulttype">DefaultType</a>,
+ this directive overrides all mime-type associations, including
+ filename extensions, that might identify the media type.</p>
+ <hr>
+
+ <h2><a name="hostnamelookups">HostNameLookups
+ directive</a></h2>
+ <!--%plaintext <?INDEX {\tt HostNameLookups} directive> -->
+ <a href="directive-dict.html#Syntax" rel=
+ "Help"><strong>Syntax:</strong></a> HostNameLookups
+ on|off|double<br>
+ <a href="directive-dict.html#Default" rel=
+ "Help"><strong>Default:</strong></a> <code>HostNameLookups
+ off</code><br>
+ <a href="directive-dict.html#Context" rel=
+ "Help"><strong>Context:</strong></a> server config, virtual
+ host, directory<br>
+ <a href="directive-dict.html#Status" rel=
+ "Help"><strong>Status:</strong></a> core<br>
+ <a href="directive-dict.html#Compatibility" rel=
+ "Help"><strong>Compatibility:</strong></a> <code>double</code>
+ available only in Apache 1.3 and above.<br>
+ <a href="directive-dict.html#Compatibility" rel=
+ "Help"><strong>Compatibility:</strong></a> Default was
+ <code>on</code> prior to Apache 1.3.
+
+ <p>This directive enables DNS lookups so that host names can be
+ logged (and passed to CGIs/SSIs in <code>REMOTE_HOST</code>).
+ The value <code>double</code> refers to doing double-reverse
+ DNS. That is, after a reverse lookup is performed, a forward
+ lookup is then performed on that result. At least one of the ip
+ addresses in the forward lookup must match the original
+ address. (In "tcpwrappers" terminology this is called
+ <code>PARANOID</code>.)</p>
+
+ <p>Regardless of the setting, when <a href=
+ "mod_access.html">mod_access</a> is used for controlling access
+ by hostname, a double reverse lookup will be performed. This is
+ necessary for security. Note that the result of this
+ double-reverse isn't generally available unless you set
+ <code>HostnameLookups double</code>. For example, if only
+ <code>HostnameLookups on</code> and a request is made to an
+ object that is protected by hostname restrictions, regardless
+ of whether the double-reverse fails or not, CGIs will still be
+ passed the single-reverse result in
+ <code>REMOTE_HOST</code>.</p>
+
+ <p>The default for this directive was previously
+ <code>on</code> in versions of Apache prior to 1.3. It was
+ changed to <code>off</code> in order to save the network
+ traffic for those sites that don't truly need the reverse
+ lookups done. It is also better for the end users because they
+ don't have to suffer the extra latency that a lookup entails.
+ Heavily loaded sites should leave this directive
+ <code>off</code>, since DNS lookups can take considerable
+ amounts of time. The utility <a href=
+ "../programs/logresolve.html">logresolve</a>, provided in the
+ <em>/support</em> directory, can be used to look up host names
+ from logged IP addresses offline.</p>
+ <hr>
+
+ <h2><a name="identitycheck">IdentityCheck directive</a></h2>
+ <!--%plaintext <?INDEX {\tt IdentityCheck} directive> -->
+ <a href="directive-dict.html#Syntax" rel=
+ "Help"><strong>Syntax:</strong></a> IdentityCheck on|off<br>
+ <a href="directive-dict.html#Default" rel=
+ "Help"><strong>Default:</strong></a> <code>IdentityCheck
+ off</code><br>
+ <a href="directive-dict.html#Context" rel=
+ "Help"><strong>Context:</strong></a> server config, virtual
+ host, directory<br>
+ <a href="directive-dict.html#Status" rel=
+ "Help"><strong>Status:</strong></a> core
+
+ <p>This directive enables RFC1413-compliant logging of the
+ remote user name for each connection, where the client machine
+ runs identd or something similar. This information is logged in
+ the access log. <em>Boolean</em> is either <code>on</code> or
+ <code>off</code>.</p>
+
+ <p>The information should not be trusted in any way except for
+ rudimentary usage tracking.</p>
+
+ <p>Note that this can cause serious latency problems accessing
+ your server since every request requires one of these lookups
+ to be performed. When firewalls are involved each lookup might
+ possibly fail and add 30 seconds of latency to each hit. So in
+ general this is not very useful on public servers accessible
+ from the Internet.</p>
+ <hr>
+
+ <h2><a name="ifdefine"><IfDefine> directive</a></h2>
+ <a href="directive-dict.html#Syntax" rel=
+ "Help"><strong>Syntax:</strong></a> <IfDefine
+ [!]<em>parameter-name</em>> <em>...</em>
+ </IfDefine><br>
+ <a href="directive-dict.html#Default" rel=
+ "Help"><strong>Default:</strong></a> None<br>
+ <a href="directive-dict.html#Context" rel=
+ "Help"><strong>Context:</strong></a> all<br>
+ <a href="directive-dict.html#Status" rel=
+ "Help"><strong>Status:</strong></a> Core<br>
+ <a href="directive-dict.html#Compatibility" rel=
+ "Help"><strong>Compatibility:</strong></a> <IfDefine> is
+ only available in 1.3.1 and later.
+
+ <p>The <IfDefine <em>test</em>>...</IfDefine>
+ section is used to mark directives that are conditional. The
+ directives within an IfDefine section are only processed if the
+ <em>test</em> is true. If <em>test</em> is false, everything
+ between the start and end markers is ignored.</p>
+
+ <p>The <em>test</em> in the <IfDefine> section directive
+ can be one of two forms:</p>
+
+ <ul>
+ <li><em>parameter-name</em></li>
+
+ <li><code>!</code><em>parameter-name</em></li>
+ </ul>
+
+ <p>In the former case, the directives between the start and end
+ markers are only processed if the parameter named
+ <em>parameter-name</em> is defined. The second format reverses
+ the test, and only processes the directives if
+ <em>parameter-name</em> is <strong>not</strong> defined.</p>
+
+ <p>The <em>parameter-name</em> argument is a define as given on
+ the <code>httpd</code> command line via
+ <code>-D</code><em>parameter-</em>, at the time the server was
+ started.</p>
+
+ <p><IfDefine> sections are nest-able, which can be used
+ to implement simple multiple-parameter tests. Example:</p>
+<pre>
$ httpd -DReverseProxy ...
# httpd.conf
LoadModule rewrite_module modules/mod_rewrite.so
LoadModule proxy_module modules/libproxy.so
</IfDefine>
-</PRE>
-
-<P> <HR>
-
-<H2><A NAME="ifmodule"><IfModule> directive</A></H2>
-<A
- HREF="directive-dict.html#Syntax"
- REL="Help"
-><STRONG>Syntax:</STRONG></A> <IfModule [!]<EM>module-name</EM>>
- <EM>...</EM>
-</IfModule><BR>
-<A
- HREF="directive-dict.html#Default"
- REL="Help"
-><STRONG>Default:</STRONG></A> None<BR>
-<A
- HREF="directive-dict.html#Context"
- REL="Help"
-><STRONG>Context:</STRONG></A> all<BR>
-<A
- HREF="directive-dict.html#Status"
- REL="Help"
-><STRONG>Status:</STRONG></A> Core<BR>
-<A
- HREF="directive-dict.html#Compatibility"
- REL="Help"
-><STRONG>Compatibility:</STRONG></A> IfModule is only available in 1.2 and
-later.<P>
-
-<P>
-
-The <IfModule <EM>test</EM>>...</IfModule>
-section is used to mark directives that are conditional. The
-directives within an IfModule section are only
-processed if the <EM>test</EM> is true. If <EM>test</EM>
-is false, everything between the start and end markers
-is ignored.<P>
-
-The <EM>test</EM> in the <IfModule> section directive
-can be one of two forms:
-
-<UL>
-<LI><EM>module name</EM>
-<LI>!<EM>module name</EM>
-</UL>
-
-<P>In the former case, the directives between the start and end markers
-are only processed if the module named <EM>module name</EM> is compiled
-in to Apache. The second format reverses the test, and only processes
-the directives if <EM>module name</EM> is <STRONG>not</STRONG> compiled in.
-
-<P>The <EM>module name</EM> argument is a module name as given as the file
-name of the module, at the time it was compiled. For example,
-<CODE>mod_rewrite.c</CODE>.
-
-<P><IfModule> sections are nest-able, which can be used to implement
-simple multiple-module tests.
-
-<P> <HR>
-
-<H2><A NAME="include">Include directive</A></H2>
-<STRONG>Syntax:</STRONG> Include <EM>file-path</EM>|<em>directory-path</em><BR>
-<A
- HREF="directive-dict.html#Context"
- REL="Help"
-><STRONG>Context:</STRONG></A> server config<BR>
-<A
- HREF="directive-dict.html#Status"
- REL="Help"
-><STRONG>Status:</STRONG></A> Core<BR>
-<A
- HREF="directive-dict.html#Compatibility"
- REL="Help"
-><STRONG>Compatibility:</STRONG></A> Include is only available in Apache 1.3
-and later.
-<P>
-This directive allows inclusion of other configuration files from within the
-server configuration files.
-
-<P>If <CODE>Include</CODE> points to a directory, rather than a file,
-Apache will read all files in that directory, and any subdirectory,
-and parse those as configuration files.
-
-<P> <HR>
-
-<H2><A NAME="keepalive">KeepAlive directive</A></H2>
-<STRONG>Syntax:</STRONG> KeepAlive on/off<BR>
-<STRONG>Default:</STRONG> <CODE>KeepAlive On</CODE><BR>
-<A
- HREF="directive-dict.html#Context"
- REL="Help"
-><STRONG>Context:</STRONG></A> server config<BR>
-<A
- HREF="directive-dict.html#Status"
- REL="Help"
-><STRONG>Status:</STRONG></A> Core<BR>
-<A
- HREF="directive-dict.html#Compatibility"
- REL="Help"
-><STRONG>Compatibility:</STRONG></A> KeepAlive is only available in Apache
-1.1 and later.<P>
-
-<p>The Keep-Alive extension to HTTP/1.0 and the persistent connection
-feature of HTTP/1.1 provide long-lived HTTP sessions which allow
-multiple requests to be sent over the same TCP connection. In some
-cases this has been shown to result in an almost 50% speedup in
-latency times for HTML documents with many images. To enable
-Keep-Alive connections in Apache 1.2 and later, set <code>KeepAlive
-On</code>.</p>
-
-<p>For HTTP/1.0 clients, Keep-Alive connections will only be used if
-they are specifically requested by a client. In addition, a
-Keep-Alive connection with an HTTP/1.0 client can only be used when
-the length of the content is known in advance. This implies that
-dynamic content such as CGI output, SSI pages, and server-generated
-directory listings will generally not use Keep-Alive connections to
-HTTP/1.0 clients. For HTTP/1.1 clients, persistent connections are
-the default unless otherwise specified. If the client requests it,
-chunked encoding will be used in order to send content of unknown
-length over persistent connections.</p>
-
-<p>See also <A
-HREF="#maxkeepaliverequests">MaxKeepAliveRequests</A>.</P>
-
-<HR>
-
-<H2><A NAME="keepalivetimeout">KeepAliveTimeout directive</A></H2>
-<A
- HREF="directive-dict.html#Syntax"
- REL="Help"
-><STRONG>Syntax:</STRONG></A> KeepAliveTimeout <EM>seconds</EM><BR>
-<A
- HREF="directive-dict.html#Default"
- REL="Help"
-><STRONG>Default:</STRONG></A> <CODE>KeepAliveTimeout 15</CODE><BR>
-<A
- HREF="directive-dict.html#Context"
- REL="Help"
-><STRONG>Context:</STRONG></A> server config<BR>
-<A
- HREF="directive-dict.html#Status"
- REL="Help"
-><STRONG>Status:</STRONG></A> Core<BR>
-<A
- HREF="directive-dict.html#Compatibility"
- REL="Help"
-><STRONG>Compatibility:</STRONG></A> KeepAliveTimeout is only available in
-Apache 1.1 and later.<P>
-
-<p>The number of seconds Apache will wait for a subsequent request
-before closing the connection. Once a request has been received, the
-timeout value specified by the <A
-HREF="#timeout"><CODE>Timeout</CODE></A> directive applies.</p>
-
-<p>Setting <code>KeepAliveTimeout</code> to a high value may
-cause performance problems in heavily loaded servers. The
-higher the timeout, the more server processes will be kept
-occupied waiting on connections with idle clients.</p>
-
-
-<HR>
-
-<H2><A NAME="limit"><Limit> directive</A></H2>
-<!--%plaintext <?INDEX {\tt Limit} section directive> -->
-<A
- HREF="directive-dict.html#Syntax"
- REL="Help"
-><STRONG>Syntax:</STRONG></A>
- <Limit <EM>method</em> [<em>method</EM>] ... > ... </Limit><BR>
-<A
- HREF="directive-dict.html#Context"
- REL="Help"
-><STRONG>Context:</STRONG></A> any<BR>
-<A
- HREF="directive-dict.html#Status"
- REL="Help"
-><STRONG>Status:</STRONG></A> core<P>
-
-Access controls are normally effective for <STRONG>all</STRONG> access
-methods, and this is the usual desired behaviour. <STRONG>In the
-general case, access control directives should not be placed within a
-<CODE><limit></CODE> section.</STRONG>
-
-<P>The purpose of the <Limit> directive is to restrict the effect
-of the access controls to the nominated HTTP methods. For all other
-methods, the access restrictions that are enclosed in the
-<Limit> bracket <STRONG>will have no effect</STRONG>. The
-following example applies the access control only to the methods POST,
-PUT, and DELETE, leaving all other methods unprotected:
-
-<BLOCKQUOTE><CODE>
-<Limit POST PUT DELETE><BR>
-Require valid-user<BR>
-</Limit></CODE></BLOCKQUOTE>
-
-The method names listed can be one or more of: GET, POST, PUT, DELETE,
-CONNECT, OPTIONS, TRACE, PATCH, PROPFIND, PROPPATCH, MKCOL, COPY,
-MOVE, LOCK, and UNLOCK. <STRONG>The method name is
-case-sensitive.</STRONG> If GET is used it will also restrict HEAD
-requests.
-
-<P><HR>
-
-<H2><A NAME="limitexcept"><LimitExcept> directive</A></H2>
-<!--%plaintext <?INDEX {\tt LimitExcept} section directive> -->
-<A
- HREF="directive-dict.html#Syntax"
- REL="Help"
-><STRONG>Syntax:</STRONG></A>
- <LimitExcept <EM>method</em> [<em>method</EM>] ... > ... </LimitExcept><BR>
-<A
- HREF="directive-dict.html#Context"
- REL="Help"
-><STRONG>Context:</STRONG></A> any<BR>
-<A
- HREF="directive-dict.html#Status"
- REL="Help"
-><STRONG>Status:</STRONG></A> core<BR>
-<A
- HREF="directive-dict.html#Compatibility"
- REL="Help"
-><STRONG>Compatibility:</STRONG></A> Available in Apache 1.3.5 and later<P>
-
-<LimitExcept> and </LimitExcept> are used to enclose a group of
-access control directives which will then apply to any HTTP access method
-<STRONG>not</STRONG> listed in the arguments; i.e., it is the opposite of a
-<A HREF="#limit"><Limit></A> section and can be used to control both
-standard and nonstandard/unrecognized methods. See the documentation for
-<A HREF="#limit"><Limit></A> for more details.
-
-<P><HR>
-
-<H2><A NAME="limitrequestbody">LimitRequestBody directive</A></H2>
-<!--%plaintext <?INDEX {\tt LimitRequestBody} directive> -->
-<A
- HREF="directive-dict.html#Syntax"
- REL="Help"
-><STRONG>Syntax:</STRONG></A> LimitRequestBody <EM>bytes</EM><BR>
-<A
- HREF="directive-dict.html#Default"
- REL="Help"
-><STRONG>Default:</STRONG></A> <CODE>LimitRequestBody 0</CODE><BR>
-<A
- HREF="directive-dict.html#Context"
- REL="Help"
-><STRONG>Context:</STRONG></A> server config, virtual host, directory,
-.htaccess<BR>
-<A
- HREF="directive-dict.html#Status"
- REL="Help"
-><STRONG>Status:</STRONG></A> core<BR>
-<A
- HREF="directive-dict.html#Compatibility"
- REL="Help"
-><STRONG>Compatibility:</STRONG></A> LimitRequestBody is only available in
-Apache 1.3.2 and later.
-<P>
-
-<p>This directive specifies the number of <em>bytes</em> from 0
-(meaning unlimited) to 2147483647 (2GB) that are allowed in a request
-body. The default value is defined by the compile-time constant
-<CODE>DEFAULT_LIMIT_REQUEST_BODY</CODE> (0 as distributed).
-<P>
-
-The LimitRequestBody directive allows the user to set a
-limit on the allowed size of an HTTP request message body within
-the context in which the directive is given (server, per-directory,
-per-file or per-location). If the client request exceeds that limit,
-the server will return an error response instead of servicing the request.
-The size of a normal request message body will vary greatly depending
-on the nature of the resource and the methods allowed on that resource.
-CGI scripts typically use the message body for passing form information
-to the server. Implementations of the PUT method will require a value
-at least as large as any representation that the server wishes
-to accept for that resource.
-<P>
-
-This directive gives the server administrator greater control over abnormal
-client request behavior, which may be useful for avoiding some forms
-of denial-of-service attacks.
-<P>
-
-<P><HR>
-
-<H2><A NAME="limitrequestfields">LimitRequestFields directive</A></H2>
-<!--%plaintext <?INDEX {\tt LimitRequestFields} directive> -->
-<A
- HREF="directive-dict.html#Syntax"
- REL="Help"
-><STRONG>Syntax:</STRONG></A> LimitRequestFields <EM>number</EM><BR>
-<A
- HREF="directive-dict.html#Default"
- REL="Help"
-><STRONG>Default:</STRONG></A> <CODE>LimitRequestFields 100</CODE><BR>
-<A
- HREF="directive-dict.html#Context"
- REL="Help"
-><STRONG>Context:</STRONG></A> server config<BR>
-<A
- HREF="directive-dict.html#Status"
- REL="Help"
-><STRONG>Status:</STRONG></A> core<BR>
-<A
- HREF="directive-dict.html#Compatibility"
- REL="Help"
-><STRONG>Compatibility:</STRONG></A> LimitRequestFields is only available in
-Apache 1.3.2 and later.
-<P>
-
-<p><em>Number</em> is an integer from 0 (meaning unlimited) to 32767.
-The default value is defined by the compile-time constant
-<CODE>DEFAULT_LIMIT_REQUEST_FIELDS</CODE> (100 as distributed).
-<P>
-
-The LimitRequestFields directive allows the server administrator to modify
-the limit on the number of request header fields allowed in an HTTP request.
-A server needs this value to be larger than the number of fields that a
-normal client request might include. The number of request header fields
-used by a client rarely exceeds 20, but this may vary among different
-client implementations, often depending upon the extent to which a user
-has configured their browser to support detailed content negotiation.
-Optional HTTP extensions are often expressed using request header fields.
-<P>
-
-This directive gives the server administrator greater control over abnormal
-client request behavior, which may be useful for avoiding some forms
-of denial-of-service attacks. The value should be increased if normal
-clients see an error response from the server that indicates too many
-fields were sent in the request.<P>
-
-<P><HR>
-
-<H2><A NAME="limitrequestfieldsize">LimitRequestFieldsize directive</A></H2>
-<!--%plaintext <?INDEX {\tt LimitRequestFieldsize} directive> -->
-<A
- HREF="directive-dict.html#Syntax"
- REL="Help"
-><STRONG>Syntax:</STRONG></A> LimitRequestFieldsize <EM>bytes</EM><BR>
-<A
- HREF="directive-dict.html#Default"
- REL="Help"
-><STRONG>Default:</STRONG></A> <CODE>LimitRequestFieldsize 8190</CODE><BR>
-<A
- HREF="directive-dict.html#Context"
- REL="Help"
-><STRONG>Context:</STRONG></A> server config<BR>
-<A
- HREF="directive-dict.html#Status"
- REL="Help"
-><STRONG>Status:</STRONG></A> core<BR>
-<A
- HREF="directive-dict.html#Compatibility"
- REL="Help"
-><STRONG>Compatibility:</STRONG></A> LimitRequestFieldsize is only available in
-Apache 1.3.2 and later.
-<P>
-
-This directive specifies the number of <em>bytes</em> from 0 to the
-value of the compile-time constant
-<CODE>DEFAULT_LIMIT_REQUEST_FIELDSIZE</CODE> (8190 as distributed)
-that will be allowed in an HTTP request header.
-<P>
-
-The LimitRequestFieldsize directive allows the server administrator to reduce
-the limit on the allowed size of an HTTP request header field below the
-normal input buffer size compiled with the server. A server needs this
-value to be large enough to hold any one header field from a normal client
-request. The size of a normal request header field will vary greatly
-among different client implementations, often depending upon the extent
-to which a user has configured their browser to support detailed
-content negotiation.
-<P>
-
-This directive gives the server administrator greater control over abnormal
-client request behavior, which may be useful for avoiding some forms
-of denial-of-service attacks. Under normal conditions, the value should
-not be changed from the default.<P>
-
-<P><HR>
-
-<H2><A NAME="limitrequestline">LimitRequestLine directive</A></H2>
-<!--%plaintext <?INDEX {\tt LimitRequestLine} directive> -->
-<A
- HREF="directive-dict.html#Syntax"
- REL="Help"
-><STRONG>Syntax:</STRONG></A> LimitRequestLine <EM>bytes</EM><BR>
-<A
- HREF="directive-dict.html#Default"
- REL="Help"
-><STRONG>Default:</STRONG></A> <CODE>LimitRequestLine 8190</CODE><BR>
-<A
- HREF="directive-dict.html#Context"
- REL="Help"
-><STRONG>Context:</STRONG></A> server config<BR>
-<A
- HREF="directive-dict.html#Status"
- REL="Help"
-><STRONG>Status:</STRONG></A> core<BR>
-<A
- HREF="directive-dict.html#Compatibility"
- REL="Help"
-><STRONG>Compatibility:</STRONG></A> LimitRequestLine is only available in
-Apache 1.3.2 and later.
-<P>
-
-This directive sets the number of <em>bytes</em> from 0 to the value
-of the compile-time constant <CODE>DEFAULT_LIMIT_REQUEST_LINE</CODE>
-(8190 as distributed) that will be allowed on the HTTP request-line.
-<P>
-
-The LimitRequestLine directive allows the server administrator to reduce
-the limit on the allowed size of a client's HTTP request-line below the
-normal input buffer size compiled with the server. Since the request-line
-consists of the HTTP method, URI, and protocol version, the
-LimitRequestLine directive places a restriction on the length of a
-request-URI allowed for a request on the server. A server needs this
-value to be large enough to hold any of its resource names, including
-any information that might be passed in the query part of a GET request.
-<P>
-
-This directive gives the server administrator greater control over abnormal
-client request behavior, which may be useful for avoiding some forms
-of denial-of-service attacks. Under normal conditions, the value should
-not be changed from the default.<P>
-
-<P><HR>
-
-
-<H2><A NAME="limitxmlrequestbody">LimitXMLRequestBody directive</A></H2>
-<A
- HREF="directive-dict.html#Syntax"
- REL="Help"
-><STRONG>Syntax:</STRONG></A> LimitXMLRequestBody <EM>number</EM><BR>
-<A
- HREF="directive-dict.html#Default"
- REL="Help"
-><STRONG>Default:</STRONG></A> <CODE>LimitXMLRequestBody 1000000</CODE><BR>
-<A
- HREF="directive-dict.html#Context"
- REL="Help"
-><STRONG>Context:</STRONG></A> server config<BR>
-<A
- HREF="directive-dict.html#Status"
- REL="Help"
-><STRONG>Status:</STRONG></A> core<BR>
-
-<P>Limit (in bytes) on maximum size of an XML-based request body.</p>
-
-<P><HR>
-
-<H2><A NAME="location"><Location> directive</A></H2>
-
-<A
- HREF="directive-dict.html#Syntax"
- REL="Help"
-><STRONG>Syntax:</STRONG></A> <Location <EM>URL-path</EM>|<em>URL</em>>
-... </Location><BR>
-<A
- HREF="directive-dict.html#Context"
- REL="Help"
-><STRONG>Context:</STRONG></A> server config, virtual host<BR>
-<A
- HREF="directive-dict.html#Status"
- REL="Help"
-><STRONG>Status:</STRONG></A> core<BR>
-<A
- HREF="directive-dict.html#Compatibility"
- REL="Help"
-><STRONG>Compatibility:</STRONG></A> Location is only available in Apache
-1.1 and later.<P>
-
-<P>The <Location> directive provides for access control by
-URL. It is similar to the <A
-HREF="#directory"><Directory></A> directive, and
-starts a subsection which is terminated with a </Location>
-directive. <CODE><Location></CODE> sections are processed in the
-order they appear in the configuration file, after the
-<Directory> sections and <CODE>.htaccess</CODE> files are
-read, and after the <Files> sections.</P>
-
-<P>Note that URLs do not have to line up with the filesystem at all,
-it should be emphasized that <Location> operates completely outside
-the filesystem.
-
-<P>For all origin (non-proxy) requests, the URL to be matched is
-of the form <CODE>/path/</CODE>, and you should not include any
-<CODE>http://servername</CODE> prefix. For proxy requests, the URL
-to be matched is of the form <CODE>scheme://servername/path</CODE>,
-and you must include the prefix.
-
-<P>The URL may use wildcards In a wild-card string, `?' matches any
-single character, and `*' matches any sequences of characters.
-
-<P><STRONG>Apache 1.2 and above:</STRONG>
-Extended regular expressions can also be used, with the addition of
-the <CODE>~</CODE> character.
-
-For example:</P>
-
-<PRE>
- <Location ~ "/(extra|special)/data">
-</PRE>
-
-<P>would match URLs that contained the substring "/extra/data" or
-"/special/data". In Apache 1.3 and above, a new directive
-<A HREF="#locationmatch"><LocationMatch></A> exists which
-behaves identical to the regex version of
-<CODE><Location></CODE>.
-
-<P>The <CODE>Location</CODE> functionality is especially useful when
-combined with the <CODE><A
-HREF="mod_mime.html#sethandler">SetHandler</A></CODE> directive. For example,
-to enable status requests, but allow them only
-from browsers at foo.com, you might use:
-
-<PRE>
+</pre>
+ <hr>
+
+ <h2><a name="ifmodule"><IfModule> directive</a></h2>
+ <a href="directive-dict.html#Syntax" rel=
+ "Help"><strong>Syntax:</strong></a> <IfModule
+ [!]<em>module-name</em>> <em>...</em> </IfModule><br>
+ <a href="directive-dict.html#Default" rel=
+ "Help"><strong>Default:</strong></a> None<br>
+ <a href="directive-dict.html#Context" rel=
+ "Help"><strong>Context:</strong></a> all<br>
+ <a href="directive-dict.html#Status" rel=
+ "Help"><strong>Status:</strong></a> Core<br>
+ <a href="directive-dict.html#Compatibility" rel=
+ "Help"><strong>Compatibility:</strong></a> IfModule is only
+ available in 1.2 and later.
+
+ <p>The <IfModule <em>test</em>>...</IfModule>
+ section is used to mark directives that are conditional. The
+ directives within an IfModule section are only processed if the
+ <em>test</em> is true. If <em>test</em> is false, everything
+ between the start and end markers is ignored.</p>
+
+ <p>The <em>test</em> in the <IfModule> section directive
+ can be one of two forms:</p>
+
+ <ul>
+ <li><em>module name</em></li>
+
+ <li>!<em>module name</em></li>
+ </ul>
+
+ <p>In the former case, the directives between the start and end
+ markers are only processed if the module named <em>module
+ name</em> is compiled in to Apache. The second format reverses
+ the test, and only processes the directives if <em>module
+ name</em> is <strong>not</strong> compiled in.</p>
+
+ <p>The <em>module name</em> argument is a module name as given
+ as the file name of the module, at the time it was compiled.
+ For example, <code>mod_rewrite.c</code>.</p>
+
+ <p><IfModule> sections are nest-able, which can be used
+ to implement simple multiple-module tests.</p>
+ <hr>
+
+ <h2><a name="include">Include directive</a></h2>
+ <strong>Syntax:</strong> Include
+ <em>file-path</em>|<em>directory-path</em><br>
+ <a href="directive-dict.html#Context" rel=
+ "Help"><strong>Context:</strong></a> server config<br>
+ <a href="directive-dict.html#Status" rel=
+ "Help"><strong>Status:</strong></a> Core<br>
+ <a href="directive-dict.html#Compatibility" rel=
+ "Help"><strong>Compatibility:</strong></a> Include is only
+ available in Apache 1.3 and later.
+
+ <p>This directive allows inclusion of other configuration files
+ from within the server configuration files.</p>
+
+ <p>If <code>Include</code> points to a directory, rather than a
+ file, Apache will read all files in that directory, and any
+ subdirectory, and parse those as configuration files.</p>
+ <hr>
+
+ <h2><a name="keepalive">KeepAlive directive</a></h2>
+ <strong>Syntax:</strong> KeepAlive on/off<br>
+ <strong>Default:</strong> <code>KeepAlive On</code><br>
+ <a href="directive-dict.html#Context" rel=
+ "Help"><strong>Context:</strong></a> server config<br>
+ <a href="directive-dict.html#Status" rel=
+ "Help"><strong>Status:</strong></a> Core<br>
+ <a href="directive-dict.html#Compatibility" rel=
+ "Help"><strong>Compatibility:</strong></a> KeepAlive is only
+ available in Apache 1.1 and later.
+
+ <p>The Keep-Alive extension to HTTP/1.0 and the persistent
+ connection feature of HTTP/1.1 provide long-lived HTTP sessions
+ which allow multiple requests to be sent over the same TCP
+ connection. In some cases this has been shown to result in an
+ almost 50% speedup in latency times for HTML documents with
+ many images. To enable Keep-Alive connections in Apache 1.2 and
+ later, set <code>KeepAlive On</code>.</p>
+
+ <p>For HTTP/1.0 clients, Keep-Alive connections will only be
+ used if they are specifically requested by a client. In
+ addition, a Keep-Alive connection with an HTTP/1.0 client can
+ only be used when the length of the content is known in
+ advance. This implies that dynamic content such as CGI output,
+ SSI pages, and server-generated directory listings will
+ generally not use Keep-Alive connections to HTTP/1.0 clients.
+ For HTTP/1.1 clients, persistent connections are the default
+ unless otherwise specified. If the client requests it, chunked
+ encoding will be used in order to send content of unknown
+ length over persistent connections.</p>
+
+ <p>See also <a href=
+ "#maxkeepaliverequests">MaxKeepAliveRequests</a>.</p>
+ <hr>
+
+ <h2><a name="keepalivetimeout">KeepAliveTimeout
+ directive</a></h2>
+ <a href="directive-dict.html#Syntax" rel=
+ "Help"><strong>Syntax:</strong></a> KeepAliveTimeout
+ <em>seconds</em><br>
+ <a href="directive-dict.html#Default" rel=
+ "Help"><strong>Default:</strong></a> <code>KeepAliveTimeout
+ 15</code><br>
+ <a href="directive-dict.html#Context" rel=
+ "Help"><strong>Context:</strong></a> server config<br>
+ <a href="directive-dict.html#Status" rel=
+ "Help"><strong>Status:</strong></a> Core<br>
+ <a href="directive-dict.html#Compatibility" rel=
+ "Help"><strong>Compatibility:</strong></a> KeepAliveTimeout is
+ only available in Apache 1.1 and later.
+
+ <p>The number of seconds Apache will wait for a subsequent
+ request before closing the connection. Once a request has been
+ received, the timeout value specified by the <a href=
+ "#timeout"><code>Timeout</code></a> directive applies.</p>
+
+ <p>Setting <code>KeepAliveTimeout</code> to a high value may
+ cause performance problems in heavily loaded servers. The
+ higher the timeout, the more server processes will be kept
+ occupied waiting on connections with idle clients.</p>
+ <hr>
+
+ <h2><a name="limit"><Limit> directive</a></h2>
+ <!--%plaintext <?INDEX {\tt Limit} section directive> -->
+ <a href="directive-dict.html#Syntax" rel=
+ "Help"><strong>Syntax:</strong></a> <Limit <em>method</em>
+ [<em>method</em>] ... > ... </Limit><br>
+ <a href="directive-dict.html#Context" rel=
+ "Help"><strong>Context:</strong></a> any<br>
+ <a href="directive-dict.html#Status" rel=
+ "Help"><strong>Status:</strong></a> core
+
+ <p>Access controls are normally effective for
+ <strong>all</strong> access methods, and this is the usual
+ desired behavior. <strong>In the general case, access control
+ directives should not be placed within a
+ <code><limit></code> section.</strong></p>
+
+ <p>The purpose of the <Limit> directive is to restrict
+ the effect of the access controls to the nominated HTTP
+ methods. For all other methods, the access restrictions that
+ are enclosed in the <Limit> bracket <strong>will have no
+ effect</strong>. The following example applies the access
+ control only to the methods POST, PUT, and DELETE, leaving all
+ other methods unprotected:</p>
+
+ <blockquote>
+ <code><Limit POST PUT DELETE><br>
+ Require valid-user<br>
+ </Limit></code>
+ </blockquote>
+ The method names listed can be one or more of: GET, POST, PUT,
+ DELETE, CONNECT, OPTIONS, TRACE, PATCH, PROPFIND, PROPPATCH,
+ MKCOL, COPY, MOVE, LOCK, and UNLOCK. <strong>The method name is
+ case-sensitive.</strong> If GET is used it will also restrict
+ HEAD requests.
+ <hr>
+
+ <h2><a name="limitexcept"><LimitExcept>
+ directive</a></h2>
+ <!--%plaintext <?INDEX {\tt LimitExcept} section directive> -->
+ <a href="directive-dict.html#Syntax" rel=
+ "Help"><strong>Syntax:</strong></a> <LimitExcept
+ <em>method</em> [<em>method</em>] ... > ...
+ </LimitExcept><br>
+ <a href="directive-dict.html#Context" rel=
+ "Help"><strong>Context:</strong></a> any<br>
+ <a href="directive-dict.html#Status" rel=
+ "Help"><strong>Status:</strong></a> core<br>
+ <a href="directive-dict.html#Compatibility" rel=
+ "Help"><strong>Compatibility:</strong></a> Available in Apache
+ 1.3.5 and later
+
+ <p><LimitExcept> and </LimitExcept> are used to
+ enclose a group of access control directives which will then
+ apply to any HTTP access method <strong>not</strong> listed in
+ the arguments; i.e., it is the opposite of a <a href=
+ "#limit"><Limit></a> section and can be used to control
+ both standard and nonstandard/unrecognized methods. See the
+ documentation for <a href="#limit"><Limit></a> for more
+ details.</p>
+ <hr>
+
+ <h2><a name="limitrequestbody">LimitRequestBody
+ directive</a></h2>
+ <!--%plaintext <?INDEX {\tt LimitRequestBody} directive> -->
+ <a href="directive-dict.html#Syntax" rel=
+ "Help"><strong>Syntax:</strong></a> LimitRequestBody
+ <em>bytes</em><br>
+ <a href="directive-dict.html#Default" rel=
+ "Help"><strong>Default:</strong></a> <code>LimitRequestBody
+ 0</code><br>
+ <a href="directive-dict.html#Context" rel=
+ "Help"><strong>Context:</strong></a> server config, virtual
+ host, directory, .htaccess<br>
+ <a href="directive-dict.html#Status" rel=
+ "Help"><strong>Status:</strong></a> core<br>
+ <a href="directive-dict.html#Compatibility" rel=
+ "Help"><strong>Compatibility:</strong></a> LimitRequestBody is
+ only available in Apache 1.3.2 and later.
+
+ <p>This directive specifies the number of <em>bytes</em> from 0
+ (meaning unlimited) to 2147483647 (2GB) that are allowed in a
+ request body. The default value is defined by the compile-time
+ constant <code>DEFAULT_LIMIT_REQUEST_BODY</code> (0 as
+ distributed).</p>
+
+ <p>The LimitRequestBody directive allows the user to set a
+ limit on the allowed size of an HTTP request message body
+ within the context in which the directive is given (server,
+ per-directory, per-file or per-location). If the client request
+ exceeds that limit, the server will return an error response
+ instead of servicing the request. The size of a normal request
+ message body will vary greatly depending on the nature of the
+ resource and the methods allowed on that resource. CGI scripts
+ typically use the message body for passing form information to
+ the server. Implementations of the PUT method will require a
+ value at least as large as any representation that the server
+ wishes to accept for that resource.</p>
+
+ <p>This directive gives the server administrator greater
+ control over abnormal client request behavior, which may be
+ useful for avoiding some forms of denial-of-service
+ attacks.</p>
+ <hr>
+
+ <h2><a name="limitrequestfields">LimitRequestFields
+ directive</a></h2>
+ <!--%plaintext <?INDEX {\tt LimitRequestFields} directive> -->
+ <a href="directive-dict.html#Syntax" rel=
+ "Help"><strong>Syntax:</strong></a> LimitRequestFields
+ <em>number</em><br>
+ <a href="directive-dict.html#Default" rel=
+ "Help"><strong>Default:</strong></a> <code>LimitRequestFields
+ 100</code><br>
+ <a href="directive-dict.html#Context" rel=
+ "Help"><strong>Context:</strong></a> server config<br>
+ <a href="directive-dict.html#Status" rel=
+ "Help"><strong>Status:</strong></a> core<br>
+ <a href="directive-dict.html#Compatibility" rel=
+ "Help"><strong>Compatibility:</strong></a> LimitRequestFields
+ is only available in Apache 1.3.2 and later.
+
+ <p><em>Number</em> is an integer from 0 (meaning unlimited) to
+ 32767. The default value is defined by the compile-time
+ constant <code>DEFAULT_LIMIT_REQUEST_FIELDS</code> (100 as
+ distributed).</p>
+
+ <p>The LimitRequestFields directive allows the server
+ administrator to modify the limit on the number of request
+ header fields allowed in an HTTP request. A server needs this
+ value to be larger than the number of fields that a normal
+ client request might include. The number of request header
+ fields used by a client rarely exceeds 20, but this may vary
+ among different client implementations, often depending upon
+ the extent to which a user has configured their browser to
+ support detailed content negotiation. Optional HTTP extensions
+ are often expressed using request header fields.</p>
+
+ <p>This directive gives the server administrator greater
+ control over abnormal client request behavior, which may be
+ useful for avoiding some forms of denial-of-service attacks.
+ The value should be increased if normal clients see an error
+ response from the server that indicates too many fields were
+ sent in the request.</p>
+ <hr>
+
+ <h2><a name="limitrequestfieldsize">LimitRequestFieldsize
+ directive</a></h2>
+ <!--%plaintext <?INDEX {\tt LimitRequestFieldsize} directive> -->
+ <a href="directive-dict.html#Syntax" rel=
+ "Help"><strong>Syntax:</strong></a> LimitRequestFieldsize
+ <em>bytes</em><br>
+ <a href="directive-dict.html#Default" rel=
+ "Help"><strong>Default:</strong></a>
+ <code>LimitRequestFieldsize 8190</code><br>
+ <a href="directive-dict.html#Context" rel=
+ "Help"><strong>Context:</strong></a> server config<br>
+ <a href="directive-dict.html#Status" rel=
+ "Help"><strong>Status:</strong></a> core<br>
+ <a href="directive-dict.html#Compatibility" rel=
+ "Help"><strong>Compatibility:</strong></a>
+ LimitRequestFieldsize is only available in Apache 1.3.2 and
+ later.
+
+ <p>This directive specifies the number of <em>bytes</em> from 0
+ to the value of the compile-time constant
+ <code>DEFAULT_LIMIT_REQUEST_FIELDSIZE</code> (8190 as
+ distributed) that will be allowed in an HTTP request
+ header.</p>
+
+ <p>The LimitRequestFieldsize directive allows the server
+ administrator to reduce the limit on the allowed size of an
+ HTTP request header field below the normal input buffer size
+ compiled with the server. A server needs this value to be large
+ enough to hold any one header field from a normal client
+ request. The size of a normal request header field will vary
+ greatly among different client implementations, often depending
+ upon the extent to which a user has configured their browser to
+ support detailed content negotiation.</p>
+
+ <p>This directive gives the server administrator greater
+ control over abnormal client request behavior, which may be
+ useful for avoiding some forms of denial-of-service attacks.
+ Under normal conditions, the value should not be changed from
+ the default.</p>
+ <hr>
+
+ <h2><a name="limitrequestline">LimitRequestLine
+ directive</a></h2>
+ <!--%plaintext <?INDEX {\tt LimitRequestLine} directive> -->
+ <a href="directive-dict.html#Syntax" rel=
+ "Help"><strong>Syntax:</strong></a> LimitRequestLine
+ <em>bytes</em><br>
+ <a href="directive-dict.html#Default" rel=
+ "Help"><strong>Default:</strong></a> <code>LimitRequestLine
+ 8190</code><br>
+ <a href="directive-dict.html#Context" rel=
+ "Help"><strong>Context:</strong></a> server config<br>
+ <a href="directive-dict.html#Status" rel=
+ "Help"><strong>Status:</strong></a> core<br>
+ <a href="directive-dict.html#Compatibility" rel=
+ "Help"><strong>Compatibility:</strong></a> LimitRequestLine is
+ only available in Apache 1.3.2 and later.
+
+ <p>This directive sets the number of <em>bytes</em> from 0 to
+ the value of the compile-time constant
+ <code>DEFAULT_LIMIT_REQUEST_LINE</code> (8190 as distributed)
+ that will be allowed on the HTTP request-line.</p>
+
+ <p>The LimitRequestLine directive allows the server
+ administrator to reduce the limit on the allowed size of a
+ client's HTTP request-line below the normal input buffer size
+ compiled with the server. Since the request-line consists of
+ the HTTP method, URI, and protocol version, the
+ LimitRequestLine directive places a restriction on the length
+ of a request-URI allowed for a request on the server. A server
+ needs this value to be large enough to hold any of its resource
+ names, including any information that might be passed in the
+ query part of a GET request.</p>
+
+ <p>This directive gives the server administrator greater
+ control over abnormal client request behavior, which may be
+ useful for avoiding some forms of denial-of-service attacks.
+ Under normal conditions, the value should not be changed from
+ the default.</p>
+ <hr>
+
+ <h2><a name="limitxmlrequestbody">LimitXMLRequestBody
+ directive</a></h2>
+ <a href="directive-dict.html#Syntax" rel=
+ "Help"><strong>Syntax:</strong></a> LimitXMLRequestBody
+ <em>number</em><br>
+ <a href="directive-dict.html#Default" rel=
+ "Help"><strong>Default:</strong></a> <code>LimitXMLRequestBody
+ 1000000</code><br>
+ <a href="directive-dict.html#Context" rel=
+ "Help"><strong>Context:</strong></a> server config<br>
+ <a href="directive-dict.html#Status" rel=
+ "Help"><strong>Status:</strong></a> core<br>
+
+
+ <p>Limit (in bytes) on maximum size of an XML-based request
+ body.</p>
+ <hr>
+
+ <h2><a name="location"><Location> directive</a></h2>
+ <a href="directive-dict.html#Syntax" rel=
+ "Help"><strong>Syntax:</strong></a> <Location
+ <em>URL-path</em>|<em>URL</em>> ... </Location><br>
+ <a href="directive-dict.html#Context" rel=
+ "Help"><strong>Context:</strong></a> server config, virtual
+ host<br>
+ <a href="directive-dict.html#Status" rel=
+ "Help"><strong>Status:</strong></a> core<br>
+ <a href="directive-dict.html#Compatibility" rel=
+ "Help"><strong>Compatibility:</strong></a> Location is only
+ available in Apache 1.1 and later.
+
+ <p>The <Location> directive provides for access control
+ by URL. It is similar to the <a href=
+ "#directory"><Directory></a> directive, and starts a
+ subsection which is terminated with a </Location>
+ directive. <code><Location></code> sections are processed
+ in the order they appear in the configuration file, after the
+ <Directory> sections and <code>.htaccess</code> files are
+ read, and after the <Files> sections.</p>
+
+ <p>Note that URLs do not have to line up with the filesystem at
+ all, it should be emphasized that <Location> operates
+ completely outside the filesystem.</p>
+
+ <p>For all origin (non-proxy) requests, the URL to be matched
+ is of the form <code>/path/</code>, and you should not include
+ any <code>http://servername</code> prefix. For proxy requests,
+ the URL to be matched is of the form
+ <code>scheme://servername/path</code>, and you must include the
+ prefix.</p>
+
+ <p>The URL may use wildcards In a wild-card string, `?' matches
+ any single character, and `*' matches any sequences of
+ characters.</p>
+
+ <p><strong>Apache 1.2 and above:</strong> Extended regular
+ expressions can also be used, with the addition of the
+ <code>~</code> character. For example:</p>
+<pre>
+ <Location ~ "/(extra|special)/data">
+</pre>
+
+ <p>would match URLs that contained the substring "/extra/data"
+ or "/special/data". In Apache 1.3 and above, a new directive <a
+ href="#locationmatch"><LocationMatch></a> exists which
+ behaves identical to the regex version of
+ <code><Location></code>.</p>
+
+ <p>The <code>Location</code> functionality is especially useful
+ when combined with the <code><a href=
+ "mod_mime.html#sethandler">SetHandler</a></code> directive. For
+ example, to enable status requests, but allow them only from
+ browsers at foo.com, you might use:</p>
+<pre>
<Location /status>
SetHandler server-status
Order Deny,Allow
Deny from all
Allow from .foo.com
</Location>
-</PRE>
-
-<P><STRONG>Apache 1.3 and above note about / (slash)</STRONG>: The slash
-character has special
-meaning depending on where in a URL it appears. People may be used
-to its behaviour in the filesystem where multiple adjacent slashes are
-frequently collapsed to a single slash (<EM>i.e.</EM>, <CODE>/home///foo</CODE>
-is the same as <CODE>/home/foo</CODE>). In URL-space this is not
-necessarily true. The <CODE><LocationMatch></CODE> directive
-and the regex version of <CODE><Location></CODE> require you
-to explicitly specify multiple slashes if that is your intention.
-For example, <CODE><LocationMatch ^/abc></CODE> would match the
-request URL <CODE>/abc</CODE> but not the request URL <CODE>//abc</CODE>.
-The (non-regex) <CODE><Location></CODE> directive behaves
-similarly when used for proxy requests. But when (non-regex)
-<CODE><Location></CODE> is used for non-proxy requests it will
-implicitly match multiple slashes with a single slash. For example,
-if you specify <CODE><Location /abc/def></CODE> and the request
-is to <CODE>/abc//def</CODE> then it will match.
-
-<P>
-<STRONG>See also</STRONG>: <A HREF="../sections.html">How Directory,
-Location and Files sections work</A> for an explanation of how these
-different sections are combined when a request is received
-
-<HR>
-
-<H2><A NAME="locationmatch"><LocationMatch></A></H2>
-
-<A
- HREF="directive-dict.html#Syntax"
- REL="Help"
-><STRONG>Syntax:</STRONG></A> <LocationMatch <EM>regex</EM>>
-... </LocationMatch><BR>
-<A
- HREF="directive-dict.html#Context"
- REL="Help"
-><STRONG>Context:</STRONG></A> server config, virtual host<BR>
-<A
- HREF="directive-dict.html#Status"
- REL="Help"
-><STRONG>Status:</STRONG></A> core<BR>
-<A
- HREF="directive-dict.html#Compatibility"
- REL="Help"
-><STRONG>Compatibility:</STRONG></A> LocationMatch is only available in
-Apache 1.3 and later.<P>
-
-<P>The <LocationMatch> directive provides for access control by
-URL, in an identical manner to <A
-HREF="#location"><Location></A>. However, it takes a regular
-expression as an argument instead of a simple string. For example:</P>
-
-<PRE>
- <LocationMatch "/(extra|special)/data">
-</PRE>
-
-<P>would match URLs that contained the substring "/extra/data" or
-"/special/data".</P>
-
-<STRONG>See also</STRONG>: <A HREF="../sections.html">How Directory,
-Location and Files sections work</A> for an explanation of how these
-different sections are combined when a request is received
-
-<HR>
-
-<H2><A NAME="loglevel">LogLevel directive</A></H2>
-<A
- HREF="directive-dict.html#Syntax"
- REL="Help"
-><STRONG>Syntax:</STRONG></A> LogLevel <EM>level</EM><BR>
-<A
- HREF="directive-dict.html#Default"
- REL="Help"
-><STRONG>Default:</STRONG></A> <CODE>LogLevel warn</CODE><BR>
-<A
- HREF="directive-dict.html#Context"
- REL="Help"
-><STRONG>Context:</STRONG></A> server config, virtual host<BR>
-<A
- HREF="directive-dict.html#Status"
- REL="Help"
-><STRONG>Status:</STRONG></A> core<BR>
-<A
- HREF="directive-dict.html#Compatibility"
- REL="Help"
-><STRONG>Compatibility:</STRONG></A> LogLevel is only available in 1.3 or
-later.
-
-<P>LogLevel adjusts the verbosity of the messages recorded in the
-error logs (see <A HREF="#errorlog">ErrorLog</A> directive).
-The following <EM>level</EM>s are available, in order of
-decreasing significance:
-
-<P><TABLE>
- <TR><TH ALIGN="LEFT"><STRONG>Level</STRONG>
- <TH ALIGN="LEFT"><STRONG>Description</STRONG>
- <TR><TH><TH ALIGN="LEFT"><STRONG>Example</STRONG>
- <TR><TD><CODE>emerg</CODE>
- <TD>Emergencies - system is unusable.
- <TR><TD><TD>"Child cannot open lock file. Exiting"
- <TR><TD><CODE>alert</CODE>
- <TD>Action must be taken immediately.
- <TR><TD><TD>"getpwuid: couldn't determine user name from uid"
- <TR><TD><CODE>crit</CODE>
- <TD>Critical Conditions.
- <TR><TD><TD>"socket: Failed to get a socket, exiting child"
- <TR><TD><CODE>error</CODE>
- <TD>Error conditions.
- <TR><TD><TD>"Premature end of script headers"
- <TR><TD><CODE>warn</CODE>
- <TD>Warning conditions.
- <TR><TD><TD>"child process 1234 did not exit, sending another SIGHUP"
- <TR><TD><CODE>notice</CODE>
- <TD>Normal but significant condition.
- <TR><TD><TD>"httpd: caught SIGBUS, attempting to dump core in ..."
- <TR><TD><CODE>info</CODE>
- <TD>Informational.
- <TR><TD><TD>"Server seems busy, (you may need to increase StartServers, or
- Min/MaxSpareServers)..."
- <TR><TD><CODE>debug</CODE>
- <TD>Debug-level messages
- <TR><TD><TD>"Opening config file ..."
-</TABLE>
-
-<P>When a particular level is specified, messages from all other levels
-of higher significance will be reported as well. <EM>E.g.</EM>, when
-<CODE>LogLevel info</CODE> is specified, then messages with log levels of
-<CODE>notice</CODE> and <CODE>warn</CODE> will also be posted.
-<P>
-Using a level of at least <CODE>crit</CODE> is recommended.
-<P><HR>
-
-<H2><A NAME="maxkeepaliverequests">MaxKeepAliveRequests directive</A></H2>
-<A
- HREF="directive-dict.html#Syntax"
- REL="Help"
-><STRONG>Syntax:</STRONG></A> MaxKeepAliveRequests <EM>number</EM><BR>
-<A
- HREF="directive-dict.html#Default"
- REL="Help"
-><STRONG>Default:</STRONG></A> <CODE>MaxKeepAliveRequests 100</CODE><BR>
-<A
- HREF="directive-dict.html#Context"
- REL="Help"
-><STRONG>Context:</STRONG></A> server config<BR>
-<A
- HREF="directive-dict.html#Status"
- REL="Help"
-><STRONG>Status:</STRONG></A> core<BR>
-<A
- HREF="directive-dict.html#Compatibility"
- REL="Help"
-><STRONG>Compatibility:</STRONG></A> Only available in Apache
-1.2 and later.
-
-<P>The MaxKeepAliveRequests directive limits the number of requests
-allowed per connection when <A HREF="#keepalive">KeepAlive</A> is
-on. If it is set to "<CODE>0</CODE>", unlimited requests will be
-allowed. We recommend that this setting be kept to a high value for
-maximum server performance.</P><HR>
-
-<H2><A NAME="namevirtualhost">NameVirtualHost directive</A></H2>
-<!--%plaintext <?INDEX {\tt NameVirtualHost} directive> -->
-<A
- HREF="directive-dict.html#Syntax"
- REL="Help"
-><STRONG>Syntax:</STRONG></A> NameVirtualHost <EM>addr</EM>[:<EM>port</EM>]<BR>
-<A
- HREF="directive-dict.html#Context"
- REL="Help"
-><STRONG>Context:</STRONG></A> server config<BR>
-<A
- HREF="directive-dict.html#Status"
- REL="Help"
-><STRONG>Status:</STRONG></A> core<BR>
-<A
- HREF="directive-dict.html#Compatibility"
- REL="Help"
-><STRONG>Compatibility:</STRONG></A> NameVirtualHost is only available in
-Apache 1.3 and later<P>
-
-The NameVirtualHost directive is a required directive if you want to configure
-<A HREF="../vhosts/">name-based virtual hosts</A>.<P>
-
-Although <EM>addr</EM> can be hostname it is recommended that you always use
-an IP address, <EM>e.g.</EM>
-
-<BLOCKQUOTE><CODE>NameVirtualHost 111.22.33.44</CODE></BLOCKQUOTE>
-
-With the NameVirtualHost directive you specify the IP address on which
-the server will receive requests for the name-based virtual hosts.
-This will usually be the address to which your name-based virtual host
-names resolve. In cases where a firewall or other proxy receives the
-requests and forwards them on a different IP address to the server,
-you must specify the IP address of the physical interface on the
-machine which will be servicing the requests. If you have multiple
-name-based hosts on multiple addresses, repeat the directive for each
-address.<P>
-
-Note: the "main server" and any _default_ servers will <STRONG>never</STRONG>
-be served for a request to a NameVirtualHost IP Address (unless for some
-reason you specify NameVirtualHost but then don't define any VirtualHosts
-for that address).<P>
-
-Optionally you can specify a port number on which the name-based
-virtual hosts should be used, <EM>e.g.</EM>
-
-<BLOCKQUOTE><CODE>NameVirtualHost 111.22.33.44:8080</CODE></BLOCKQUOTE>
-
-<STRONG>See also:</STRONG>
-<A HREF="../vhosts/">Apache Virtual Host documentation</A>
-<HR>
-
-<H2><A NAME="options">Options directive</A></H2>
-<!--%plaintext <?INDEX {\tt Options} directive> -->
-<A
- HREF="directive-dict.html#Syntax"
- REL="Help"
-><STRONG>Syntax:</STRONG></A> Options [+|-]<em>option</em> [[+|-]<em>option</em>] ...</EM><BR>
-<A
- HREF="directive-dict.html#Context"
- REL="Help"
-><STRONG>Context:</STRONG></A> server config, virtual host, directory,
-.htaccess<BR>
-<A
- HREF="directive-dict.html#Override"
- REL="Help"
-><STRONG>Override:</STRONG></A> Options<BR>
-<A
- HREF="directive-dict.html#Status"
- REL="Help"
-><STRONG>Status:</STRONG></A> core<P>
-
-The Options directive controls which server features are available in
-a particular directory.
-<P>
-<EM>option</EM> can be set to <CODE>None</CODE>, in which case none of
-the extra features are enabled, or one or more of the following:
-<DL>
-<DT>All
-<DD>All options except for MultiViews. This is the default setting.
-<DT>ExecCGI
-<DD>
-<!--%plaintext <?INDEX {\tt ExecCGI} option> -->
-Execution of CGI scripts is permitted.
-<DT>FollowSymLinks
-<DD>
-<!--%plaintext <?INDEX {\tt FollowSymLinks} option> -->
-The server will follow symbolic links in this directory.
-<BR>
-<STRONG>Note</STRONG>: even though the server follows the symlink it
-does <EM>not</EM>
-change the pathname used to match against <CODE><Directory></CODE>
-sections.
-<BR>
-<STRONG>Note</STRONG>: this option gets ignored if set inside a
-<Location> section.
-
-<DT>Includes
-<DD>
-<!--%plaintext <?INDEX {\tt Includes} option> -->
-Server-side includes are permitted.
-<DT>IncludesNOEXEC
-<DD>
-<!--%plaintext <?INDEX {\tt IncludesNOEXEC} option> -->
-Server-side includes are permitted, but the #exec command and
-#exec CGI are disabled. It is still possible to #include virtual
-CGI scripts from ScriptAliase'd directories.
-<DT>Indexes
-<DD>
-<!--%plaintext <?INDEX {\tt Indexes} option> -->
-If a URL which maps to a directory is requested, and the there is no
-DirectoryIndex (<EM>e.g.</EM>, index.html) in that directory, then the server will
-return a formatted listing of the directory.
-<DT>MultiViews
-<DD>
-<!--%plaintext <?INDEX {\tt MultiViews} option> -->
-<A HREF="../content-negotiation.html">Content negotiated</A> MultiViews are
-allowed.
-<DT>SymLinksIfOwnerMatch
-<DD>
-<!--%plaintext <?INDEX {\tt SymLinksIfOwnerMatch} option> -->
-The server will only follow symbolic links for which the target
-file or directory is owned by the same user id as the link.
-<BR>
-<STRONG>Note</STRONG>: this option gets ignored if set inside a
-<Location> section.
-</DL>
-
-Normally, if multiple <CODE>Options</CODE> could apply to a directory,
-then the most specific one is taken complete; the options are not
-merged. However if <EM>all</EM> the options on the <CODE>Options</CODE>
-directive are preceded by a + or - symbol, the options are
-merged. Any options preceded by a + are added to the options
-currently in force, and any options preceded by a - are removed from
-the options currently in force. <P>
-
-For example, without any + and - symbols:
-
-<BLOCKQUOTE><CODE>
-<Directory /web/docs> <BR>
-Options Indexes FollowSymLinks<BR>
-</Directory><BR>
-<Directory /web/docs/spec> <BR>
-Options Includes<BR>
-</Directory>
-</CODE></BLOCKQUOTE>
-then only <CODE>Includes</CODE> will be set for the /web/docs/spec
-directory. However if the second <CODE>Options</CODE> directive uses the +
-and - symbols:<P>
-
-<BLOCKQUOTE><CODE>
-<Directory /web/docs> <BR>
-Options Indexes FollowSymLinks<BR>
-</Directory><BR>
-<Directory /web/docs/spec> <BR>
-Options +Includes -Indexes<BR>
-</Directory>
-</CODE></BLOCKQUOTE>
-then the options <CODE>FollowSymLinks</CODE> and <CODE>Includes</CODE>
-are set for the /web/docs/spec directory.<P>
-
-<STRONG>Note:</STRONG> Using <CODE>-IncludesNOEXEC</CODE> or
-<CODE>-Includes</CODE>
-disables server-side includes completely regardless of the previous setting.<P>
-
-The default in the absence of any other settings is <CODE>All</CODE>.<P>
-<HR>
-
-
-
-<H2><A NAME="port">Port directive</A></H2>
-<!--%plaintext <?INDEX {\tt Port} directive> -->
-<A
- HREF="directive-dict.html#Syntax"
- REL="Help"
-><STRONG>Syntax:</STRONG></A> Port <EM>number</EM><BR>
-<A
- HREF="directive-dict.html#Default"
- REL="Help"
-><STRONG>Default:</STRONG></A> <CODE>Port 80</CODE><BR>
-<A
- HREF="directive-dict.html#Context"
- REL="Help"
-><STRONG>Context:</STRONG></A> server config<BR>
-<A
- HREF="directive-dict.html#Status"
- REL="Help"
-><STRONG>Status:</STRONG></A> core<P>
-
-<EM>Number</EM> is a number from 0 to 65535; some port numbers
-(especially below
-1024) are reserved for particular protocols. See <CODE>/etc/services</CODE>
-for a list of some defined ports; the standard port for the http protocol
-is 80.<P>
-
-The Port directive has two behaviors, the first of which is necessary for
-NCSA backwards compatibility (and which is confusing in the context of
-Apache).<P>
-
-<UL>
-<LI>
-In the absence of any <A HREF="mpm_common.html#listen">Listen</A>
-directives specifying a port number,
-a Port directive given in the "main server"
-(<EM>i.e.</EM>, outside any <A HREF="#virtualhost"><VirtualHost></A> section)
-sets the network port on which the server listens.
-If there are any Listen directives specifying
-<CODE>:number</CODE> then Port has no effect on what address the server
-listens at.
-
-<LI>The Port directive
-sets the <CODE>SERVER_PORT</CODE> environment variable (for
-<A HREF="mod_cgi.html">CGI</A> and <A HREF="mod_include.html">SSI</A>),
-and is used when the server must generate a URL that refers to itself
-(for example when creating an external redirect to itself). This
-behaviour is modified by
-<A HREF="#usecanonicalname">UseCanonicalName</A>.
-</UL>
-
-The primary behaviour of Port should be considered to be similar to that of
-the <A HREF="#servername">ServerName</A> directive. The ServerName
-and Port together specify what you consider to be the <EM>canonical</EM>
-address of the server.
-(See also <A HREF="#usecanonicalname">UseCanonicalName</A>.)<P>
-
-Port 80 is one of Unix's special ports. All ports numbered below 1024
-are reserved for system use, <EM>i.e.</EM>, regular (non-root) users
-cannot make use of them; instead they can only use higher port
-numbers. To use port 80, you must start the server from the root
-account. After binding to the port and before accepting requests,
-Apache will change to a low privileged user as set by the <A
-HREF="mpm_common.html#user">User directive</A>.<P>
-
-If you cannot use port 80, choose any other unused port. Non-root users
-will have to choose a port number higher than 1023, such as 8000.<P>
-
-SECURITY: if you do start the server as root, be sure not to set <A
-HREF="mpm_common.html#user">User</A> to root. If you run the server as
-root whilst handling connections, your site may be open to a major
-security attack.<P><HR>
-
-<H2><A NAME="require">Require directive</A></H2>
-<!--%plaintext <?INDEX {\tt Require} directive> -->
-<A
- HREF="directive-dict.html#Syntax"
- REL="Help"
-><STRONG>Syntax:</STRONG></A> Require <EM>entity-name</em> [<em>entity-name</em>] ...</EM><BR>
-<A
- HREF="directive-dict.html#Context"
- REL="Help"
-><STRONG>Context:</STRONG></A> directory, .htaccess<BR>
-<A
- HREF="directive-dict.html#Override"
- REL="Help"
-><STRONG>Override:</STRONG></A> AuthConfig<BR>
-<A
- HREF="directive-dict.html#Status"
- REL="Help"
-><STRONG>Status:</STRONG></A> core<P>
-
-This directive selects which authenticated users can access a directory.
-The allowed syntaxes are:
-<UL>
-<LI>Require user <EM>userid</em> [<em>userid</em>] ...<P>
-Only the named users can access the directory.<P>
-<LI>Require group <EM>group-name</em> [<em>group-name</em>] ...<P>
-Only users in the named groups can access the directory.<P>
-<LI>Require valid-user<P>
-All valid users can access the directory.
-</UL>
-<P>
-Require must be accompanied by <A HREF="#authname">AuthName</A> and
-<A HREF="#authtype">AuthType</A> directives, and directives such as
-<A HREF="mod_auth.html#authuserfile">AuthUserFile</A> and
-<A HREF="mod_auth.html#authgroupfile">AuthGroupFile</A> (to define users and
-groups) in order to work correctly. Example:
-<BLOCKQUOTE><CODE>
-AuthType Basic<BR>
-AuthName "Restricted Directory"<BR>
-AuthUserFile /web/users<BR>
-AuthGroupFile /web/groups<BR>
-Require group admin<BR>
-</CODE></BLOCKQUOTE>
-
-Access controls which are applied in this way are effective for
-<STRONG>all</STRONG> methods. <STRONG>This is what is normally
-desired.</STRONG> If you wish to apply access controls only to
-specific methods, while leaving other methods unprotected, then place
-the <CODE>Require</CODE> statement into a <A
-HREF="#limit"><Limit></A> section<P>
-<P>See also <A HREF="#satisfy">Satisfy</A> and <A HREF="mod_access.html">mod_access</A>.
-<HR>
-
-<H2><A NAME="rlimit">RLimitCPU</A> <A NAME="rlimitcpu">directive</A></H2>
-<!--%plaintext <?INDEX {\tt RLimitCPU} directive> -->
-<A
- HREF="directive-dict.html#Syntax"
- REL="Help"
-><STRONG>Syntax:</STRONG></A> RLimitCPU <EM>number</EM>|max
- [<em>number</em>|max]
-<BR>
-<A
- HREF="directive-dict.html#Default"
- REL="Help"
-><STRONG>Default:</STRONG></A> <EM>Unset; uses operating system defaults</EM>
-<BR>
-<A
- HREF="directive-dict.html#Context"
- REL="Help"
-><STRONG>Context:</STRONG></A> server config, virtual host<BR>
-<A
- HREF="directive-dict.html#Status"
- REL="Help"
-><STRONG>Status:</STRONG></A> core<BR>
-<A
- HREF="directive-dict.html#Compatibility"
- REL="Help"
-><STRONG>Compatibility:</STRONG></A> RLimitCPU is only available in Apache 1.2
-and later. Moved in version 2.0 to the <A HREF="../mpm.html">MPMs</A>.<P>
-
-Takes 1 or 2 parameters. The first parameter sets the soft resource limit
-for all processes and the second parameter sets the maximum resource limit.
-Either parameter can be a number, or <EM>max</EM> to indicate to the server
-that the limit should be set to the maximum allowed by the operating system
-configuration. Raising the maximum resource limit requires that the server
-is running as root, or in the initial startup phase.<P>
-
-This applies to processes forked off from Apache children servicing requests,
-not the Apache children themselves. This includes CGI scripts and SSI
-exec commands, but not any processes forked off from the Apache parent
-such as piped logs.<P>
-
-CPU resource limits are expressed in seconds per process.<P>
-
-See also <A HREF="#rlimitmem">RLimitMEM</A> or
-<A HREF="#rlimitnproc">RLimitNPROC</A>.<P><HR>
-
-<H2><A NAME="rlimitmem">RLimitMEM directive</A></H2>
-<!--%plaintext <?INDEX {\tt RLimitMEM} directive> -->
-<A
- HREF="directive-dict.html#Syntax"
- REL="Help"
-><STRONG>Syntax:</STRONG></A> RLimitMEM <em>number</em>|max
- [<em>number</em>|max]<br>
-<A
- HREF="directive-dict.html#Default"
- REL="Help"
-><STRONG>Default:</STRONG></A> <EM>Unset; uses operating system defaults</EM>
-<BR>
-<A
- HREF="directive-dict.html#Context"
- REL="Help"
-><STRONG>Context:</STRONG></A> server config, virtual host<BR>
-<A
- HREF="directive-dict.html#Status"
- REL="Help"
-><STRONG>Status:</STRONG></A> core<BR>
-<A
- HREF="directive-dict.html#Compatibility"
- REL="Help"
-><STRONG>Compatibility:</STRONG></A> RLimitMEM is only available in Apache 1.2
-and later. Moved in version 2.0 to the <A HREF="../mpm.html">MPMs</A>.<P>
-
-Takes 1 or 2 parameters. The first parameter sets the soft resource limit for
-all processes and the second parameter sets the maximum resource limit. Either
-parameter can be a number, or <EM>max</EM> to indicate to the server that the
-limit should be set to the maximum allowed by the operating system
-configuration. Raising the maximum resource limit requires that the
-server is running as root, or in the initial startup phase.<P>
-
-This applies to processes forked off from Apache children servicing requests,
-not the Apache children themselves. This includes CGI scripts and SSI
-exec commands, but not any processes forked off from the Apache parent
-such as piped logs.<P>
-
-Memory resource limits are expressed in bytes per process.<P>
-
-See also <A HREF="#rlimitcpu">RLimitCPU</A> or
-<A HREF="#rlimitnproc">RLimitNPROC</A>.<P><HR>
-
-<H2><A NAME="rlimitnproc">RLimitNPROC directive</A></H2>
-<!--%plaintext <?INDEX {\tt RLimitNPROC} directive> -->
-<A
- HREF="directive-dict.html#Syntax"
- REL="Help"
-><STRONG>Syntax:</STRONG></A> RLimitNPROC <em>number</em>|max
- [<em>number</em>|max]<BR>
-<A
- HREF="directive-dict.html#Default"
- REL="Help"
-><STRONG>Default:</STRONG></A> <EM>Unset; uses operating system defaults</EM>
-<BR>
-<A
- HREF="directive-dict.html#Context"
- REL="Help"
-><STRONG>Context:</STRONG></A> server config, virtual host<BR>
-<A
- HREF="directive-dict.html#Status"
- REL="Help"
-><STRONG>Status:</STRONG></A> core<BR>
-<A
- HREF="directive-dict.html#Compatibility"
- REL="Help"
-><STRONG>Compatibility:</STRONG></A> RLimitNPROC is only available in Apache
-1.2 and later. Moved in version 2.0 to the <A HREF="../mpm.html">MPMs</A>.<P>
-
-Takes 1 or 2 parameters. The first parameter sets the soft resource limit
-for all processes and the second parameter sets the maximum resource limit.
-Either parameter can be a number, or <code>max</code> to indicate to the server
-that the limit should be set to the maximum allowed by the operating system
-configuration. Raising the maximum resource limit requires that the server
-is running as root, or in the initial startup phase.<P>
-
-This applies to processes forked off from Apache children servicing requests,
-not the Apache children themselves. This includes CGI scripts and SSI
-exec commands, but not any processes forked off from the Apache parent
-such as piped logs.<P>
-
-Process limits control the number of processes per user.<P>
-
-Note: If CGI processes are <STRONG>not</STRONG> running under userids other
-than the
-web server userid, this directive will limit the number of processes that the
-server itself can create. Evidence of this situation will be indicated by
-<STRONG><EM>cannot fork</EM></STRONG> messages in the error_log.<P>
-
-See also <A HREF="#rlimitmem">RLimitMEM</A> or
-<A HREF="#rlimitcpu">RLimitCPU</A>.
-
-<P><HR>
-
-<H2><A NAME="satisfy">Satisfy directive</A></H2>
-<!--%plaintext <?INDEX {\tt Satisfy} directive> -->
-<A
- HREF="directive-dict.html#Syntax"
- REL="Help"
-><STRONG>Syntax:</STRONG></A> Satisfy any|all<BR>
-<A
- HREF="directive-dict.html#Default"
- REL="Help"
-><STRONG>Default:</STRONG></A> Satisfy all<BR>
-<A
- HREF="directive-dict.html#Context"
- REL="Help"
-><STRONG>Context:</STRONG></A> directory, .htaccess<BR>
-<A
- HREF="directive-dict.html#Status"
- REL="Help"
-><STRONG>Status:</STRONG></A> core<BR>
-<A
- HREF="directive-dict.html#Compatibility"
- REL="Help"
-><STRONG>Compatibility:</STRONG></A> Satisfy is only available in Apache 1.2
-and later<P>
-
-Access policy if both <CODE>Allow</CODE> and <CODE>Require</CODE>
-used. The parameter can be
-either <EM>'all'</EM> or <EM>'any'</EM>. This directive is only useful
-if access to a particular area is being restricted by both
-username/password <EM>and</EM> client host address. In this case the
-default behavior ("all") is to require that the client passes the
-address access restriction <EM>and</EM> enters a valid username and
-password. With the "any" option the client will be granted access if
-they either pass the host restriction or enter a valid username and
-password. This can be used to password restrict an area, but to let
-clients from particular addresses in without prompting for a password.
-<P>
-See also <A HREF="#require">Require</A> and
-<A HREF="mod_access.html">mod_access</A>.
-
-<P><HR>
-
-<H2><A NAME="scriptinterpretersource">ScriptInterpreterSource directive</A></H2>
-<!--%plaintext <?INDEX {\tt ScriptInterpreterSource} directive> -->
-<A
- HREF="directive-dict.html#Syntax"
- REL="Help"
-><STRONG>Syntax:</STRONG></A> ScriptInterpreterSource registry|script<BR>
-<A
- HREF="directive-dict.html#Default"
- REL="Help"
-><STRONG>Default:</STRONG></A> <CODE>ScriptInterpreterSource script</CODE>
-<BR>
-<A
- HREF="directive-dict.html#Context"
- REL="Help"
-><STRONG>Context:</STRONG></A> directory, .htaccess<BR>
-<A
- HREF="directive-dict.html#Status"
- REL="Help"
-><STRONG>Status:</STRONG></A> core (Windows only)<P>
-
-This directive is used to control how Apache 1.3.5 and later finds the interpreter
-used to run CGI scripts. The default technique is to use the interpreter pointed to by
-the #! line in the script. Setting ScriptInterpreterSource registry will cause the
-Windows Registry to be searched using the script file extension (e.g., .pl) as a search key.
-<P><HR>
-
-<H2><A NAME="serveradmin">ServerAdmin directive</A></H2>
-<!--%plaintext <?INDEX {\tt ServerAdmin} directive> -->
-<A
- HREF="directive-dict.html#Syntax"
- REL="Help"
-><STRONG>Syntax:</STRONG></A> ServerAdmin <EM>email-address</EM><BR>
-<A
- HREF="directive-dict.html#Context"
- REL="Help"
-><STRONG>Context:</STRONG></A> server config, virtual host<BR>
-<A
- HREF="directive-dict.html#Status"
- REL="Help"
-><STRONG>Status:</STRONG></A> core<P>
-
-The ServerAdmin sets the e-mail address that the server includes in any
-error messages it returns to the client.<P>
-
-It may be worth setting up a dedicated address for this, <EM>e.g.</EM>
-<BLOCKQUOTE><CODE>ServerAdmin www-admin@foo.bar.com</CODE></BLOCKQUOTE>
-as users do not always mention that they are talking about the server!<P><HR>
-
-<H2><A NAME="serveralias">ServerAlias directive</A></H2>
-
-<A
- HREF="directive-dict.html#Syntax"
- REL="Help"
-><STRONG>Syntax:</STRONG></A> ServerAlias <EM>hostname</em> [<em>hostname</em>] ...<BR>
-<A
- HREF="directive-dict.html#Context"
- REL="Help"
-><STRONG>Context:</STRONG></A> virtual host<BR>
-<A
- HREF="directive-dict.html#Status"
- REL="Help"
-><STRONG>Status:</STRONG></A> core<BR>
-<A
- HREF="directive-dict.html#Compatibility"
- REL="Help"
-><STRONG>Compatibility:</STRONG></A> ServerAlias is only available in Apache
-1.1 and later.<P>
-
-The ServerAlias directive sets the alternate names for a host, for use
-with
-<A HREF="../vhosts/name-based.html">name-based virtual hosts</A>.
-
-<P><STRONG>See also:</STRONG>
-<A HREF="../vhosts/">Apache Virtual Host documentation</A>
-
-<HR>
-
-<H2><A NAME="servername">ServerName directive</A></H2>
-<!--%plaintext <?INDEX {\tt ServerName} directive> -->
-<A
- HREF="directive-dict.html#Syntax"
- REL="Help"
-><STRONG>Syntax:</STRONG></A> ServerName <EM>fully-qualified-domain-name</EM>
-<BR>
-<A
- HREF="directive-dict.html#Context"
- REL="Help"
-><STRONG>Context:</STRONG></A> server config, virtual host<BR>
-<A
- HREF="directive-dict.html#Status"
- REL="Help"
-><STRONG>Status:</STRONG></A> core<P>
-
-The ServerName directive sets the hostname of the server; this is
-used when creating redirection URLs. If it is not specified, then the
-server attempts to deduce it from its own IP address; however this may
-not work reliably, or may not return the preferred hostname. For example:
-<BLOCKQUOTE><CODE>ServerName www.example.com</CODE></BLOCKQUOTE>
-would be used if the canonical (main) name of the actual machine
-were <CODE>simple.example.com</CODE>.<P>
-
-If you are using <A HREF="../vhosts/name-based.html">name-based
-virtual hosts</A>, the <CODE>ServerName</CODE> inside a
-<A HREF="#virtualhost"><CODE><VirtualHost></CODE></A>
-section specifies what hostname must appear in the request's
-<CODE>Host:</CODE> header to match this virtual host.<P>
-
-<P><STRONG>See Also</STRONG>:<BR>
-<A HREF="../dns-caveats.html">DNS Issues</A><BR>
-<A HREF="../vhosts/">Apache virtual host documentation</A><BR>
-<A HREF="#usecanonicalname">UseCanonicalName</A><BR>
-<A HREF="#namevirtualhost">NameVirtualHost</A><BR>
-<A HREF="#serveralias">ServerAlias</A><BR>
-</P>
-<HR>
-
-<H2><A NAME="serverpath">ServerPath directive</A></H2>
-
-<A
- HREF="directive-dict.html#Syntax"
- REL="Help"
-><STRONG>Syntax:</STRONG></A> ServerPath <EM>directory-path</EM><BR>
-<A
- HREF="directive-dict.html#Context"
- REL="Help"
-><STRONG>Context:</STRONG></A> virtual host<BR>
-<A
- HREF="directive-dict.html#Status"
- REL="Help"
-><STRONG>Status:</STRONG></A> core<BR>
-<A
- HREF="directive-dict.html#Compatibility"
- REL="Help"
-><STRONG>Compatibility:</STRONG></A> ServerPath is only available in Apache
-1.1 and later.<P>
-
-The ServerPath directive sets the legacy URL pathname for a host, for
-use with <A HREF="../vhosts/">name-based virtual hosts</A>.
-
-<P><STRONG>See also:</STRONG>
-<A HREF="../vhosts/">Apache Virtual Host documentation</A>
-
-<HR>
-
-<H2><A NAME="serverroot">ServerRoot directive</A></H2>
-<!--%plaintext <?INDEX {\tt ServerRoot} directive> -->
-<A
- HREF="directive-dict.html#Syntax"
- REL="Help"
-><STRONG>Syntax:</STRONG></A> ServerRoot <EM>directory-path</EM><BR>
-<A
- HREF="directive-dict.html#Default"
- REL="Help"
-><STRONG>Default:</STRONG></A> <CODE>ServerRoot /usr/local/apache</CODE><BR>
-<A
- HREF="directive-dict.html#Context"
- REL="Help"
-><STRONG>Context:</STRONG></A> server config<BR>
-<A
- HREF="directive-dict.html#Status"
- REL="Help"
-><STRONG>Status:</STRONG></A> core<P>
-
-The ServerRoot directive sets the directory in which the server lives.
-Typically it will contain the subdirectories <CODE>conf/</CODE> and
-<CODE>logs/</CODE>. Relative paths for other configuration files are taken
-as relative to this directory.<P>
-
-See also <A HREF="../invoking.html">the <CODE>-d</CODE> option to httpd</A>.<P>
-See also <A HREF="../misc/security_tips.html#serverroot">the security tips</A>
-for information on how to properly set permissions on the ServerRoot.<P>
-
-<HR>
-
-<H2><A NAME="serversignature">ServerSignature directive</A></H2>
-<!--%plaintext <?INDEX {\tt ServerSignature} directive> -->
-<A
- HREF="directive-dict.html#Syntax"
- REL="Help"
-><STRONG>Syntax:</STRONG></A> ServerSignature On|Off|EMail<BR>
-<A
- HREF="directive-dict.html#Default"
- REL="Help"
-><STRONG>Default:</STRONG></A> <CODE>ServerSignature Off</CODE><BR>
-<A
- HREF="directive-dict.html#Context"
- REL="Help"
-><STRONG>Context:</STRONG></A> server config, virtual host, directory,
-.htaccess<BR>
-<A
- HREF="directive-dict.html#Status"
- REL="Help"
-><STRONG>Status:</STRONG></A> core<BR>
-<A
- HREF="directive-dict.html#Compatibility"
- REL="Help"
-><STRONG>Compatibility:</STRONG></A> ServerSignature is only available in
-Apache
-1.3 and later.<P>
-
-The ServerSignature directive allows the configuration of a trailing
-footer line under server-generated documents (error messages,
-mod_proxy ftp directory listings, mod_info output, ...). The reason
-why you would want to enable such a footer line is that in a chain
-of proxies, the user often has no possibility to tell which of the
-chained servers actually produced a returned error message.<BR>
-The <SAMP>Off</SAMP> setting, which is the default, suppresses the
-error line (and is therefore compatible with the behavior of
-Apache-1.2 and below). The <SAMP>On</SAMP> setting simply adds a
-line with the server version number and <A
-HREF="#servername">ServerName</A> of the serving virtual host, and
-the <SAMP>EMail</SAMP> setting additionally creates a "mailto:"
-reference to the <A HREF="#serveradmin">ServerAdmin</A> of the
-referenced document.
-
-<HR>
-
-<H2><A NAME="servertokens">ServerTokens directive</A></H2>
-<!--%plaintext <?INDEX {\tt ServerTokens} directive> -->
-<A
- HREF="directive-dict.html#Syntax"
- REL="Help"
-><STRONG>Syntax:</STRONG></A> ServerTokens Minimal|ProductOnly|OS|Full<BR>
-<A
- HREF="directive-dict.html#Default"
- REL="Help"
-><STRONG>Default:</STRONG></A> <CODE>ServerTokens Full</CODE><BR>
-<A
- HREF="directive-dict.html#Context"
- REL="Help"
-><STRONG>Context:</STRONG></A> server config <BR>
-<A
- HREF="directive-dict.html#Status"
- REL="Help"
-><STRONG>Status:</STRONG></A> core<BR>
-<A
- HREF="directive-dict.html#Compatibility"
- REL="Help"
-><STRONG>Compatibility:</STRONG></A> ServerTokens is only available
- in Apache 1.3 and later; the <code>ProductOnly</code> keyword is
- only available in versions later than 1.3.12
-
-<P>
-This directive controls whether <SAMP>Server</SAMP> response header
-field which is sent back to clients includes a description of the generic
-OS-type of the server as well as information about compiled-in modules.
-</P>
-<DL>
- <DT><CODE>ServerTokens Prod[uctOnly]</CODE>
- </DT>
- <DD>Server sends (<EM>e.g.</EM>): <SAMP>Server: Apache</SAMP>
- </DD>
- <DT><CODE>ServerTokens Min[imal]</CODE>
- </DT>
- <DD>Server sends (<EM>e.g.</EM>): <SAMP>Server: Apache/1.3.0</SAMP>
- </DD>
- <DT><CODE>ServerTokens OS</CODE>
- </DT>
- <DD>Server sends (<EM>e.g.</EM>): <SAMP>Server: Apache/1.3.0 (Unix)</SAMP>
- </DD>
- <DT><CODE>ServerTokens Full</CODE> (or not specified)
- </DT>
- <DD>Server sends (<EM>e.g.</EM>): <SAMP>Server: Apache/1.3.0 (Unix) PHP/3.0
- MyMod/1.2</SAMP>
- </DD>
-</DL>
-<P>
-This setting applies to the entire server, and cannot be enabled or
-disabled on a virtualhost-by-virtualhost basis.
-</P>
-
-<HR>
-
-<h2><a name="sethandler">SetHandler</a> directive</h2>
-
-<a
- href="directive-dict.html#Syntax"
- rel="Help"
-><strong>Syntax:</strong></a> SetHandler <em>handler-name</em><br>
-<a
- href="directive-dict.html#Context"
- rel="Help"
-><strong>Context:</strong></a> directory, files, location, .htaccess<br>
-<a
- href="directive-dict.html#Status"
- rel="Help"
-><strong>Status:</strong></a> Base<br>
-<a
- href="directive-dict.html#Module"
- rel="Help"
-><strong>Module:</strong></a> core<br>
-<a
- href="directive-dict.html#Compatibility"
- rel="Help"
-><strong>Compatibility:</strong></a> SetHandler was introduced in mod_mime
-with Apache 1.1, and moved into the core with Apache 2.0<P>
-
-<P>When placed into an <code>.htaccess</code> file or a
-<code><Directory></code> or <code><Location></code> section,
-this directive forces all matching files to be parsed through the
-<a href="../handler.html">handler</a>
-given by <em>handler-name</em>. For example, if you had a
-directory you wanted to be parsed entirely as imagemap rule files,
-regardless of extension, you might put the following into an
-<code>.htaccess</code> file in that directory:
+</pre>
+
+ <p><strong>Apache 1.3 and above note about / (slash)</strong>:
+ The slash character has special meaning depending on where in a
+ URL it appears. People may be used to its behavior in the
+ filesystem where multiple adjacent slashes are frequently
+ collapsed to a single slash (<em>i.e.</em>,
+ <code>/home///foo</code> is the same as
+ <code>/home/foo</code>). In URL-space this is not necessarily
+ true. The <code><LocationMatch></code> directive and the
+ regex version of <code><Location></code> require you to
+ explicitly specify multiple slashes if that is your intention.
+ For example, <code><LocationMatch ^/abc></code> would
+ match the request URL <code>/abc</code> but not the request URL
+ <code>//abc</code>. The (non-regex)
+ <code><Location></code> directive behaves similarly when
+ used for proxy requests. But when (non-regex)
+ <code><Location></code> is used for non-proxy requests it
+ will implicitly match multiple slashes with a single slash. For
+ example, if you specify <code><Location /abc/def></code>
+ and the request is to <code>/abc//def</code> then it will
+ match.</p>
+
+ <p><strong>See also</strong>: <a href="../sections.html">How
+ Directory, Location and Files sections work</a> for an
+ explanation of how these different sections are combined when a
+ request is received</p>
+ <hr>
+
+ <h2><a name="locationmatch"><LocationMatch></a></h2>
+ <a href="directive-dict.html#Syntax" rel=
+ "Help"><strong>Syntax:</strong></a> <LocationMatch
+ <em>regex</em>> ... </LocationMatch><br>
+ <a href="directive-dict.html#Context" rel=
+ "Help"><strong>Context:</strong></a> server config, virtual
+ host<br>
+ <a href="directive-dict.html#Status" rel=
+ "Help"><strong>Status:</strong></a> core<br>
+ <a href="directive-dict.html#Compatibility" rel=
+ "Help"><strong>Compatibility:</strong></a> LocationMatch is
+ only available in Apache 1.3 and later.
+
+ <p>The <LocationMatch> directive provides for access
+ control by URL, in an identical manner to <a href=
+ "#location"><Location></a>. However, it takes a regular
+ expression as an argument instead of a simple string. For
+ example:</p>
+<pre>
+ <LocationMatch "/(extra|special)/data">
+</pre>
+
+ <p>would match URLs that contained the substring "/extra/data"
+ or "/special/data".</p>
+ <strong>See also</strong>: <a href="../sections.html">How
+ Directory, Location and Files sections work</a> for an
+ explanation of how these different sections are combined when a
+ request is received
+ <hr>
+
+ <h2><a name="loglevel">LogLevel directive</a></h2>
+ <a href="directive-dict.html#Syntax" rel=
+ "Help"><strong>Syntax:</strong></a> LogLevel <em>level</em><br>
+ <a href="directive-dict.html#Default" rel=
+ "Help"><strong>Default:</strong></a> <code>LogLevel
+ warn</code><br>
+ <a href="directive-dict.html#Context" rel=
+ "Help"><strong>Context:</strong></a> server config, virtual
+ host<br>
+ <a href="directive-dict.html#Status" rel=
+ "Help"><strong>Status:</strong></a> core<br>
+ <a href="directive-dict.html#Compatibility" rel=
+ "Help"><strong>Compatibility:</strong></a> LogLevel is only
+ available in 1.3 or later.
+
+ <p>LogLevel adjusts the verbosity of the messages recorded in
+ the error logs (see <a href="#errorlog">ErrorLog</a>
+ directive). The following <em>level</em>s are available, in
+ order of decreasing significance:</p>
+
+ <table>
+ <tr>
+ <th align="LEFT"><strong>Level</strong> </th>
+
+ <th align="LEFT"><strong>Description</strong> </th>
+ </tr>
+
+ <tr>
+ <th>
+ </th>
+
+ <th align="LEFT"><strong>Example</strong> </th>
+ </tr>
+
+ <tr>
+ <td><code>emerg</code> </td>
+
+ <td>Emergencies - system is unusable.</td>
+ </tr>
+
+ <tr>
+ <td>
+ </td>
+
+ <td>"Child cannot open lock file. Exiting"</td>
+ </tr>
+
+ <tr>
+ <td><code>alert</code> </td>
+
+ <td>Action must be taken immediately.</td>
+ </tr>
+
+ <tr>
+ <td>
+ </td>
+
+ <td>"getpwuid: couldn't determine user name from uid"</td>
+ </tr>
+
+ <tr>
+ <td><code>crit</code> </td>
+
+ <td>Critical Conditions.</td>
+ </tr>
+
+ <tr>
+ <td>
+ </td>
+
+ <td>"socket: Failed to get a socket, exiting child"</td>
+ </tr>
+
+ <tr>
+ <td><code>error</code> </td>
+
+ <td>Error conditions.</td>
+ </tr>
+
+ <tr>
+ <td>
+ </td>
+
+ <td>"Premature end of script headers"</td>
+ </tr>
+
+ <tr>
+ <td><code>warn</code> </td>
+
+ <td>Warning conditions.</td>
+ </tr>
+
+ <tr>
+ <td>
+ </td>
+
+ <td>"child process 1234 did not exit, sending another
+ SIGHUP"</td>
+ </tr>
+
+ <tr>
+ <td><code>notice</code> </td>
+
+ <td>Normal but significant condition.</td>
+ </tr>
+
+ <tr>
+ <td>
+ </td>
+
+ <td>"httpd: caught SIGBUS, attempting to dump core in
+ ..."</td>
+ </tr>
+
+ <tr>
+ <td><code>info</code> </td>
+
+ <td>Informational.</td>
+ </tr>
+
+ <tr>
+ <td>
+ </td>
+
+ <td>"Server seems busy, (you may need to increase
+ StartServers, or Min/MaxSpareServers)..."</td>
+ </tr>
+
+ <tr>
+ <td><code>debug</code> </td>
+
+ <td>Debug-level messages</td>
+ </tr>
+
+ <tr>
+ <td>
+ </td>
+
+ <td>"Opening config file ..."</td>
+ </tr>
+ </table>
+
+ <p>When a particular level is specified, messages from all
+ other levels of higher significance will be reported as well.
+ <em>E.g.</em>, when <code>LogLevel info</code> is specified,
+ then messages with log levels of <code>notice</code> and
+ <code>warn</code> will also be posted.</p>
+
+ <p>Using a level of at least <code>crit</code> is
+ recommended.</p>
+ <hr>
+
+ <h2><a name="maxkeepaliverequests">MaxKeepAliveRequests
+ directive</a></h2>
+ <a href="directive-dict.html#Syntax" rel=
+ "Help"><strong>Syntax:</strong></a> MaxKeepAliveRequests
+ <em>number</em><br>
+ <a href="directive-dict.html#Default" rel=
+ "Help"><strong>Default:</strong></a> <code>MaxKeepAliveRequests
+ 100</code><br>
+ <a href="directive-dict.html#Context" rel=
+ "Help"><strong>Context:</strong></a> server config<br>
+ <a href="directive-dict.html#Status" rel=
+ "Help"><strong>Status:</strong></a> core<br>
+ <a href="directive-dict.html#Compatibility" rel=
+ "Help"><strong>Compatibility:</strong></a> Only available in
+ Apache 1.2 and later.
+
+ <p>The MaxKeepAliveRequests directive limits the number of
+ requests allowed per connection when <a href=
+ "#keepalive">KeepAlive</a> is on. If it is set to
+ "<code>0</code>", unlimited requests will be allowed. We
+ recommend that this setting be kept to a high value for maximum
+ server performance.</p>
+ <hr>
+
+ <h2><a name="namevirtualhost">NameVirtualHost
+ directive</a></h2>
+ <!--%plaintext <?INDEX {\tt NameVirtualHost} directive> -->
+ <a href="directive-dict.html#Syntax" rel=
+ "Help"><strong>Syntax:</strong></a> NameVirtualHost
+ <em>addr</em>[:<em>port</em>]<br>
+ <a href="directive-dict.html#Context" rel=
+ "Help"><strong>Context:</strong></a> server config<br>
+ <a href="directive-dict.html#Status" rel=
+ "Help"><strong>Status:</strong></a> core<br>
+ <a href="directive-dict.html#Compatibility" rel=
+ "Help"><strong>Compatibility:</strong></a> NameVirtualHost is
+ only available in Apache 1.3 and later
+
+ <p>The NameVirtualHost directive is a required directive if you
+ want to configure <a href="../vhosts/">name-based virtual
+ hosts</a>.</p>
+
+ <p>Although <em>addr</em> can be hostname it is recommended
+ that you always use an IP address, <em>e.g.</em></p>
+
+ <blockquote>
+ <code>NameVirtualHost 111.22.33.44</code>
+ </blockquote>
+ With the NameVirtualHost directive you specify the IP address
+ on which the server will receive requests for the name-based
+ virtual hosts. This will usually be the address to which your
+ name-based virtual host names resolve. In cases where a
+ firewall or other proxy receives the requests and forwards them
+ on a different IP address to the server, you must specify the
+ IP address of the physical interface on the machine which will
+ be servicing the requests. If you have multiple name-based
+ hosts on multiple addresses, repeat the directive for each
+ address.
+
+ <p>Note: the "main server" and any _default_ servers will
+ <strong>never</strong> be served for a request to a
+ NameVirtualHost IP Address (unless for some reason you specify
+ NameVirtualHost but then don't define any VirtualHosts for that
+ address).</p>
+
+ <p>Optionally you can specify a port number on which the
+ name-based virtual hosts should be used, <em>e.g.</em></p>
+
+ <blockquote>
+ <code>NameVirtualHost 111.22.33.44:8080</code>
+ </blockquote>
+ <strong>See also:</strong> <a href="../vhosts/">Apache Virtual
+ Host documentation</a>
+ <hr>
+
+ <h2><a name="options">Options directive</a></h2>
+ <!--%plaintext <?INDEX {\tt Options} directive> -->
+ <a href="directive-dict.html#Syntax" rel=
+ "Help"><strong>Syntax:</strong></a> Options
+ [+|-]<em>option</em> [[+|-]<em>option</em>] ...<br>
+ <a href="directive-dict.html#Context" rel=
+ "Help"><strong>Context:</strong></a> server config, virtual
+ host, directory, .htaccess<br>
+ <a href="directive-dict.html#Override" rel=
+ "Help"><strong>Override:</strong></a> Options<br>
+ <a href="directive-dict.html#Status" rel=
+ "Help"><strong>Status:</strong></a> core
+
+ <p>The Options directive controls which server features are
+ available in a particular directory.</p>
+
+ <p><em>option</em> can be set to <code>None</code>, in which
+ case none of the extra features are enabled, or one or more of
+ the following:</p>
+
+ <dl>
+ <dt>All</dt>
+
+ <dd>All options except for MultiViews. This is the default
+ setting.</dd>
+
+ <dt>ExecCGI</dt>
+
+ <dd><!--%plaintext <?INDEX {\tt ExecCGI} option> -->
+ Execution of CGI scripts is permitted.</dd>
+
+ <dt>FollowSymLinks</dt>
+
+ <dd>
+ <!--%plaintext <?INDEX {\tt FollowSymLinks} option> -->
+ The server will follow symbolic links in this directory.<br>
+ <strong>Note</strong>: even though the server follows the
+ symlink it does <em>not</em> change the pathname used to
+ match against <code><Directory></code> sections.<br>
+ <strong>Note</strong>: this option gets ignored if set
+ inside a <Location> section.</dd>
+
+ <dt>Includes</dt>
+
+ <dd><!--%plaintext <?INDEX {\tt Includes} option> -->
+ Server-side includes are permitted.</dd>
+
+ <dt>IncludesNOEXEC</dt>
+
+ <dd>
+ <!--%plaintext <?INDEX {\tt IncludesNOEXEC} option> -->
+ Server-side includes are permitted, but the #exec command and
+ #exec CGI are disabled. It is still possible to #include
+ virtual CGI scripts from ScriptAliase'd directories.</dd>
+
+ <dt>Indexes</dt>
+
+ <dd><!--%plaintext <?INDEX {\tt Indexes} option> -->
+ If a URL which maps to a directory is requested, and the
+ there is no DirectoryIndex (<em>e.g.</em>, index.html) in
+ that directory, then the server will return a formatted
+ listing of the directory.</dd>
+
+ <dt>MultiViews</dt>
+
+ <dd><!--%plaintext <?INDEX {\tt MultiViews} option> -->
+ <a href="../content-negotiation.html">Content negotiated</a>
+ MultiViews are allowed.</dd>
+
+ <dt>SymLinksIfOwnerMatch</dt>
+
+ <dd>
+ <!--%plaintext <?INDEX {\tt SymLinksIfOwnerMatch} option> -->
+ The server will only follow symbolic links for which the
+ target file or directory is owned by the same user id as the
+ link.<br>
+ <strong>Note</strong>: this option gets ignored if set
+ inside a <Location> section.</dd>
+ </dl>
+ Normally, if multiple <code>Options</code> could apply to a
+ directory, then the most specific one is taken complete; the
+ options are not merged. However if <em>all</em> the options on
+ the <code>Options</code> directive are preceded by a + or -
+ symbol, the options are merged. Any options preceded by a + are
+ added to the options currently in force, and any options
+ preceded by a - are removed from the options currently in
+ force.
+
+ <p>For example, without any + and - symbols:</p>
+
+ <blockquote>
+ <code><Directory /web/docs><br>
+ Options Indexes FollowSymLinks<br>
+ </Directory><br>
+ <Directory /web/docs/spec><br>
+ Options Includes<br>
+ </Directory></code>
+ </blockquote>
+ then only <code>Includes</code> will be set for the
+ /web/docs/spec directory. However if the second
+ <code>Options</code> directive uses the + and - symbols:
+
+ <blockquote>
+ <code><Directory /web/docs><br>
+ Options Indexes FollowSymLinks<br>
+ </Directory><br>
+ <Directory /web/docs/spec><br>
+ Options +Includes -Indexes<br>
+ </Directory></code>
+ </blockquote>
+ then the options <code>FollowSymLinks</code> and
+ <code>Includes</code> are set for the /web/docs/spec directory.
+
+
+ <p><strong>Note:</strong> Using <code>-IncludesNOEXEC</code> or
+ <code>-Includes</code> disables server-side includes completely
+ regardless of the previous setting.</p>
+
+ <p>The default in the absence of any other settings is
+ <code>All</code>.</p>
+ <hr>
+
+ <h2><a name="port">Port directive</a></h2>
+ <!--%plaintext <?INDEX {\tt Port} directive> -->
+ <a href="directive-dict.html#Syntax" rel=
+ "Help"><strong>Syntax:</strong></a> Port <em>number</em><br>
+ <a href="directive-dict.html#Default" rel=
+ "Help"><strong>Default:</strong></a> <code>Port 80</code><br>
+ <a href="directive-dict.html#Context" rel=
+ "Help"><strong>Context:</strong></a> server config<br>
+ <a href="directive-dict.html#Status" rel=
+ "Help"><strong>Status:</strong></a> core
+
+ <p><em>Number</em> is a number from 0 to 65535; some port
+ numbers (especially below 1024) are reserved for particular
+ protocols. See <code>/etc/services</code> for a list of some
+ defined ports; the standard port for the http protocol is
+ 80.</p>
+
+ <p>The Port directive has two behaviors, the first of which is
+ necessary for NCSA backwards compatibility (and which is
+ confusing in the context of Apache).</p>
+
+ <ul>
+ <li>In the absence of any <a href=
+ "mpm_common.html#listen">Listen</a> directives specifying a
+ port number, a Port directive given in the "main server"
+ (<em>i.e.</em>, outside any <a href=
+ "#virtualhost"><VirtualHost></a> section) sets the
+ network port on which the server listens. If there are any
+ Listen directives specifying <code>:number</code> then Port
+ has no effect on what address the server listens at.</li>
+
+ <li>The Port directive sets the <code>SERVER_PORT</code>
+ environment variable (for <a href="mod_cgi.html">CGI</a> and
+ <a href="mod_include.html">SSI</a>), and is used when the
+ server must generate a URL that refers to itself (for example
+ when creating an external redirect to itself). This behaviour
+ is modified by <a href=
+ "#usecanonicalname">UseCanonicalName</a>.</li>
+ </ul>
+ The primary behavior of Port should be considered to be
+ similar to that of the <a href="#servername">ServerName</a>
+ directive. The ServerName and Port together specify what you
+ consider to be the <em>canonical</em> address of the server.
+ (See also <a href="#usecanonicalname">UseCanonicalName</a>.)
+
+ <p>Port 80 is one of Unix's special ports. All ports numbered
+ below 1024 are reserved for system use, <em>i.e.</em>, regular
+ (non-root) users cannot make use of them; instead they can only
+ use higher port numbers. To use port 80, you must start the
+ server from the root account. After binding to the port and
+ before accepting requests, Apache will change to a low
+ privileged user as set by the <a href=
+ "mpm_common.html#user">User directive</a>.</p>
+
+ <p>If you cannot use port 80, choose any other unused port.
+ Non-root users will have to choose a port number higher than
+ 1023, such as 8000.</p>
+
+ <p>SECURITY: if you do start the server as root, be sure not to
+ set <a href="mpm_common.html#user">User</a> to root. If you run
+ the server as root whilst handling connections, your site may
+ be open to a major security attack.</p>
+ <hr>
+
+ <h2><a name="require">Require directive</a></h2>
+ <!--%plaintext <?INDEX {\tt Require} directive> -->
+ <a href="directive-dict.html#Syntax" rel=
+ "Help"><strong>Syntax:</strong></a> Require
+ <em>entity-name</em> [<em>entity-name</em>] ...<br>
+ <a href="directive-dict.html#Context" rel=
+ "Help"><strong>Context:</strong></a> directory, .htaccess<br>
+ <a href="directive-dict.html#Override" rel=
+ "Help"><strong>Override:</strong></a> AuthConfig<br>
+ <a href="directive-dict.html#Status" rel=
+ "Help"><strong>Status:</strong></a> core
+
+ <p>This directive selects which authenticated users can access
+ a directory. The allowed syntaxes are:</p>
+
+ <ul>
+ <li>
+ Require user <em>userid</em> [<em>userid</em>] ...
+
+ <p>Only the named users can access the directory.</p>
+ </li>
+
+ <li>
+ Require group <em>group-name</em> [<em>group-name</em>] ...
+
+
+ <p>Only users in the named groups can access the
+ directory.</p>
+ </li>
+
+ <li>
+ Require valid-user
+
+ <p>All valid users can access the directory.</p>
+ </li>
+ </ul>
+
+ <p>Require must be accompanied by <a href=
+ "#authname">AuthName</a> and <a href="#authtype">AuthType</a>
+ directives, and directives such as <a href=
+ "mod_auth.html#authuserfile">AuthUserFile</a> and <a href=
+ "mod_auth.html#authgroupfile">AuthGroupFile</a> (to define
+ users and groups) in order to work correctly. Example:</p>
+
+ <blockquote>
+ <code>AuthType Basic<br>
+ AuthName "Restricted Directory"<br>
+ AuthUserFile /web/users<br>
+ AuthGroupFile /web/groups<br>
+ Require group admin<br>
+ </code>
+ </blockquote>
+ Access controls which are applied in this way are effective for
+ <strong>all</strong> methods. <strong>This is what is normally
+ desired.</strong> If you wish to apply access controls only to
+ specific methods, while leaving other methods unprotected, then
+ place the <code>Require</code> statement into a <a href=
+ "#limit"><Limit></a> section
+
+ <p>See also <a href="#satisfy">Satisfy</a> and <a href=
+ "mod_access.html">mod_access</a>.</p>
+ <hr>
+
+ <h2><a name="rlimit">RLimitCPU</a> <a name=
+ "rlimitcpu">directive</a></h2>
+ <!--%plaintext <?INDEX {\tt RLimitCPU} directive> -->
+ <a href="directive-dict.html#Syntax" rel=
+ "Help"><strong>Syntax:</strong></a> RLimitCPU
+ <em>number</em>|max [<em>number</em>|max] <br>
+ <a href="directive-dict.html#Default" rel=
+ "Help"><strong>Default:</strong></a> <em>Unset; uses operating
+ system defaults</em> <br>
+ <a href="directive-dict.html#Context" rel=
+ "Help"><strong>Context:</strong></a> server config, virtual
+ host<br>
+ <a href="directive-dict.html#Status" rel=
+ "Help"><strong>Status:</strong></a> core<br>
+ <a href="directive-dict.html#Compatibility" rel=
+ "Help"><strong>Compatibility:</strong></a> RLimitCPU is only
+ available in Apache 1.2 and later. Moved in version 2.0 to the
+ <a href="../mpm.html">MPMs</a>.
+
+ <p>Takes 1 or 2 parameters. The first parameter sets the soft
+ resource limit for all processes and the second parameter sets
+ the maximum resource limit. Either parameter can be a number,
+ or <em>max</em> to indicate to the server that the limit should
+ be set to the maximum allowed by the operating system
+ configuration. Raising the maximum resource limit requires that
+ the server is running as root, or in the initial startup
+ phase.</p>
+
+ <p>This applies to processes forked off from Apache children
+ servicing requests, not the Apache children themselves. This
+ includes CGI scripts and SSI exec commands, but not any
+ processes forked off from the Apache parent such as piped
+ logs.</p>
+
+ <p>CPU resource limits are expressed in seconds per
+ process.</p>
+
+ <p>See also <a href="#rlimitmem">RLimitMEM</a> or <a href=
+ "#rlimitnproc">RLimitNPROC</a>.</p>
+ <hr>
+
+ <h2><a name="rlimitmem">RLimitMEM directive</a></h2>
+ <!--%plaintext <?INDEX {\tt RLimitMEM} directive> -->
+ <a href="directive-dict.html#Syntax" rel=
+ "Help"><strong>Syntax:</strong></a> RLimitMEM
+ <em>number</em>|max [<em>number</em>|max]<br>
+ <a href="directive-dict.html#Default" rel=
+ "Help"><strong>Default:</strong></a> <em>Unset; uses operating
+ system defaults</em> <br>
+ <a href="directive-dict.html#Context" rel=
+ "Help"><strong>Context:</strong></a> server config, virtual
+ host<br>
+ <a href="directive-dict.html#Status" rel=
+ "Help"><strong>Status:</strong></a> core<br>
+ <a href="directive-dict.html#Compatibility" rel=
+ "Help"><strong>Compatibility:</strong></a> RLimitMEM is only
+ available in Apache 1.2 and later. Moved in version 2.0 to the
+ <a href="../mpm.html">MPMs</a>.
+
+ <p>Takes 1 or 2 parameters. The first parameter sets the soft
+ resource limit for all processes and the second parameter sets
+ the maximum resource limit. Either parameter can be a number,
+ or <em>max</em> to indicate to the server that the limit should
+ be set to the maximum allowed by the operating system
+ configuration. Raising the maximum resource limit requires that
+ the server is running as root, or in the initial startup
+ phase.</p>
+
+ <p>This applies to processes forked off from Apache children
+ servicing requests, not the Apache children themselves. This
+ includes CGI scripts and SSI exec commands, but not any
+ processes forked off from the Apache parent such as piped
+ logs.</p>
+
+ <p>Memory resource limits are expressed in bytes per
+ process.</p>
+
+ <p>See also <a href="#rlimitcpu">RLimitCPU</a> or <a href=
+ "#rlimitnproc">RLimitNPROC</a>.</p>
+ <hr>
+
+ <h2><a name="rlimitnproc">RLimitNPROC directive</a></h2>
+ <!--%plaintext <?INDEX {\tt RLimitNPROC} directive> -->
+ <a href="directive-dict.html#Syntax" rel=
+ "Help"><strong>Syntax:</strong></a> RLimitNPROC
+ <em>number</em>|max [<em>number</em>|max]<br>
+ <a href="directive-dict.html#Default" rel=
+ "Help"><strong>Default:</strong></a> <em>Unset; uses operating
+ system defaults</em> <br>
+ <a href="directive-dict.html#Context" rel=
+ "Help"><strong>Context:</strong></a> server config, virtual
+ host<br>
+ <a href="directive-dict.html#Status" rel=
+ "Help"><strong>Status:</strong></a> core<br>
+ <a href="directive-dict.html#Compatibility" rel=
+ "Help"><strong>Compatibility:</strong></a> RLimitNPROC is only
+ available in Apache 1.2 and later. Moved in version 2.0 to the
+ <a href="../mpm.html">MPMs</a>.
+
+ <p>Takes 1 or 2 parameters. The first parameter sets the soft
+ resource limit for all processes and the second parameter sets
+ the maximum resource limit. Either parameter can be a number,
+ or <code>max</code> to indicate to the server that the limit
+ should be set to the maximum allowed by the operating system
+ configuration. Raising the maximum resource limit requires that
+ the server is running as root, or in the initial startup
+ phase.</p>
+
+ <p>This applies to processes forked off from Apache children
+ servicing requests, not the Apache children themselves. This
+ includes CGI scripts and SSI exec commands, but not any
+ processes forked off from the Apache parent such as piped
+ logs.</p>
+
+ <p>Process limits control the number of processes per user.</p>
+
+ <p>Note: If CGI processes are <strong>not</strong> running
+ under userids other than the web server userid, this directive
+ will limit the number of processes that the server itself can
+ create. Evidence of this situation will be indicated by
+ <strong><em>cannot fork</em></strong> messages in the
+ error_log.</p>
+
+ <p>See also <a href="#rlimitmem">RLimitMEM</a> or <a href=
+ "#rlimitcpu">RLimitCPU</a>.</p>
+ <hr>
+
+ <h2><a name="satisfy">Satisfy directive</a></h2>
+ <!--%plaintext <?INDEX {\tt Satisfy} directive> -->
+ <a href="directive-dict.html#Syntax" rel=
+ "Help"><strong>Syntax:</strong></a> Satisfy any|all<br>
+ <a href="directive-dict.html#Default" rel=
+ "Help"><strong>Default:</strong></a> Satisfy all<br>
+ <a href="directive-dict.html#Context" rel=
+ "Help"><strong>Context:</strong></a> directory, .htaccess<br>
+ <a href="directive-dict.html#Status" rel=
+ "Help"><strong>Status:</strong></a> core<br>
+ <a href="directive-dict.html#Compatibility" rel=
+ "Help"><strong>Compatibility:</strong></a> Satisfy is only
+ available in Apache 1.2 and later
+
+ <p>Access policy if both <code>Allow</code> and
+ <code>Require</code> used. The parameter can be either
+ <em>'all'</em> or <em>'any'</em>. This directive is only useful
+ if access to a particular area is being restricted by both
+ username/password <em>and</em> client host address. In this
+ case the default behavior ("all") is to require that the client
+ passes the address access restriction <em>and</em> enters a
+ valid username and password. With the "any" option the client
+ will be granted access if they either pass the host restriction
+ or enter a valid username and password. This can be used to
+ password restrict an area, but to let clients from particular
+ addresses in without prompting for a password.</p>
+
+ <p>See also <a href="#require">Require</a> and <a href=
+ "mod_access.html">mod_access</a>.</p>
+ <hr>
+
+ <h2><a name="scriptinterpretersource">ScriptInterpreterSource
+ directive</a></h2>
+ <!--%plaintext <?INDEX {\tt ScriptInterpreterSource} directive> -->
+ <a href="directive-dict.html#Syntax" rel=
+ "Help"><strong>Syntax:</strong></a> ScriptInterpreterSource
+ registry|script<br>
+ <a href="directive-dict.html#Default" rel=
+ "Help"><strong>Default:</strong></a>
+ <code>ScriptInterpreterSource script</code> <br>
+ <a href="directive-dict.html#Context" rel=
+ "Help"><strong>Context:</strong></a> directory, .htaccess<br>
+ <a href="directive-dict.html#Status" rel=
+ "Help"><strong>Status:</strong></a> core (Windows only)
+
+ <p>This directive is used to control how Apache 1.3.5 and later
+ finds the interpreter used to run CGI scripts. The default
+ technique is to use the interpreter pointed to by the #! line
+ in the script. Setting ScriptInterpreterSource registry will
+ cause the Windows Registry to be searched using the script file
+ extension (e.g., .pl) as a search key.</p>
+ <hr>
+
+ <h2><a name="serveradmin">ServerAdmin directive</a></h2>
+ <!--%plaintext <?INDEX {\tt ServerAdmin} directive> -->
+ <a href="directive-dict.html#Syntax" rel=
+ "Help"><strong>Syntax:</strong></a> ServerAdmin
+ <em>email-address</em><br>
+ <a href="directive-dict.html#Context" rel=
+ "Help"><strong>Context:</strong></a> server config, virtual
+ host<br>
+ <a href="directive-dict.html#Status" rel=
+ "Help"><strong>Status:</strong></a> core
+
+ <p>The ServerAdmin sets the e-mail address that the server
+ includes in any error messages it returns to the client.</p>
+
+ <p>It may be worth setting up a dedicated address for this,
+ <em>e.g.</em></p>
+
+ <blockquote>
+ <code>ServerAdmin www-admin@foo.bar.com</code>
+ </blockquote>
+ as users do not always mention that they are talking about the
+ server!
+ <hr>
+
+ <h2><a name="serveralias">ServerAlias directive</a></h2>
+ <a href="directive-dict.html#Syntax" rel=
+ "Help"><strong>Syntax:</strong></a> ServerAlias
+ <em>hostname</em> [<em>hostname</em>] ...<br>
+ <a href="directive-dict.html#Context" rel=
+ "Help"><strong>Context:</strong></a> virtual host<br>
+ <a href="directive-dict.html#Status" rel=
+ "Help"><strong>Status:</strong></a> core<br>
+ <a href="directive-dict.html#Compatibility" rel=
+ "Help"><strong>Compatibility:</strong></a> ServerAlias is only
+ available in Apache 1.1 and later.
+
+ <p>The ServerAlias directive sets the alternate names for a
+ host, for use with <a href=
+ "../vhosts/name-based.html">name-based virtual hosts</a>.</p>
+
+ <p><strong>See also:</strong> <a href="../vhosts/">Apache
+ Virtual Host documentation</a></p>
+ <hr>
+
+ <h2><a name="servername">ServerName directive</a></h2>
+ <!--%plaintext <?INDEX {\tt ServerName} directive> -->
+ <a href="directive-dict.html#Syntax" rel=
+ "Help"><strong>Syntax:</strong></a> ServerName
+ <em>fully-qualified-domain-name</em> <br>
+ <a href="directive-dict.html#Context" rel=
+ "Help"><strong>Context:</strong></a> server config, virtual
+ host<br>
+ <a href="directive-dict.html#Status" rel=
+ "Help"><strong>Status:</strong></a> core
+
+ <p>The ServerName directive sets the hostname of the server;
+ this is used when creating redirection URLs. If it is not
+ specified, then the server attempts to deduce it from its own
+ IP address; however this may not work reliably, or may not
+ return the preferred hostname. For example:</p>
+
+ <blockquote>
+ <code>ServerName www.example.com</code>
+ </blockquote>
+ would be used if the canonical (main) name of the actual
+ machine were <code>simple.example.com</code>.
+
+ <p>If you are using <a href=
+ "../vhosts/name-based.html">name-based virtual hosts</a>, the
+ <code>ServerName</code> inside a <a href=
+ "#virtualhost"><code><VirtualHost></code></a> section
+ specifies what hostname must appear in the request's
+ <code>Host:</code> header to match this virtual host.</p>
+
+ <p><strong>See Also</strong>:<br>
+ <a href="../dns-caveats.html">DNS Issues</a><br>
+ <a href="../vhosts/">Apache virtual host documentation</a><br>
+ <a href="#usecanonicalname">UseCanonicalName</a><br>
+ <a href="#namevirtualhost">NameVirtualHost</a><br>
+ <a href="#serveralias">ServerAlias</a><br>
+ </p>
+ <hr>
+
+ <h2><a name="serverpath">ServerPath directive</a></h2>
+ <a href="directive-dict.html#Syntax" rel=
+ "Help"><strong>Syntax:</strong></a> ServerPath
+ <em>directory-path</em><br>
+ <a href="directive-dict.html#Context" rel=
+ "Help"><strong>Context:</strong></a> virtual host<br>
+ <a href="directive-dict.html#Status" rel=
+ "Help"><strong>Status:</strong></a> core<br>
+ <a href="directive-dict.html#Compatibility" rel=
+ "Help"><strong>Compatibility:</strong></a> ServerPath is only
+ available in Apache 1.1 and later.
+
+ <p>The ServerPath directive sets the legacy URL pathname for a
+ host, for use with <a href="../vhosts/">name-based virtual
+ hosts</a>.</p>
+
+ <p><strong>See also:</strong> <a href="../vhosts/">Apache
+ Virtual Host documentation</a></p>
+ <hr>
+
+ <h2><a name="serverroot">ServerRoot directive</a></h2>
+ <!--%plaintext <?INDEX {\tt ServerRoot} directive> -->
+ <a href="directive-dict.html#Syntax" rel=
+ "Help"><strong>Syntax:</strong></a> ServerRoot
+ <em>directory-path</em><br>
+ <a href="directive-dict.html#Default" rel=
+ "Help"><strong>Default:</strong></a> <code>ServerRoot
+ /usr/local/apache</code><br>
+ <a href="directive-dict.html#Context" rel=
+ "Help"><strong>Context:</strong></a> server config<br>
+ <a href="directive-dict.html#Status" rel=
+ "Help"><strong>Status:</strong></a> core
+
+ <p>The ServerRoot directive sets the directory in which the
+ server lives. Typically it will contain the subdirectories
+ <code>conf/</code> and <code>logs/</code>. Relative paths for
+ other configuration files are taken as relative to this
+ directory.</p>
+
+ <p>See also <a href="../invoking.html">the <code>-d</code>
+ option to httpd</a>.</p>
+
+ <p>See also <a href="../misc/security_tips.html#serverroot">the
+ security tips</a> for information on how to properly set
+ permissions on the ServerRoot.</p>
+ <hr>
+
+ <h2><a name="serversignature">ServerSignature
+ directive</a></h2>
+ <!--%plaintext <?INDEX {\tt ServerSignature} directive> -->
+ <a href="directive-dict.html#Syntax" rel=
+ "Help"><strong>Syntax:</strong></a> ServerSignature
+ On|Off|EMail<br>
+ <a href="directive-dict.html#Default" rel=
+ "Help"><strong>Default:</strong></a> <code>ServerSignature
+ Off</code><br>
+ <a href="directive-dict.html#Context" rel=
+ "Help"><strong>Context:</strong></a> server config, virtual
+ host, directory, .htaccess<br>
+ <a href="directive-dict.html#Status" rel=
+ "Help"><strong>Status:</strong></a> core<br>
+ <a href="directive-dict.html#Compatibility" rel=
+ "Help"><strong>Compatibility:</strong></a> ServerSignature is
+ only available in Apache 1.3 and later.
+
+ <p>The ServerSignature directive allows the configuration of a
+ trailing footer line under server-generated documents (error
+ messages, mod_proxy ftp directory listings, mod_info output,
+ ...). The reason why you would want to enable such a footer
+ line is that in a chain of proxies, the user often has no
+ possibility to tell which of the chained servers actually
+ produced a returned error message.<br>
+ The <samp>Off</samp> setting, which is the default, suppresses
+ the error line (and is therefore compatible with the behavior
+ of Apache-1.2 and below). The <samp>On</samp> setting simply
+ adds a line with the server version number and <a href=
+ "#servername">ServerName</a> of the serving virtual host, and
+ the <samp>EMail</samp> setting additionally creates a "mailto:"
+ reference to the <a href="#serveradmin">ServerAdmin</a> of the
+ referenced document.</p>
+ <hr>
+
+ <h2><a name="servertokens">ServerTokens directive</a></h2>
+ <!--%plaintext <?INDEX {\tt ServerTokens} directive> -->
+ <a href="directive-dict.html#Syntax" rel=
+ "Help"><strong>Syntax:</strong></a> ServerTokens
+ Minimal|ProductOnly|OS|Full<br>
+ <a href="directive-dict.html#Default" rel=
+ "Help"><strong>Default:</strong></a> <code>ServerTokens
+ Full</code><br>
+ <a href="directive-dict.html#Context" rel=
+ "Help"><strong>Context:</strong></a> server config <br>
+ <a href="directive-dict.html#Status" rel=
+ "Help"><strong>Status:</strong></a> core<br>
+ <a href="directive-dict.html#Compatibility" rel=
+ "Help"><strong>Compatibility:</strong></a> ServerTokens is only
+ available in Apache 1.3 and later; the <code>ProductOnly</code>
+ keyword is only available in versions later than 1.3.12
+
+ <p>This directive controls whether <samp>Server</samp> response
+ header field which is sent back to clients includes a
+ description of the generic OS-type of the server as well as
+ information about compiled-in modules.</p>
+
+ <dl>
+ <dt><code>ServerTokens Prod[uctOnly]</code></dt>
+
+ <dd>Server sends (<em>e.g.</em>): <samp>Server:
+ Apache</samp></dd>
+
+ <dt><code>ServerTokens Min[imal]</code></dt>
+
+ <dd>Server sends (<em>e.g.</em>): <samp>Server:
+ Apache/1.3.0</samp></dd>
+
+ <dt><code>ServerTokens OS</code></dt>
+
+ <dd>Server sends (<em>e.g.</em>): <samp>Server: Apache/1.3.0
+ (Unix)</samp></dd>
+
+ <dt><code>ServerTokens Full</code> (or not specified)</dt>
+
+ <dd>Server sends (<em>e.g.</em>): <samp>Server: Apache/1.3.0
+ (Unix) PHP/3.0 MyMod/1.2</samp></dd>
+ </dl>
+
+ <p>This setting applies to the entire server, and cannot be
+ enabled or disabled on a virtualhost-by-virtualhost basis.</p>
+ <hr>
+
+ <h2><a name="sethandler">SetHandler</a> directive</h2>
+ <a href="directive-dict.html#Syntax" rel=
+ "Help"><strong>Syntax:</strong></a> SetHandler
+ <em>handler-name</em><br>
+ <a href="directive-dict.html#Context" rel=
+ "Help"><strong>Context:</strong></a> directory, files,
+ location, .htaccess<br>
+ <a href="directive-dict.html#Status" rel=
+ "Help"><strong>Status:</strong></a> Base<br>
+ <a href="directive-dict.html#Module" rel=
+ "Help"><strong>Module:</strong></a> core<br>
+ <a href="directive-dict.html#Compatibility" rel=
+ "Help"><strong>Compatibility:</strong></a> SetHandler was
+ introduced in mod_mime with Apache 1.1, and moved into the core
+ with Apache 2.0
+
+ <p>When placed into an <code>.htaccess</code> file or a
+ <code><Directory></code> or <code><Location></code>
+ section, this directive forces all matching files to be parsed
+ through the <a href="../handler.html">handler</a> given by
+ <em>handler-name</em>. For example, if you had a directory you
+ wanted to be parsed entirely as imagemap rule files, regardless
+ of extension, you might put the following into an
+ <code>.htaccess</code> file in that directory:</p>
<pre>
SetHandler imap-file
</pre>
-<P>Another example: if you wanted to have the server display a status
-report whenever a URL of <code>http://servername/status</code> was
-called, you might put the following into access.conf:
+ <p>Another example: if you wanted to have the server display a
+ status report whenever a URL of
+ <code>http://servername/status</code> was called, you might put
+ the following into access.conf:</p>
<pre>
<Location /status>
SetHandler server-status
</Location>
</pre>
-
-<HR>
-
-<H2><A NAME="setinputfilter">SetInputFilter directive</A></H2>
-<P><A
- HREF="directive-dict.html#Syntax"
- REL="Help"
-><STRONG>Syntax:</STRONG></A> SetInputFilter <EM>filter</EM>[<EM>;filter</EM>...]<BR>
-<A
- HREF="directive-dict.html#Default"
- REL="Help"
-><STRONG>Default:</STRONG></A> none<BR>
-<A
- HREF="directive-dict.html#Context"
- REL="Help"
-><STRONG>Context:</STRONG></A> directory, files, location, .htaccess<BR>
-<A
- HREF="directive-dict.html#Status"
- REL="Help"
-><STRONG>Status:</STRONG></A> core</P>
-
-<p>The <code>SetInputFilter</code> directive sets the filter or filters
-which will process client requests and POST input when they are received
-by the server. This is in addition to any filters defined elsewhere,
-including the <a href="mod_mime.html#addinputfilter">AddInputFilter</a>
-directive.</p>
-
-<p>If more than one filter is specified, they must be seperated by
-semicolons in the order in which they should process the content.</p>
-
-<p>See also the <a href="../filter.html">Filters</a> documentation.</p>
-
-
-<P><HR>
-<H2><A NAME="setoutputfilter">SetOutputFilter directive</A></H2>
-<P><A
- HREF="directive-dict.html#Syntax"
- REL="Help"
-><STRONG>Syntax:</STRONG></A> SetOutputFilter <EM>filter</EM>
-[<EM>filter</EM>] ...<BR>
-<A
- HREF="directive-dict.html#Default"
- REL="Help"
-><STRONG>Default:</STRONG></A> none<BR>
-<A
- HREF="directive-dict.html#Context"
- REL="Help"
-><STRONG>Context:</STRONG></A> directory, files, location, .htaccess<BR>
-<A
- HREF="directive-dict.html#Status"
- REL="Help"
-><STRONG>Status:</STRONG></A> core</P>
-
-<P>The <code>SetOutputFilter</code> directive sets the filters which
-will process responses from the server before they are sent to the
-client. This is in addition to any filters defined elsewhere,
-including the <a href="mod_mime.html#addoutputfilter">AddOutputFilter</a>
-directive.</p>
-
-For example, the following configuration will process
-all files in the <code>/www/data/</code> directory for
-server-side includes.</P>
-
-<BLOCKQUOTE><CODE>
-<Directory /www/data/><BR>
- SetOutputFilter INCLUDES<BR>
-</Directory>
-</CODE></BLOCKQUOTE>
-
-<p>If more than one filter is specified, they must be seperated by
-semicolons in the order in which they should process the content.</p>
-
-<p>See also the <a href="../filter.html">Filters</a> documentation.</p>
-
-<P><HR>
-<H2><A NAME="timeout">TimeOut directive</A></H2>
-<!--%plaintext <?INDEX {\tt TimeOut} directive> -->
-<A
- HREF="directive-dict.html#Syntax"
- REL="Help"
-><STRONG>Syntax:</STRONG></A> TimeOut <EM>number</EM><BR>
-<A
- HREF="directive-dict.html#Default"
- REL="Help"
-><STRONG>Default:</STRONG></A> <CODE>TimeOut 300</CODE><BR>
-<A
- HREF="directive-dict.html#Context"
- REL="Help"
-><STRONG>Context:</STRONG></A> server config<BR>
-<A
- HREF="directive-dict.html#Status"
- REL="Help"
-><STRONG>Status:</STRONG></A> core<P>
-
-The TimeOut directive currently defines the amount of time Apache will
-wait for three things:
-
-<OL>
- <LI>The total amount of time it takes to receive a GET request.
- <LI>The amount of time between receipt of TCP packets on a POST or
- PUT request.
- <LI>The amount of time between ACKs on transmissions of TCP packets
- in responses.
-</OL>
-
-We plan on making these separately configurable at some point down the
-road. The timer used to default to 1200 before 1.2, but has been
-lowered to 300 which is still far more than necessary in most
-situations. It is not set any lower by default because there may
-still be odd places in the code where the timer is not reset when
-a packet is sent.
-
-<P><HR>
-
-<H2><A NAME="usecanonicalname">UseCanonicalName directive</A></H2>
-<!--%plaintext <?INDEX {\tt UseCanonicalName} directive> -->
-<A HREF="directive-dict.html#Syntax" REL="Help">
-<STRONG>Syntax:</STRONG></A> UseCanonicalName on|off|dns<BR>
-<A HREF="directive-dict.html#Default" REL="Help">
-<STRONG>Default:</STRONG></A> <CODE>UseCanonicalName on</CODE><BR>
-<A HREF="directive-dict.html#Context" REL="Help">
-<STRONG>Context:</STRONG></A> server config, virtual host, directory<BR>
-<A HREF="directive-dict.html#Override" REL="Help">
-<STRONG>Override:</STRONG></A> Options<BR>
-<A HREF="directive-dict.html#Compatibility" REL="Help">
-<STRONG>Compatibility:</STRONG></A> UseCanonicalName is only available in
-Apache 1.3 and later<P>
-
-In many situations Apache has to construct a <EM>self-referential</EM>
-URL. That is, a URL which refers back to the same server.
-With <CODE>UseCanonicalName on</CODE> (and in all versions prior to
-1.3) Apache will use the <A HREF="#servername">ServerName</A> and <A
-HREF="#port">Port</A> directives to construct a canonical name for the
-server. This name is used in all self-referential URLs, and for the
-values of <CODE>SERVER_NAME</CODE> and <CODE>SERVER_PORT</CODE> in CGIs.
-
-<P>With <CODE>UseCanonicalName off</CODE> Apache will form
-self-referential URLs using the hostname and port supplied
-by the client if any are supplied (otherwise it will use the
-canonical name). These values are the same that are used to
-implement <A HREF="../vhosts/name-based.html">name based virtual
-hosts</A>, and are available with the same clients. The CGI variables
-<CODE>SERVER_NAME</CODE> and <CODE>SERVER_PORT</CODE> will be constructed
-from the client supplied values as well.
-
-<P>An example where this may be useful is on an intranet server where
-you have users connecting to the machine using short names such as
-<CODE>www</CODE>. You'll notice that if the users type a shortname,
-and a URL which is a directory, such as <CODE>http://www/splat</CODE>,
-<EM>without the trailing slash</EM> then Apache will redirect them to
-<CODE>http://www.domain.com/splat/</CODE>. If you have authentication
-enabled, this will cause the user to have to reauthenticate twice (once
-for <CODE>www</CODE> and once again for <CODE>www.domain.com</CODE>).
-But if <CODE>UseCanonicalName</CODE> is set off, then Apache will redirect
-to <CODE>http://www/splat/</CODE>.
-
-<P>There is a third option, <CODE>UseCanonicalName DNS</CODE>, which
-is intended for use with mass IP-based virtual hosting to support
-ancient clients that do not provide a <CODE>Host:</CODE> header. With
-this option Apache does a reverse DNS lookup on the server IP address
-that the client connected to in order to work out self-referential URLs.
-
-<P><STRONG>Warning:</STRONG> if CGIs make assumptions about the values of
-<CODE>SERVER_NAME</CODE> they may be broken by this option. The client
-is essentially free to give whatever value they want as a hostname.
-But if the CGI is only using <CODE>SERVER_NAME</CODE> to construct
-self-referential URLs then it should be just fine.
-
-<P><STRONG>See also:</STRONG>
-<A HREF="#servername">ServerName</A>,
-<A HREF="#port">Port</A>
-
-<P><HR>
-
-<H2><A NAME="virtualhost"><VirtualHost> directive</A></H2>
-<!--%plaintext <?INDEX {\tt VirtualHost} section directive> -->
-<A
- HREF="directive-dict.html#Syntax"
- REL="Help"
-><STRONG>Syntax:</STRONG></A> <VirtualHost <EM>addr</EM>[:<EM>port</EM>]
-[<EM>addr</EM>[:<EM>port</EM>]] ...> ...
-</VirtualHost> <BR>
-<A
- HREF="directive-dict.html#Context"
- REL="Help"
-><STRONG>Context:</STRONG></A> server config<BR>
-<A
- HREF="directive-dict.html#Status"
- REL="Help"
-><STRONG>Status:</STRONG></A> Core.<BR>
-<A
- HREF="directive-dict.html#Compatibility"
- REL="Help"
-><STRONG>Compatibility:</STRONG></A> Non-IP address-based Virtual Hosting only
-available in Apache 1.1 and later.<BR>
-<A
- HREF="directive-dict.html#Compatibility"
- REL="Help"
-><STRONG>Compatibility:</STRONG></A> Multiple address support only available in
-Apache 1.2 and later.<P>
-
-<VirtualHost> and </VirtualHost> are used to enclose a group of
-directives which will apply only to a particular virtual host.
-Any directive which is allowed in a virtual host context may be used.
-When the server receives a request for a document on a particular virtual
-host, it uses the configuration directives enclosed in the <VirtualHost>
-section. <EM>Addr</EM> can be
-<MENU>
-<LI>The IP address of the virtual host
-<LI>A fully qualified domain name for the IP address of the virtual host.
-</MENU> Example:
-<BLOCKQUOTE>
-<CODE>
-<VirtualHost 10.1.2.3> <BR>
-ServerAdmin webmaster@host.foo.com <BR>
-DocumentRoot /www/docs/host.foo.com <BR>
-ServerName host.foo.com <BR>
-ErrorLog logs/host.foo.com-error_log <BR>
-TransferLog logs/host.foo.com-access_log <BR>
-</VirtualHost>
-</CODE></BLOCKQUOTE>
-
-Each VirtualHost must correspond to a different IP address, different port
-number or a
-different host name for the server, in the former case the server
-machine must be configured to accept IP packets for multiple
-addresses. (If the machine does not have multiple network interfaces,
-then this can be accomplished with the <CODE>ifconfig alias</CODE>
-command (if your OS supports it), or with kernel patches like <A
-HREF="../misc/vif-info.html">VIF</A> (for SunOS(TM) 4.1.x)).<P>
-
-The special name <CODE>_default_</CODE> can be specified in which case
-this virtual host will match any IP address that is not explicitly listed
-in another virtual host. In the absence of any _default_ virtual host
-the "main" server config, consisting of all those definitions outside
-any VirtualHost section, is used when no match occurs.<P>
-
-You can specify a <CODE>:port</CODE> to change the port that is matched.
-If unspecified then it defaults to the same port as the most recent
-<CODE><A HREF="#port">Port</A></CODE> statement of the main server. You
-may also specify <CODE>:*</CODE> to match all ports on that address.
-(This is recommended when used with <CODE>_default_</CODE>.)<P>
-
-<STRONG>SECURITY</STRONG>: See the
-<A HREF="../misc/security_tips.html">security tips</A>
-document for details on why your security could be compromised if
-the directory where logfiles are stored is writable by anyone other
-than the user that starts the server.
-
-<P><STRONG>NOTE</STRONG>: The use of <VirtualHost> does
-<STRONG>not</STRONG> affect what addresses Apache listens on. You may
-need to ensure that Apache is listening on the correct addresses using
-<A HREF="mpm_common.html#listen">Listen</A>.
-
-<P><STRONG>See also:</STRONG>
-<A HREF="../vhosts/">Apache Virtual Host documentation</A><BR>
-<STRONG>See also:</STRONG>
-<A HREF="../dns-caveats.html">Warnings about DNS and Apache</A><BR>
-<STRONG>See also:</STRONG>
-<A HREF="../bind.html">Setting which addresses and ports Apache uses</A><BR>
-<STRONG>See also</STRONG>: <A HREF="../sections.html">How Directory,
-Location and Files sections work</A> for an explanation of how these
-different sections are combined when a request is received
-</P>
-
-<!--#include virtual="footer.html" -->
-</BODY>
-</HTML>
+ <hr>
+
+ <h2><a name="setinputfilter">SetInputFilter directive</a></h2>
+
+ <p><a href="directive-dict.html#Syntax" rel=
+ "Help"><strong>Syntax:</strong></a> SetInputFilter
+ <em>filter</em>[<em>;filter</em>...]<br>
+ <a href="directive-dict.html#Default" rel=
+ "Help"><strong>Default:</strong></a> none<br>
+ <a href="directive-dict.html#Context" rel=
+ "Help"><strong>Context:</strong></a> directory, files,
+ location, .htaccess<br>
+ <a href="directive-dict.html#Status" rel=
+ "Help"><strong>Status:</strong></a> core</p>
+
+ <p>The <code>SetInputFilter</code> directive sets the filter or
+ filters which will process client requests and POST input when
+ they are received by the server. This is in addition to any
+ filters defined elsewhere, including the <a href=
+ "mod_mime.html#addinputfilter">AddInputFilter</a>
+ directive.</p>
+
+ <p>If more than one filter is specified, they must be seperated
+ by semicolons in the order in which they should process the
+ content.</p>
+
+ <p>See also the <a href="../filter.html">Filters</a>
+ documentation.</p>
+ <hr>
+
+ <h2><a name="setoutputfilter">SetOutputFilter
+ directive</a></h2>
+
+ <p><a href="directive-dict.html#Syntax" rel=
+ "Help"><strong>Syntax:</strong></a> SetOutputFilter
+ <em>filter</em> [<em>filter</em>] ...<br>
+ <a href="directive-dict.html#Default" rel=
+ "Help"><strong>Default:</strong></a> none<br>
+ <a href="directive-dict.html#Context" rel=
+ "Help"><strong>Context:</strong></a> directory, files,
+ location, .htaccess<br>
+ <a href="directive-dict.html#Status" rel=
+ "Help"><strong>Status:</strong></a> core</p>
+
+ <p>The <code>SetOutputFilter</code> directive sets the filters
+ which will process responses from the server before they are
+ sent to the client. This is in addition to any filters defined
+ elsewhere, including the <a href=
+ "mod_mime.html#addoutputfilter">AddOutputFilter</a>
+ directive.</p>
+ For example, the following configuration will process all files
+ in the <code>/www/data/</code> directory for server-side
+ includes.<br>
+ <br>
+
+
+ <blockquote>
+ <code><Directory /www/data/><br>
+ SetOutputFilter INCLUDES<br>
+ </Directory></code>
+ </blockquote>
+
+ <p>If more than one filter is specified, they must be seperated
+ by semicolons in the order in which they should process the
+ content.</p>
+
+ <p>See also the <a href="../filter.html">Filters</a>
+ documentation.</p>
+ <hr>
+
+ <h2><a name="timeout">TimeOut directive</a></h2>
+ <!--%plaintext <?INDEX {\tt TimeOut} directive> -->
+ <a href="directive-dict.html#Syntax" rel=
+ "Help"><strong>Syntax:</strong></a> TimeOut <em>number</em><br>
+ <a href="directive-dict.html#Default" rel=
+ "Help"><strong>Default:</strong></a> <code>TimeOut
+ 300</code><br>
+ <a href="directive-dict.html#Context" rel=
+ "Help"><strong>Context:</strong></a> server config<br>
+ <a href="directive-dict.html#Status" rel=
+ "Help"><strong>Status:</strong></a> core
+
+ <p>The TimeOut directive currently defines the amount of time
+ Apache will wait for three things:</p>
+
+ <ol>
+ <li>The total amount of time it takes to receive a GET
+ request.</li>
+
+ <li>The amount of time between receipt of TCP packets on a
+ POST or PUT request.</li>
+
+ <li>The amount of time between ACKs on transmissions of TCP
+ packets in responses.</li>
+ </ol>
+ We plan on making these separately configurable at some point
+ down the road. The timer used to default to 1200 before 1.2,
+ but has been lowered to 300 which is still far more than
+ necessary in most situations. It is not set any lower by
+ default because there may still be odd places in the code where
+ the timer is not reset when a packet is sent.
+ <hr>
+
+ <h2><a name="usecanonicalname">UseCanonicalName
+ directive</a></h2>
+ <!--%plaintext <?INDEX {\tt UseCanonicalName} directive> -->
+ <a href="directive-dict.html#Syntax" rel=
+ "Help"><strong>Syntax:</strong></a> UseCanonicalName
+ on|off|dns<br>
+ <a href="directive-dict.html#Default" rel=
+ "Help"><strong>Default:</strong></a> <code>UseCanonicalName
+ on</code><br>
+ <a href="directive-dict.html#Context" rel=
+ "Help"><strong>Context:</strong></a> server config, virtual
+ host, directory<br>
+ <a href="directive-dict.html#Override" rel=
+ "Help"><strong>Override:</strong></a> Options<br>
+ <a href="directive-dict.html#Compatibility" rel=
+ "Help"><strong>Compatibility:</strong></a> UseCanonicalName is
+ only available in Apache 1.3 and later
+
+ <p>In many situations Apache has to construct a
+ <em>self-referential</em> URL. That is, a URL which refers back
+ to the same server. With <code>UseCanonicalName on</code> (and
+ in all versions prior to 1.3) Apache will use the <a href=
+ "#servername">ServerName</a> and <a href="#port">Port</a>
+ directives to construct a canonical name for the server. This
+ name is used in all self-referential URLs, and for the values
+ of <code>SERVER_NAME</code> and <code>SERVER_PORT</code> in
+ CGIs.</p>
+
+ <p>With <code>UseCanonicalName off</code> Apache will form
+ self-referential URLs using the hostname and port supplied by
+ the client if any are supplied (otherwise it will use the
+ canonical name). These values are the same that are used to
+ implement <a href="../vhosts/name-based.html">name based
+ virtual hosts</a>, and are available with the same clients. The
+ CGI variables <code>SERVER_NAME</code> and
+ <code>SERVER_PORT</code> will be constructed from the client
+ supplied values as well.</p>
+
+ <p>An example where this may be useful is on an intranet server
+ where you have users connecting to the machine using short
+ names such as <code>www</code>. You'll notice that if the users
+ type a shortname, and a URL which is a directory, such as
+ <code>http://www/splat</code>, <em>without the trailing
+ slash</em> then Apache will redirect them to
+ <code>http://www.domain.com/splat/</code>. If you have
+ authentication enabled, this will cause the user to have to
+ reauthenticate twice (once for <code>www</code> and once again
+ for <code>www.domain.com</code>). But if
+ <code>UseCanonicalName</code> is set off, then Apache will
+ redirect to <code>http://www/splat/</code>.</p>
+
+ <p>There is a third option, <code>UseCanonicalName DNS</code>,
+ which is intended for use with mass IP-based virtual hosting to
+ support ancient clients that do not provide a
+ <code>Host:</code> header. With this option Apache does a
+ reverse DNS lookup on the server IP address that the client
+ connected to in order to work out self-referential URLs.</p>
+
+ <p><strong>Warning:</strong> if CGIs make assumptions about the
+ values of <code>SERVER_NAME</code> they may be broken by this
+ option. The client is essentially free to give whatever value
+ they want as a hostname. But if the CGI is only using
+ <code>SERVER_NAME</code> to construct self-referential URLs
+ then it should be just fine.</p>
+
+ <p><strong>See also:</strong> <a href=
+ "#servername">ServerName</a>, <a href="#port">Port</a></p>
+ <hr>
+
+ <h2><a name="virtualhost"><VirtualHost>
+ directive</a></h2>
+ <!--%plaintext <?INDEX {\tt VirtualHost} section directive> -->
+ <a href="directive-dict.html#Syntax" rel=
+ "Help"><strong>Syntax:</strong></a> <VirtualHost
+ <em>addr</em>[:<em>port</em>] [<em>addr</em>[:<em>port</em>]]
+ ...> ... </VirtualHost> <br>
+ <a href="directive-dict.html#Context" rel=
+ "Help"><strong>Context:</strong></a> server config<br>
+ <a href="directive-dict.html#Status" rel=
+ "Help"><strong>Status:</strong></a> Core.<br>
+ <a href="directive-dict.html#Compatibility" rel=
+ "Help"><strong>Compatibility:</strong></a> Non-IP address-based
+ Virtual Hosting only available in Apache 1.1 and later.<br>
+ <a href="directive-dict.html#Compatibility" rel=
+ "Help"><strong>Compatibility:</strong></a> Multiple address
+ support only available in Apache 1.2 and later.
+
+ <p><VirtualHost> and </VirtualHost> are used to
+ enclose a group of directives which will apply only to a
+ particular virtual host. Any directive which is allowed in a
+ virtual host context may be used. When the server receives a
+ request for a document on a particular virtual host, it uses
+ the configuration directives enclosed in the
+ <VirtualHost> section. <em>Addr</em> can be</p>
+
+ <ul>
+ <li>The IP address of the virtual host</li>
+
+ <li>A fully qualified domain name for the IP address of the
+ virtual host.</li>
+ </ul>
+ Example:
+
+ <blockquote>
+ <code><VirtualHost 10.1.2.3><br>
+ ServerAdmin webmaster@host.foo.com<br>
+ DocumentRoot /www/docs/host.foo.com<br>
+ ServerName host.foo.com<br>
+ ErrorLog logs/host.foo.com-error_log<br>
+ TransferLog logs/host.foo.com-access_log<br>
+ </VirtualHost></code>
+ </blockquote>
+ Each VirtualHost must correspond to a different IP address,
+ different port number or a different host name for the server,
+ in the former case the server machine must be configured to
+ accept IP packets for multiple addresses. (If the machine does
+ not have multiple network interfaces, then this can be
+ accomplished with the <code>ifconfig alias</code> command (if
+ your OS supports it), or with kernel patches like <a href=
+ "../misc/vif-info.html">VIF</a> (for SunOS(TM) 4.1.x)).
+
+ <p>The special name <code>_default_</code> can be specified in
+ which case this virtual host will match any IP address that is
+ not explicitly listed in another virtual host. In the absence
+ of any _default_ virtual host the "main" server config,
+ consisting of all those definitions outside any VirtualHost
+ section, is used when no match occurs.</p>
+
+ <p>You can specify a <code>:port</code> to change the port that
+ is matched. If unspecified then it defaults to the same port as
+ the most recent <code><a href="#port">Port</a></code> statement
+ of the main server. You may also specify <code>:*</code> to
+ match all ports on that address. (This is recommended when used
+ with <code>_default_</code>.)</p>
+
+ <p><strong>SECURITY</strong>: See the <a href=
+ "../misc/security_tips.html">security tips</a> document for
+ details on why your security could be compromised if the
+ directory where logfiles are stored is writable by anyone other
+ than the user that starts the server.</p>
+
+ <p><strong>NOTE</strong>: The use of <VirtualHost> does
+ <strong>not</strong> affect what addresses Apache listens on.
+ You may need to ensure that Apache is listening on the correct
+ addresses using <a href=
+ "mpm_common.html#listen">Listen</a>.</p>
+
+ <p><strong>See also:</strong> <a href="../vhosts/">Apache
+ Virtual Host documentation</a><br>
+ <strong>See also:</strong> <a href=
+ "../dns-caveats.html">Warnings about DNS and Apache</a><br>
+ <strong>See also:</strong> <a href="../bind.html">Setting
+ which addresses and ports Apache uses</a><br>
+ <strong>See also</strong>: <a href="../sections.html">How
+ Directory, Location and Files sections work</a> for an
+ explanation of how these different sections are combined when a
+ request is received</p>
+ <!--#include virtual="footer.html" -->
+ </body>
+</html>
projects / apache / commitdiff