diff options
| author | Rich Bowen <rbowen@apache.org> | 2001-09-06 05:48:59 +0200 |
|---|---|---|
| committer | Rich Bowen <rbowen@apache.org> | 2001-09-06 05:48:59 +0200 |
| commit | 4e1be58da35efb90d017226ddb2ad5cf02121096 (patch) | |
| tree | 9d0854dc2da0d65bf1475f1415f81973842f6a69 /docs/manual/mod/core.html | |
| parent | W3C tidy. Convert uppercase tags -> lowercase. Various other indentation (diff) | |
| download | apache2-4e1be58da35efb90d017226ddb2ad5cf02121096.tar.xz apache2-4e1be58da35efb90d017226ddb2ad5cf02121096.zip | |
W3C tidy. Lowecased HTML tags. Various other indentation and
prettification of the HTML.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@90908 13f79535-47bb-0310-9956-ffa450edef68
Diffstat (limited to 'docs/manual/mod/core.html')
| -rw-r--r-- | docs/manual/mod/core.html | 5425 |
1 files changed, 2654 insertions, 2771 deletions
diff --git a/docs/manual/mod/core.html b/docs/manual/mod/core.html index e0c240df39..cb851c764c 100644 --- a/docs/manual/mod/core.html +++ b/docs/manual/mod/core.html @@ -1,1058 +1,1021 @@ -<!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 @@ -1060,1745 +1023,1665 @@ Example: 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> |