mirror of
https://github.com/apache/httpd.git
synced 2025-06-04 21:42:15 +03:00
3006aa4a2a
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@97593 13f79535-47bb-0310-9956-ffa450edef68
2491 lines
160 KiB
XML
2491 lines
160 KiB
XML
<?xml version="1.0" encoding="ISO-8859-1"?>
|
||
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
|
||
<html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en"><head><!--
|
||
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
|
||
This file is generated from xml source: DO NOT EDIT
|
||
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
|
||
--><title>core - Apache HTTP Server</title><link href="../style/css/manual.css" rel="stylesheet" media="all" type="text/css" title="Main stylesheet" /><link href="../style/css/manual-loose-100pc.css" rel="alternate stylesheet" media="all" type="text/css" title="No Sidebar - Default font size" /><link href="../style/css/manual-print.css" rel="stylesheet" media="print" type="text/css" /><link href="../images/favicon.ico" rel="shortcut icon" /></head><body><div id="page-header"><p class="menu"><a href="../mod/">Modules</a> | <a href="../mod/directives.html">Directives</a> | <a href="../faq/">FAQ</a> | <a href="../glossary.html">Glossary</a> | <a href="../sitemap.html">Sitemap</a></p><p class="apache">Apache HTTP Server Version 2.0</p><img alt="" src="../images/feather.gif" /></div><div class="up"><a href="./"><img title="<-" alt="<-" src="../images/left.gif" /></a></div><div id="path"><a href="http://www.apache.org/">Apache</a> > <a href="http://httpd.apache.org/">HTTP Server</a> > <a href="http://httpd.apache.org/docs-project/">Documentation</a> > <a href="../">Version 2.0</a> > <a href="./">Modules</a></div><div id="page-content"><div id="preamble"><h1>Apache Module core</h1><table class="module"><tr><th><a href="module-dict.html#Description">Description:
|
||
</a></th><td>Core Apache HTTP Server features that are always
|
||
available</td></tr><tr><th><a href="module-dict.html#Status">Status:
|
||
</a></th><td>Core</td></tr></table></div><div id="quickview"><h3 class="directives">Directives</h3><ul id="toc"><li><img alt="" src="../images/down.gif" /> <a href="#acceptpathinfo">AcceptPathInfo</a></li>
|
||
<li><img alt="" src="../images/down.gif" /> <a href="#accessfilename">AccessFileName</a></li>
|
||
<li><img alt="" src="../images/down.gif" /> <a href="#adddefaultcharset">AddDefaultCharset</a></li>
|
||
<li><img alt="" src="../images/down.gif" /> <a href="#addoutputfilterbytype">AddOutputFilterByType</a></li>
|
||
<li><img alt="" src="../images/down.gif" /> <a href="#allowoverride">AllowOverride</a></li>
|
||
<li><img alt="" src="../images/down.gif" /> <a href="#authname">AuthName</a></li>
|
||
<li><img alt="" src="../images/down.gif" /> <a href="#authtype">AuthType</a></li>
|
||
<li><img alt="" src="../images/down.gif" /> <a href="#cgimapextension">CGIMapExtension</a></li>
|
||
<li><img alt="" src="../images/down.gif" /> <a href="#contentdigest">ContentDigest</a></li>
|
||
<li><img alt="" src="../images/down.gif" /> <a href="#defaulttype">DefaultType</a></li>
|
||
<li><img alt="" src="../images/down.gif" /> <a href="#directory"><Directory></a></li>
|
||
<li><img alt="" src="../images/down.gif" /> <a href="#directorymatch"><DirectoryMatch></a></li>
|
||
<li><img alt="" src="../images/down.gif" /> <a href="#documentroot">DocumentRoot</a></li>
|
||
<li><img alt="" src="../images/down.gif" /> <a href="#enablemmap">EnableMMAP</a></li>
|
||
<li><img alt="" src="../images/down.gif" /> <a href="#enablesendfile">EnableSendfile</a></li>
|
||
<li><img alt="" src="../images/down.gif" /> <a href="#errordocument">ErrorDocument</a></li>
|
||
<li><img alt="" src="../images/down.gif" /> <a href="#errorlog">ErrorLog</a></li>
|
||
<li><img alt="" src="../images/down.gif" /> <a href="#fileetag">FileETag</a></li>
|
||
<li><img alt="" src="../images/down.gif" /> <a href="#files"><Files></a></li>
|
||
<li><img alt="" src="../images/down.gif" /> <a href="#filesmatch"><FilesMatch></a></li>
|
||
<li><img alt="" src="../images/down.gif" /> <a href="#forcetype">ForceType</a></li>
|
||
<li><img alt="" src="../images/down.gif" /> <a href="#hostnamelookups">HostnameLookups</a></li>
|
||
<li><img alt="" src="../images/down.gif" /> <a href="#identitycheck">IdentityCheck</a></li>
|
||
<li><img alt="" src="../images/down.gif" /> <a href="#ifdefine"><IfDefine></a></li>
|
||
<li><img alt="" src="../images/down.gif" /> <a href="#ifmodule"><IfModule></a></li>
|
||
<li><img alt="" src="../images/down.gif" /> <a href="#include">Include</a></li>
|
||
<li><img alt="" src="../images/down.gif" /> <a href="#keepalive">KeepAlive</a></li>
|
||
<li><img alt="" src="../images/down.gif" /> <a href="#keepalivetimeout">KeepAliveTimeout</a></li>
|
||
<li><img alt="" src="../images/down.gif" /> <a href="#limit"><Limit></a></li>
|
||
<li><img alt="" src="../images/down.gif" /> <a href="#limitexcept"><LimitExcept></a></li>
|
||
<li><img alt="" src="../images/down.gif" /> <a href="#limitrequestbody">LimitRequestBody</a></li>
|
||
<li><img alt="" src="../images/down.gif" /> <a href="#limitrequestfields">LimitRequestFields</a></li>
|
||
<li><img alt="" src="../images/down.gif" /> <a href="#limitrequestfieldsize">LimitRequestFieldSize</a></li>
|
||
<li><img alt="" src="../images/down.gif" /> <a href="#limitrequestline">LimitRequestLine</a></li>
|
||
<li><img alt="" src="../images/down.gif" /> <a href="#limitxmlrequestbody">LimitXMLRequestBody</a></li>
|
||
<li><img alt="" src="../images/down.gif" /> <a href="#location"><Location></a></li>
|
||
<li><img alt="" src="../images/down.gif" /> <a href="#locationmatch"><LocationMatch></a></li>
|
||
<li><img alt="" src="../images/down.gif" /> <a href="#loglevel">LogLevel</a></li>
|
||
<li><img alt="" src="../images/down.gif" /> <a href="#maxkeepaliverequests">MaxKeepAliveRequests</a></li>
|
||
<li><img alt="" src="../images/down.gif" /> <a href="#namevirtualhost">NameVirtualHost</a></li>
|
||
<li><img alt="" src="../images/down.gif" /> <a href="#options">Options</a></li>
|
||
<li><img alt="" src="../images/down.gif" /> <a href="#require">Require</a></li>
|
||
<li><img alt="" src="../images/down.gif" /> <a href="#rlimitcpu">RLimitCPU</a></li>
|
||
<li><img alt="" src="../images/down.gif" /> <a href="#rlimitmem">RLimitMEM</a></li>
|
||
<li><img alt="" src="../images/down.gif" /> <a href="#rlimitnproc">RLimitNPROC</a></li>
|
||
<li><img alt="" src="../images/down.gif" /> <a href="#satisfy">Satisfy</a></li>
|
||
<li><img alt="" src="../images/down.gif" /> <a href="#scriptinterpretersource">ScriptInterpreterSource</a></li>
|
||
<li><img alt="" src="../images/down.gif" /> <a href="#serveradmin">ServerAdmin</a></li>
|
||
<li><img alt="" src="../images/down.gif" /> <a href="#serveralias">ServerAlias</a></li>
|
||
<li><img alt="" src="../images/down.gif" /> <a href="#servername">ServerName</a></li>
|
||
<li><img alt="" src="../images/down.gif" /> <a href="#serverpath">ServerPath</a></li>
|
||
<li><img alt="" src="../images/down.gif" /> <a href="#serverroot">ServerRoot</a></li>
|
||
<li><img alt="" src="../images/down.gif" /> <a href="#serversignature">ServerSignature</a></li>
|
||
<li><img alt="" src="../images/down.gif" /> <a href="#servertokens">ServerTokens</a></li>
|
||
<li><img alt="" src="../images/down.gif" /> <a href="#sethandler">SetHandler</a></li>
|
||
<li><img alt="" src="../images/down.gif" /> <a href="#setinputfilter">SetInputFilter</a></li>
|
||
<li><img alt="" src="../images/down.gif" /> <a href="#setoutputfilter">SetOutputFilter</a></li>
|
||
<li><img alt="" src="../images/down.gif" /> <a href="#timeout">TimeOut</a></li>
|
||
<li><img alt="" src="../images/down.gif" /> <a href="#usecanonicalname">UseCanonicalName</a></li>
|
||
<li><img alt="" src="../images/down.gif" /> <a href="#virtualhost"><VirtualHost></a></li>
|
||
</ul></div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div><div class="directive-section"><h2><a name="AcceptPathInfo" id="AcceptPathInfo">AcceptPathInfo</a> <a name="acceptpathinfo" id="acceptpathinfo">Directive</a></h2><table class="directive"><tr><th><a href="directive-dict.html#Description">Description:
|
||
</a></th><td>Resources accept trailing pathname information</td></tr><tr><th><a href="directive-dict.html#Syntax">Syntax:
|
||
</a></th><td><code>AcceptPathInfo On|Off|Default</code></td></tr><tr><th><a href="directive-dict.html#Default">Default:
|
||
</a></th><td><code>AcceptPathInfo Default</code></td></tr><tr><th><a href="directive-dict.html#Context">Context:
|
||
</a></th><td>server config, virtual host, directory, .htaccess</td></tr><tr><th><a href="directive-dict.html#Override">Override:
|
||
</a></th><td>FileInfo</td></tr><tr><th><a href="directive-dict.html#Status">Status:
|
||
</a></th><td>Core</td></tr><tr><th><a href="directive-dict.html#Module">Module:
|
||
</a></th><td>core</td></tr><tr><th><a href="directive-dict.html#Compatibility">Compatibility:
|
||
</a></th><td>Available in Apache 2.0.30 and later</td></tr></table>
|
||
|
||
<p>This directive controls whether requests that contain trailing
|
||
pathname information that follows an actual filename (or
|
||
non-existent file in an existing directory) will be accepted or
|
||
rejected. The trailing pathname information can be made
|
||
available to scripts in the PATH_INFO environment variable.</p>
|
||
|
||
<p>For example, assume the location <code>/test/</code> points to
|
||
a directory that contains only the single file
|
||
<code>here.html</code>. Then requests for
|
||
<code>/test/here.html/more</code> and
|
||
<code>/test/nothere.html/more</code> both collect
|
||
<code>/more</code> as PATH_INFO.</p>
|
||
|
||
<p>The three possible arguments for the
|
||
<code class="directive">AcceptPathInfo</code> directive are:</p>
|
||
<dl>
|
||
<dt><code>off</code></dt><dd>A request will only be accepted if it
|
||
maps to a literal path that exists. Therefore a request with
|
||
trailing pathname information after the true filename such as
|
||
<code>/test/here.html/more</code> in the above example will return
|
||
a 404 NOT FOUND error.</dd>
|
||
|
||
<dt><code>on</code></dt><dd>A request will be accepted if a
|
||
leading path component maps to a file that exists. The above
|
||
example <code>/test/here.html/more</code> will be accepted if
|
||
<code>/test/here.html</code> maps to a valid file.</dd>
|
||
|
||
<dt><code>default</code></dt><dd>The treatment of requests with
|
||
trailing pathname information is determined by the <a href="../handler.html">handler</a> responsible for the request.
|
||
The core handler for normal files defaults to rejecting PATH_INFO.
|
||
Handlers that serve scripts, such as <a href="mod_cgi.html">cgi-script</a> and <a href="mod_isapi.html">isapi-isa</a>, generally accept PATH_INFO by
|
||
default.</dd>
|
||
</dl>
|
||
|
||
<p>The primary purpose of the <code>AcceptPathInfo</code>
|
||
directive is to allow you to override the handler's choice of
|
||
accepting or rejecting PATH_INFO. This override is required, for
|
||
example, when you use a <a href="../filter.html">filter</a>, such
|
||
as <a href="mod_include.html">INCLUDES</a>, to generate content
|
||
based on PATH_INFO. The core handler would usually reject the
|
||
request, so you can use the following configuration to enable
|
||
such a script:</p>
|
||
|
||
<div class="example"><p><code>
|
||
<Files "mypaths.shtml"><br />
|
||
<span class="indent">
|
||
Options +Includes<br />
|
||
SetOutputFilter INCLUDES<br />
|
||
AcceptPathInfo on<br />
|
||
</span>
|
||
</Files>
|
||
</code></p></div>
|
||
|
||
</div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div><div class="directive-section"><h2><a name="AccessFileName" id="AccessFileName">AccessFileName</a> <a name="accessfilename" id="accessfilename">Directive</a></h2><table class="directive"><tr><th><a href="directive-dict.html#Description">Description:
|
||
</a></th><td>Name of the distributed configuration file</td></tr><tr><th><a href="directive-dict.html#Syntax">Syntax:
|
||
</a></th><td><code>AccessFileName <var>filename</var> [<var>filename</var>] ...</code></td></tr><tr><th><a href="directive-dict.html#Default">Default:
|
||
</a></th><td><code>AccessFileName .htaccess</code></td></tr><tr><th><a href="directive-dict.html#Context">Context:
|
||
</a></th><td>server config, virtual host</td></tr><tr><th><a href="directive-dict.html#Status">Status:
|
||
</a></th><td>Core</td></tr><tr><th><a href="directive-dict.html#Module">Module:
|
||
</a></th><td>core</td></tr></table>
|
||
<p>When returning a document to the client the server looks for
|
||
the first existing configuration file from this list of names in
|
||
every directory of the path to the document, if distributed
|
||
configuration files are enabled for that directory. For
|
||
example:</p>
|
||
|
||
<div class="example"><p><code>
|
||
AccessFileName .acl
|
||
</code></p></div>
|
||
|
||
<p>before returning the document
|
||
<code>/usr/local/web/index.html</code>, the server will read
|
||
<code>/.acl</code>, <code>/usr/.acl</code>,
|
||
<code>/usr/local/.acl</code> and <code>/usr/local/web/.acl</code>
|
||
for directives, unless they have been disabled with</p>
|
||
|
||
<div class="example"><p><code>
|
||
<Directory /><br />
|
||
<span class="indent">
|
||
AllowOverride None<br />
|
||
</span>
|
||
</Directory>
|
||
</code></p></div>
|
||
<h3>See also</h3><ul><li><code class="directive"><a href="#allowoverride">AllowOverride</a></code></li><li><a href="../configuring.html">Configuration Files</a></li><li><a href="../howto/htaccess.html">.htaccess Files</a></li></ul></div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div><div class="directive-section"><h2><a name="AddDefaultCharset" id="AddDefaultCharset">AddDefaultCharset</a> <a name="adddefaultcharset" id="adddefaultcharset">Directive</a></h2><table class="directive"><tr><th><a href="directive-dict.html#Description">Description:
|
||
</a></th><td>Default character set to be added for a
|
||
response without an explicit character set</td></tr><tr><th><a href="directive-dict.html#Syntax">Syntax:
|
||
</a></th><td><code>AddDefaultCharset On|Off|<var>charset</var></code></td></tr><tr><th><a href="directive-dict.html#Default">Default:
|
||
</a></th><td><code>AddDefaultCharset Off</code></td></tr><tr><th><a href="directive-dict.html#Context">Context:
|
||
</a></th><td>server config, virtual host, directory, .htaccess</td></tr><tr><th><a href="directive-dict.html#Override">Override:
|
||
</a></th><td>FileInfo</td></tr><tr><th><a href="directive-dict.html#Status">Status:
|
||
</a></th><td>Core</td></tr><tr><th><a href="directive-dict.html#Module">Module:
|
||
</a></th><td>core</td></tr></table>
|
||
<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
|
||
<var>charset</var> to be used. For example:</p>
|
||
|
||
<div class="example"><p><code>
|
||
AddDefaultCharset utf-8
|
||
</code></p></div>
|
||
</div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div><div class="directive-section"><h2><a name="AddOutputFilterByType" id="AddOutputFilterByType">AddOutputFilterByType</a> <a name="addoutputfilterbytype" id="addoutputfilterbytype">Directive</a></h2><table class="directive"><tr><th><a href="directive-dict.html#Description">Description:
|
||
</a></th><td>assigns an output filter to a particular MIME-type</td></tr><tr><th><a href="directive-dict.html#Syntax">Syntax:
|
||
</a></th><td><code>AddOutputFilterByType <var>filter</var>[;<var>filter</var>...] <var>MIME-type</var>
|
||
[<var>MIME-type</var>] ...</code></td></tr><tr><th><a href="directive-dict.html#Context">Context:
|
||
</a></th><td>server config, virtual host, directory, .htaccess</td></tr><tr><th><a href="directive-dict.html#Override">Override:
|
||
</a></th><td>FileInfo</td></tr><tr><th><a href="directive-dict.html#Status">Status:
|
||
</a></th><td>Core</td></tr><tr><th><a href="directive-dict.html#Module">Module:
|
||
</a></th><td>core</td></tr><tr><th><a href="directive-dict.html#Compatibility">Compatibility:
|
||
</a></th><td>Available in Apache 2.0.33 and later</td></tr></table>
|
||
<p>This directive activates a particular output <a href="../filter.html">filter</a> for a request depending on the
|
||
response MIME-type.</p>
|
||
|
||
<p>The following example uses the DEFLATE filter, which is provided by
|
||
<code class="module"><a href="../mod/mod_deflate.html">mod_deflate</a></code>. It will compress all output (either static
|
||
or dynamic) which is labeled as <code>text/html</code> or
|
||
<code>text/plain</code> before it is sent to the client.</p>
|
||
|
||
<div class="example"><p><code>
|
||
AddOutputFilterByType DEFLATE text/html text/plain
|
||
</code></p></div>
|
||
|
||
<p>If you want the content to be processed by more than one filter, they
|
||
have to be separated by semicolons. It's also possible to use one
|
||
<code class="directive">AddOutputFilterByType</code> directive for each of
|
||
them.</p>
|
||
|
||
<p>The configuration below causes all script output labeled as
|
||
<code>text/html</code> to be processed at first by the INCLUDES filter
|
||
and then by the DEFLATE filter.</p>
|
||
|
||
<div class="example"><p><code>
|
||
<Location /cgi-bin/><br />
|
||
<span class="indent">
|
||
Options Includes<br />
|
||
AddOutputFilterByType INCLUDES;DEFLATE text/html<br />
|
||
</span>
|
||
</Location>
|
||
</code></p></div>
|
||
|
||
<div class="note"><h3>Note:</h3>
|
||
<p>The output filters are not applied on proxy requests.</p>
|
||
</div>
|
||
<h3>See also</h3><ul><li><code class="directive"><a href="../mod/mod_mime.html#addoutputfilter">AddOutputFilter</a></code></li><li><code class="directive"><a href="#setoutputfilter">SetOutputFilter</a></code></li><li><code class="module"><a href="../mod/mod_include.html">mod_include</a></code></li><li><code class="module"><a href="../mod/mod_deflate.html">mod_deflate</a></code></li><li><a href="../filter.html">The filters documentation</a></li></ul></div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div><div class="directive-section"><h2><a name="AllowOverride" id="AllowOverride">AllowOverride</a> <a name="allowoverride" id="allowoverride">Directive</a></h2><table class="directive"><tr><th><a href="directive-dict.html#Description">Description:
|
||
</a></th><td>Types of directives that are allowed in
|
||
.htaccess files</td></tr><tr><th><a href="directive-dict.html#Syntax">Syntax:
|
||
</a></th><td><code>AllowOverride All|None|<var>directive-type</var>
|
||
[<var>directive-type</var>] ...</code></td></tr><tr><th><a href="directive-dict.html#Default">Default:
|
||
</a></th><td><code>AllowOverride All</code></td></tr><tr><th><a href="directive-dict.html#Context">Context:
|
||
</a></th><td>directory</td></tr><tr><th><a href="directive-dict.html#Status">Status:
|
||
</a></th><td>Core</td></tr><tr><th><a href="directive-dict.html#Module">Module:
|
||
</a></th><td>core</td></tr></table>
|
||
<p>When the server finds an .htaccess file (as specified by <code class="directive"><a href="#accessfilename">AccessFileName</a></code>) it needs to know
|
||
which directives declared in that file can override earlier
|
||
access information.</p>
|
||
|
||
<div class="note"><h3>Only available in Directory sections</h3>
|
||
<code class="directive">AllowOverride</code> is valid only in
|
||
<code class="directive"><a href="#directory"><Directory></a></code>
|
||
sections, not in <code class="directive"><a href="#location"><Location></a></code> or <code class="directive"><a href="#files"><Files></a></code> sections.
|
||
</div>
|
||
|
||
<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 <var>directive-type</var> can be one of the following
|
||
groupings of directives.</p>
|
||
|
||
<dl>
|
||
<dt>AuthConfig</dt>
|
||
|
||
<dd>
|
||
|
||
Allow use of the authorization directives (<code class="directive"><a href="../mod/mod_authn_dbm.html#authdbmgroupfile">AuthDBMGroupFile</a></code>,
|
||
<code class="directive"><a href="../mod/mod_authn_dbm.html#authdbmuserfile">AuthDBMUserFile</a></code>,
|
||
<code class="directive"><a href="../mod/mod_authz_groupfile.html#authgroupfile">AuthGroupFile</a></code>,
|
||
<code class="directive"><a href="#authname">AuthName</a></code>,
|
||
<code class="directive"><a href="#authtype">AuthType</a></code>, <code class="directive"><a href="../mod/mod_authn_file.html#authuserfile">AuthUserFile</a></code>, <code class="directive"><a href="#require">Require</a></code>, <em>etc.</em>).</dd>
|
||
|
||
<dt>FileInfo</dt>
|
||
|
||
<dd>
|
||
Allow use of the directives controlling document types (<code class="directive"><a href="#defaulttype">DefaultType</a></code>, <code class="directive"><a href="#errordocument">ErrorDocument</a></code>, <code class="directive"><a href="#forcetype">ForceType</a></code>, <code class="directive"><a href="../mod/mod_negotiation.html#languagepriority">LanguagePriority</a></code>,
|
||
<code class="directive"><a href="#sethandler">SetHandler</a></code>, <code class="directive"><a href="#setinputfilter">SetInputFilter</a></code>, <code class="directive"><a href="#setoutputfilter">SetOutputFilter</a></code>, and
|
||
<code class="module"><a href="../mod/mod_mime.html">mod_mime</a></code> Add* and Remove*
|
||
directives, <em>etc.</em>).</dd>
|
||
|
||
<dt>Indexes</dt>
|
||
|
||
<dd>
|
||
Allow use of the directives controlling directory indexing
|
||
(<code class="directive"><a href="../mod/mod_autoindex.html#adddescription">AddDescription</a></code>,
|
||
<code class="directive"><a href="../mod/mod_autoindex.html#addicon">AddIcon</a></code>, <code class="directive"><a href="../mod/mod_autoindex.html#addiconbyencoding">AddIconByEncoding</a></code>,
|
||
<code class="directive"><a href="../mod/mod_autoindex.html#addiconbytype">AddIconByType</a></code>,
|
||
<code class="directive"><a href="../mod/mod_autoindex.html#defaulticon">DefaultIcon</a></code>, <code class="directive"><a href="../mod/mod_dir.html#directoryindex">DirectoryIndex</a></code>, <code class="directive"><a href="../mod/mod_autoindex.html#fancyindexing">FancyIndexing</a></code>, <code class="directive"><a href="../mod/mod_autoindex.html#headername">HeaderName</a></code>, <code class="directive"><a href="../mod/mod_autoindex.html#indexignore">IndexIgnore</a></code>, <code class="directive"><a href="../mod/mod_autoindex.html#indexoptions">IndexOptions</a></code>, <code class="directive"><a href="../mod/mod_autoindex.html#readmename">ReadmeName</a></code>,
|
||
<em>etc.</em>).</dd>
|
||
|
||
<dt>Limit</dt>
|
||
|
||
<dd>
|
||
Allow use of the directives controlling host access (<code class="directive"><a href="../mod/mod_authz_host.html#allow">Allow</a></code>, <code class="directive"><a href="../mod/mod_authz_host.html#deny">Deny</a></code> and <code class="directive"><a href="../mod/mod_authz_host.html#order">Order</a></code>).</dd>
|
||
|
||
<dt>Options</dt>
|
||
|
||
<dd>
|
||
Allow use of the directives controlling specific directory
|
||
features (<code class="directive"><a href="#options">Options</a></code> and
|
||
<code class="directive"><a href="../mod/mod_include.html#xbithack">XBitHack</a></code>).</dd>
|
||
</dl>
|
||
|
||
<p>Example:</p>
|
||
|
||
<div class="example"><p><code>
|
||
AllowOverride AuthConfig Indexes
|
||
</code></p></div>
|
||
<h3>See also</h3><ul><li><code class="directive"><a href="#accessfilename">AccessFileName</a></code></li><li><a href="../configuring.html">Configuration Files</a></li><li><a href="../howto/htaccess.html">.htaccess Files</a></li></ul></div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div><div class="directive-section"><h2><a name="AuthName" id="AuthName">AuthName</a> <a name="authname" id="authname">Directive</a></h2><table class="directive"><tr><th><a href="directive-dict.html#Description">Description:
|
||
</a></th><td>Authorization realm for use in HTTP
|
||
authentication</td></tr><tr><th><a href="directive-dict.html#Syntax">Syntax:
|
||
</a></th><td><code>AuthName <var>auth-domain</var></code></td></tr><tr><th><a href="directive-dict.html#Context">Context:
|
||
</a></th><td>directory, .htaccess</td></tr><tr><th><a href="directive-dict.html#Override">Override:
|
||
</a></th><td>AuthConfig</td></tr><tr><th><a href="directive-dict.html#Status">Status:
|
||
</a></th><td>Core</td></tr><tr><th><a href="directive-dict.html#Module">Module:
|
||
</a></th><td>core</td></tr></table>
|
||
<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.
|
||
<code class="directive">AuthName</code> takes a single argument; if the
|
||
realm name contains spaces, it must be enclosed in quotation
|
||
marks. It must be accompanied by <code class="directive"><a href="#authtype">AuthType</a></code> and <code class="directive"><a href="#require">Require</a></code> directives, and directives such
|
||
as <code class="directive"><a href="../mod/mod_authn_file.html#authuserfile">AuthUserFile</a></code> and
|
||
<code class="directive"><a href="../mod/mod_authz_groupfile.html#authgroupfile">AuthGroupFile</a></code> to
|
||
work.</p>
|
||
|
||
<p>For example:</p>
|
||
|
||
<div class="example"><p><code>
|
||
AuthName "Top Secret"
|
||
</code></p></div>
|
||
|
||
<p>The string provided for the <code>AuthName</code> is what will
|
||
appear in the password dialog provided by most browsers.</p>
|
||
<h3>See also</h3><ul><li><a href="../howto/auth.html">Authentication, Authorization, and
|
||
Access Control</a></li></ul></div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div><div class="directive-section"><h2><a name="AuthType" id="AuthType">AuthType</a> <a name="authtype" id="authtype">Directive</a></h2><table class="directive"><tr><th><a href="directive-dict.html#Description">Description:
|
||
</a></th><td>Type of user authentication</td></tr><tr><th><a href="directive-dict.html#Syntax">Syntax:
|
||
</a></th><td><code>AuthType Basic|Digest</code></td></tr><tr><th><a href="directive-dict.html#Context">Context:
|
||
</a></th><td>directory, .htaccess</td></tr><tr><th><a href="directive-dict.html#Override">Override:
|
||
</a></th><td>AuthConfig</td></tr><tr><th><a href="directive-dict.html#Status">Status:
|
||
</a></th><td>Core</td></tr><tr><th><a href="directive-dict.html#Module">Module:
|
||
</a></th><td>core</td></tr></table>
|
||
<p>This directive selects the type of user authentication for a
|
||
directory. Only <code>Basic</code> and <code>Digest</code> are
|
||
currently implemented.
|
||
|
||
It must be accompanied by <code class="directive"><a href="#authname">AuthName</a></code> and <code class="directive"><a href="#require">Require</a></code> directives, and directives such
|
||
as <code class="directive"><a href="../mod/mod_authn_file.html#authuserfile">AuthUserFile</a></code> and
|
||
<code class="directive"><a href="../mod/mod_authz_groupfile.html#authgroupfile">AuthGroupFile</a></code> to
|
||
work.</p>
|
||
<h3>See also</h3><ul><li><a href="../howto/auth.html">Authentication, Authorization,
|
||
and Access Control</a></li></ul></div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div><div class="directive-section"><h2><a name="CGIMapExtension" id="CGIMapExtension">CGIMapExtension</a> <a name="cgimapextension" id="cgimapextension">Directive</a></h2><table class="directive"><tr><th><a href="directive-dict.html#Description">Description:
|
||
</a></th><td>Technique for locating the interpreter for CGI
|
||
scripts</td></tr><tr><th><a href="directive-dict.html#Syntax">Syntax:
|
||
</a></th><td><code>CGIMapExtension cgi-path .extension</code></td></tr><tr><th><a href="directive-dict.html#Default">Default:
|
||
</a></th><td><code>None</code></td></tr><tr><th><a href="directive-dict.html#Context">Context:
|
||
</a></th><td>directory, .htaccess</td></tr><tr><th><a href="directive-dict.html#Override">Override:
|
||
</a></th><td>FileInfo</td></tr><tr><th><a href="directive-dict.html#Status">Status:
|
||
</a></th><td>Core</td></tr><tr><th><a href="directive-dict.html#Module">Module:
|
||
</a></th><td>core</td></tr><tr><th><a href="directive-dict.html#Compatibility">Compatibility:
|
||
</a></th><td>NetWare only</td></tr></table>
|
||
<p>This directive is used to control how Apache finds the
|
||
interpreter used to run CGI scripts. For example, setting <code>CGIMapExtension sys:\foo.nlm .foo</code> will
|
||
cause all CGI script files with a .foo extension to be passed to the FOO interpreter.</p>
|
||
</div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div><div class="directive-section"><h2><a name="ContentDigest" id="ContentDigest">ContentDigest</a> <a name="contentdigest" id="contentdigest">Directive</a></h2><table class="directive"><tr><th><a href="directive-dict.html#Description">Description:
|
||
</a></th><td>Enables the generation of Content-MD5 HTTP Response
|
||
headers</td></tr><tr><th><a href="directive-dict.html#Syntax">Syntax:
|
||
</a></th><td><code>ContentDigest on|off</code></td></tr><tr><th><a href="directive-dict.html#Default">Default:
|
||
</a></th><td><code>ContentDigest off</code></td></tr><tr><th><a href="directive-dict.html#Context">Context:
|
||
</a></th><td>server config, virtual host, directory, .htaccess</td></tr><tr><th><a href="directive-dict.html#Override">Override:
|
||
</a></th><td>Options</td></tr><tr><th><a href="directive-dict.html#Status">Status:
|
||
</a></th><td>Core</td></tr><tr><th><a href="directive-dict.html#Module">Module:
|
||
</a></th><td>core</td></tr></table>
|
||
<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>
|
||
|
||
<div class="example"><p><code>
|
||
Content-MD5: AuLb7Dp1rqtRtxz2m9kRpA==
|
||
</code></p></div>
|
||
|
||
<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>
|
||
</div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div><div class="directive-section"><h2><a name="DefaultType" id="DefaultType">DefaultType</a> <a name="defaulttype" id="defaulttype">Directive</a></h2><table class="directive"><tr><th><a href="directive-dict.html#Description">Description:
|
||
</a></th><td>MIME content-type that will be sent if the
|
||
server cannot determine a type in any other way</td></tr><tr><th><a href="directive-dict.html#Syntax">Syntax:
|
||
</a></th><td><code>DefaultType <var>MIME-type</var></code></td></tr><tr><th><a href="directive-dict.html#Default">Default:
|
||
</a></th><td><code>DefaultType text/plain</code></td></tr><tr><th><a href="directive-dict.html#Context">Context:
|
||
</a></th><td>server config, virtual host, directory, .htaccess</td></tr><tr><th><a href="directive-dict.html#Override">Override:
|
||
</a></th><td>FileInfo</td></tr><tr><th><a href="directive-dict.html#Status">Status:
|
||
</a></th><td>Core</td></tr><tr><th><a href="directive-dict.html#Module">Module:
|
||
</a></th><td>core</td></tr></table>
|
||
<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>
|
||
|
||
<div class="example"><p><code>
|
||
DefaultType image/gif
|
||
</code></p></div>
|
||
|
||
<p>would be appropriate for a directory which contained many gif
|
||
images with filenames missing the .gif extension.</p>
|
||
|
||
<p>Note that unlike <code class="directive"><a href="#forcetype">ForceType</a></code>, 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>
|
||
</div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div><div class="directive-section"><h2><a name="Directory" id="Directory"><Directory></a> <a name="directory" id="directory">Directive</a></h2><table class="directive"><tr><th><a href="directive-dict.html#Description">Description:
|
||
</a></th><td>Enclose a group of directives that apply only to the
|
||
named file-system directory and sub-directories</td></tr><tr><th><a href="directive-dict.html#Syntax">Syntax:
|
||
</a></th><td><code><Directory <var>directory-path</var>>
|
||
... </Directory></code></td></tr><tr><th><a href="directive-dict.html#Context">Context:
|
||
</a></th><td>server config, virtual host</td></tr><tr><th><a href="directive-dict.html#Status">Status:
|
||
</a></th><td>Core</td></tr><tr><th><a href="directive-dict.html#Module">Module:
|
||
</a></th><td>core</td></tr></table>
|
||
<p><code class="directive"><Directory></code> and
|
||
<code></Directory></code> are used to enclose a group of
|
||
directives that will apply only to the named directory and
|
||
sub-directories of that directory. Any directive that is allowed
|
||
in a directory context may be used. <var>Directory-path</var> is
|
||
either the full path to a directory, or a wild-card string using
|
||
Unix shell-style matching. In a wild-card string, `?' matches any
|
||
single character, and `*' matches any sequences of characters.
|
||
You may also use `[]' character ranges. None of the wildcards
|
||
match a `/' character, so <code><Directory
|
||
/*/public_html></code> will not match
|
||
<code>/home/user/public_html</code>, but <code><Directory
|
||
/home/*/public_html></code> will match. Example:</p>
|
||
|
||
<div class="example"><p><code>
|
||
<Directory /usr/local/httpd/htdocs><br />
|
||
<span class="indent">
|
||
Options Indexes FollowSymLinks<br />
|
||
</span>
|
||
</Directory>
|
||
</code></p></div>
|
||
|
||
<div class="note">
|
||
<p>Be careful with the <var>directory-path</var> arguments:
|
||
They have to literally match the filesystem path which Apache uses
|
||
to access the files. Directives applied to a particular
|
||
<Directory> will not apply to files accessed from that same
|
||
directory via a different path, such as via different symbolic
|
||
links.</p>
|
||
</div>
|
||
|
||
<p>Extended regular
|
||
expressions can also be used, with the addition of the
|
||
<code>~</code> character. For example:</p>
|
||
|
||
<div class="example"><p><code>
|
||
<Directory ~ "^/www/.*/[0-9]{3}">
|
||
</code></p></div>
|
||
|
||
<p>would match directories in /www/ that consisted of three
|
||
numbers.</p>
|
||
|
||
<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>
|
||
|
||
<div class="example"><p><code>
|
||
<Directory /><br />
|
||
<span class="indent">
|
||
AllowOverride None<br />
|
||
</span>
|
||
</Directory><br />
|
||
<br />
|
||
<Directory /home/><br />
|
||
<span class="indent">
|
||
AllowOverride FileInfo<br />
|
||
</span>
|
||
</Directory>
|
||
</code></p></div>
|
||
|
||
<p>for access to the document <code>/home/web/dir/doc.html</code>
|
||
the steps are:</p>
|
||
|
||
<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 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>
|
||
|
||
<div class="example"><p><code>
|
||
<Directory ~ abc$><br />
|
||
<span class="indent">
|
||
# ... directives here ...<br />
|
||
</span>
|
||
</Directory>
|
||
</code></p></div>
|
||
|
||
<p>The regular expression section 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>
|
||
|
||
<p><strong>Note that the default Apache access for
|
||
<Directory /> is <code>Allow from All</code>. 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>
|
||
|
||
<div class="example"><p><code>
|
||
<Directory /><br />
|
||
<span class="indent">
|
||
Order Deny,Allow<br />
|
||
Deny from All<br />
|
||
</span>
|
||
</Directory>
|
||
</code></p></div>
|
||
|
||
<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>
|
||
|
||
<p>The directory sections typically occur in
|
||
the access.conf file, but they may appear in any configuration
|
||
file. <code class="directive"><Directory></code> directives
|
||
cannot nest, and cannot appear in a <code class="directive"><a href="#limit"><Limit></a></code> or <code class="directive"><a href="#limitexcept"><LimitExcept></a></code> section.</p>
|
||
<h3>See also</h3><ul><li><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</li></ul></div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div><div class="directive-section"><h2><a name="DirectoryMatch" id="DirectoryMatch"><DirectoryMatch></a> <a name="directorymatch" id="directorymatch">Directive</a></h2><table class="directive"><tr><th><a href="directive-dict.html#Description">Description:
|
||
</a></th><td>Enclose directives that apply to
|
||
file-system directories matching a regular expression and their
|
||
subdirectories</td></tr><tr><th><a href="directive-dict.html#Syntax">Syntax:
|
||
</a></th><td><code><DirectoryMatch <var>regex</var>>
|
||
... </DirectoryMatch></code></td></tr><tr><th><a href="directive-dict.html#Context">Context:
|
||
</a></th><td>server config, virtual host</td></tr><tr><th><a href="directive-dict.html#Status">Status:
|
||
</a></th><td>Core</td></tr><tr><th><a href="directive-dict.html#Module">Module:
|
||
</a></th><td>core</td></tr></table>
|
||
<p><code class="directive"><DirectoryMatch></code> and
|
||
<code></DirectoryMatch></code> 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 <code class="directive"><a href="#directory"><Directory></a></code>. However, it
|
||
takes as an argument a regular expression. For example:</p>
|
||
|
||
<div class="example"><p><code>
|
||
<DirectoryMatch "^/www/.*/[0-9]{3}">
|
||
</code></p></div>
|
||
|
||
<p>would match directories in <code>/www/</code> that consisted of three
|
||
numbers.</p>
|
||
<h3>See also</h3><ul><li><code class="directive"><a href="#directory"><Directory></a></code> for
|
||
a description of how regular expressions are mixed in with normal
|
||
<code><Directory></code>s</li><li><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</li></ul></div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div><div class="directive-section"><h2><a name="DocumentRoot" id="DocumentRoot">DocumentRoot</a> <a name="documentroot" id="documentroot">Directive</a></h2><table class="directive"><tr><th><a href="directive-dict.html#Description">Description:
|
||
</a></th><td>Directory that forms the main document tree visible
|
||
from the web</td></tr><tr><th><a href="directive-dict.html#Syntax">Syntax:
|
||
</a></th><td><code>DocumentRoot <var>directory-path</var></code></td></tr><tr><th><a href="directive-dict.html#Default">Default:
|
||
</a></th><td><code>DocumentRoot /usr/local/apache/htdocs</code></td></tr><tr><th><a href="directive-dict.html#Context">Context:
|
||
</a></th><td>server config, virtual host</td></tr><tr><th><a href="directive-dict.html#Status">Status:
|
||
</a></th><td>Core</td></tr><tr><th><a href="directive-dict.html#Module">Module:
|
||
</a></th><td>core</td></tr></table>
|
||
<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>
|
||
|
||
<div class="example"><p><code>
|
||
DocumentRoot /usr/web
|
||
</code></p></div>
|
||
|
||
<p>then an access to
|
||
<code>http://www.my.host.com/index.html</code> refers to
|
||
<code>/usr/web/index.html</code>.</p>
|
||
|
||
<p>The <code class="directive">DocumentRoot</code> should be specified without
|
||
a trailing slash.</p>
|
||
<h3>See also</h3><ul><li><a href="../urlmapping.html">Mapping URLs to Filesystem
|
||
Location</a></li></ul></div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div><div class="directive-section"><h2><a name="EnableMMAP" id="EnableMMAP">EnableMMAP</a> <a name="enablemmap" id="enablemmap">Directive</a></h2><table class="directive"><tr><th><a href="directive-dict.html#Description">Description:
|
||
</a></th><td>Use memory-mapping to read files during delivery</td></tr><tr><th><a href="directive-dict.html#Syntax">Syntax:
|
||
</a></th><td><code>EnableMMAP on|off</code></td></tr><tr><th><a href="directive-dict.html#Default">Default:
|
||
</a></th><td><code>EnableMMAP on</code></td></tr><tr><th><a href="directive-dict.html#Context">Context:
|
||
</a></th><td>server config, virtual host, directory, .htaccess</td></tr><tr><th><a href="directive-dict.html#Override">Override:
|
||
</a></th><td>FileInfo</td></tr><tr><th><a href="directive-dict.html#Status">Status:
|
||
</a></th><td>Core</td></tr><tr><th><a href="directive-dict.html#Module">Module:
|
||
</a></th><td>core</td></tr></table>
|
||
<p>This directive controls whether the httpd may use
|
||
memory-mapping if it needs to read the contents of a file during
|
||
delivery. By default, when the handling of a request requires
|
||
access to the data within a file-- for example, when delivering a
|
||
server-parsed file using <code class="module"><a href="../mod/mod_include.html">mod_include</a></code>-- Apache
|
||
memory-maps the file if the OS supports it.</p>
|
||
|
||
<p>This memory-mapping sometimes yields a performance improvement.
|
||
But in some environments, it is better to disable the memory-mapping
|
||
to prevent operational problems:</p>
|
||
|
||
<ul>
|
||
<li>On some multiprocessor systems, memory-mapping can reduce the
|
||
performance of the httpd.</li>
|
||
<li>With an NFS-mounted <code class="directive"><a href="#documentroot">DocumentRoot</a></code>,
|
||
the httpd may crash due to a segmentation fault if a file is deleted
|
||
or truncated while the httpd has it memory-mapped.</li>
|
||
</ul>
|
||
|
||
<p>For server configurations that are vulnerable to these problems,
|
||
you should disable memory-mapping of delivered files by specifying:</p>
|
||
|
||
<div class="example"><p><code>
|
||
EnableMMAP off
|
||
</code></p></div>
|
||
|
||
<p>For NFS mounted files, this feature may be disabled explicitly for
|
||
the offending files by specifying:</p>
|
||
|
||
<div class="example"><p><code>
|
||
<Directory "/path-to-nfs-files">
|
||
EnableMMAP off
|
||
</Directory>
|
||
</code></p></div>
|
||
</div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div><div class="directive-section"><h2><a name="EnableSendfile" id="EnableSendfile">EnableSendfile</a> <a name="enablesendfile" id="enablesendfile">Directive</a></h2><table class="directive"><tr><th><a href="directive-dict.html#Description">Description:
|
||
</a></th><td>Use the kernel sendfile support to deliver files to the client</td></tr><tr><th><a href="directive-dict.html#Syntax">Syntax:
|
||
</a></th><td><code>EnableSendfile on|off</code></td></tr><tr><th><a href="directive-dict.html#Default">Default:
|
||
</a></th><td><code>EnableSendfile on</code></td></tr><tr><th><a href="directive-dict.html#Context">Context:
|
||
</a></th><td>server config, virtual host, directory, .htaccess</td></tr><tr><th><a href="directive-dict.html#Override">Override:
|
||
</a></th><td>FileInfo</td></tr><tr><th><a href="directive-dict.html#Status">Status:
|
||
</a></th><td>Core</td></tr><tr><th><a href="directive-dict.html#Module">Module:
|
||
</a></th><td>core</td></tr><tr><th><a href="directive-dict.html#Compatibility">Compatibility:
|
||
</a></th><td>Available in version 2.0.44 and later</td></tr></table>
|
||
<p>This directive controls whether httpd may use the sendfile
|
||
support from the kernel to transmit file contents to the client.
|
||
By default, when the handling of a request requires no access
|
||
to the data within a file -- for example, when delivering a
|
||
static file -- Apache uses sendfile to deliver the file contents
|
||
without ever reading the file if the OS supports it.</p>
|
||
|
||
<p>This sendfile mechanism avoids seperate read and send operations,
|
||
and buffer allocations. But on some platforms or within some
|
||
filesystems, it is better to disable this feature to avoid
|
||
operational problems:</p>
|
||
|
||
<ul>
|
||
<li>Some platforms may have broken sendfile support that the build
|
||
system did not detect, especially if the binaries were built on
|
||
another box and moved to such a machine with broken sendfile
|
||
support.</li>
|
||
<li>With a network-mounted <code class="directive"><a href="#documentroot">DocumentRoot</a></code> (e.g., NFS or SMB),
|
||
the kernel may be unable to serve the network file through
|
||
its own cache.</li>
|
||
</ul>
|
||
|
||
<p>For server configurations that are vulnerable to these problems,
|
||
you should disable this feature by specifying:</p>
|
||
|
||
<div class="example"><p><code>
|
||
EnableSendfile off
|
||
</code></p></div>
|
||
|
||
<p>For NFS or SMB mounted files, this feature may be disabled explicitly
|
||
for the offending files by specifying:</p>
|
||
|
||
<div class="example"><p><code>
|
||
<Directory "/path-to-nfs-files"><br />
|
||
EnableSendfile off<br />
|
||
</Directory>
|
||
</code></p></div>
|
||
</div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div><div class="directive-section"><h2><a name="ErrorDocument" id="ErrorDocument">ErrorDocument</a> <a name="errordocument" id="errordocument">Directive</a></h2><table class="directive"><tr><th><a href="directive-dict.html#Description">Description:
|
||
</a></th><td>What the server will return to the client
|
||
in case of an error</td></tr><tr><th><a href="directive-dict.html#Syntax">Syntax:
|
||
</a></th><td><code>ErrorDocument <var>error-code</var> <var>document</var></code></td></tr><tr><th><a href="directive-dict.html#Context">Context:
|
||
</a></th><td>server config, virtual host, directory, .htaccess</td></tr><tr><th><a href="directive-dict.html#Override">Override:
|
||
</a></th><td>FileInfo</td></tr><tr><th><a href="directive-dict.html#Status">Status:
|
||
</a></th><td>Core</td></tr><tr><th><a href="directive-dict.html#Module">Module:
|
||
</a></th><td>core</td></tr><tr><th><a href="directive-dict.html#Compatibility">Compatibility:
|
||
</a></th><td>Quoting syntax for text messages is different in Apache
|
||
2.0</td></tr></table>
|
||
<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 <var>URL-path</var> to handle the
|
||
problem/error</li>
|
||
|
||
<li>redirect to an external <var>URL</var> to handle the
|
||
problem/error</li>
|
||
</ol>
|
||
|
||
<p>The first option is the default, while options 2-4 are
|
||
configured using the <code class="directive">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>
|
||
|
||
<div class="example"><p><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></p></div>
|
||
|
||
<p>Note that when you specify an <code class="directive">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>Microsoft Internet Explorer (MSIE) will ignore server-generated
|
||
error messages when they are "too small" and substitute its own
|
||
"friendly" error messages. The size threshold varies depending on
|
||
the type of error, but in general, if you make your error document
|
||
greater than 512 bytes, then MSIE will show the server-generated
|
||
error rather than masking it. More information is available in
|
||
Microsoft Knowledgebase article <a href="http://support.microsoft.com/default.aspx?scid=kb;en-us;Q294807">Q294807</a>.</p>
|
||
|
||
<p>Prior to version 2.0, messages were indicated by prefixing
|
||
them with a single unmatched double quote character.</p>
|
||
<h3>See also</h3><ul><li><a href="../custom-error.html">documentation of
|
||
customizable responses</a></li></ul></div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div><div class="directive-section"><h2><a name="ErrorLog" id="ErrorLog">ErrorLog</a> <a name="errorlog" id="errorlog">Directive</a></h2><table class="directive"><tr><th><a href="directive-dict.html#Description">Description:
|
||
</a></th><td>Location where the server will log errors</td></tr><tr><th><a href="directive-dict.html#Syntax">Syntax:
|
||
</a></th><td><code> ErrorLog <var>file-path</var>|syslog[:<var>facility</var>]</code></td></tr><tr><th><a href="directive-dict.html#Default">Default:
|
||
</a></th><td><code>ErrorLog logs/error_log (Unix)
|
||
ErrorLog logs/error.log (Windows and OS/2)</code></td></tr><tr><th><a href="directive-dict.html#Context">Context:
|
||
</a></th><td>server config, virtual host</td></tr><tr><th><a href="directive-dict.html#Status">Status:
|
||
</a></th><td>Core</td></tr><tr><th><a href="directive-dict.html#Module">Module:
|
||
</a></th><td>core</td></tr></table>
|
||
<p>The <code class="directive">ErrorLog</code> directive sets the name of
|
||
the file to which the server will log any errors it encounters. If
|
||
the <var>file-path</var> does not begin with a slash (/) then it is
|
||
assumed to be relative to the <code class="directive"><a href="#serverroot">ServerRoot</a></code>.</p>
|
||
|
||
<div class="example"><h3>Example</h3><p><code>
|
||
ErrorLog /var/log/httpd/error_log
|
||
</code></p></div>
|
||
|
||
<p>If the <var>file-path</var>
|
||
begins with a pipe (|) then it is assumed to be a command to spawn
|
||
to handle the error log.</p>
|
||
|
||
<div class="example"><h3>Example</h3><p><code>
|
||
ErrorLog "|/usr/local/bin/httpd_errors"
|
||
</code></p></div>
|
||
|
||
<p>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:<var>facility</var></code> syntax where
|
||
<var>facility</var> can be one of the names usually documented in
|
||
syslog(1).</p>
|
||
|
||
<div class="example"><h3>Example</h3><p><code>
|
||
ErrorLog syslog:user
|
||
</code></p></div>
|
||
|
||
<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>
|
||
<h3>See also</h3><ul><li><code class="directive"><a href="#loglevel">LogLevel</a></code></li><li><a href="../logs.html">Apache Log Files</a></li></ul></div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div><div class="directive-section"><h2><a name="FileETag" id="FileETag">FileETag</a> <a name="fileetag" id="fileetag">Directive</a></h2><table class="directive"><tr><th><a href="directive-dict.html#Description">Description:
|
||
</a></th><td>File attributes used to create the ETag
|
||
HTTP response header</td></tr><tr><th><a href="directive-dict.html#Syntax">Syntax:
|
||
</a></th><td><code>FileETag <var>component</var> ...</code></td></tr><tr><th><a href="directive-dict.html#Default">Default:
|
||
</a></th><td><code>FileETag INode MTime Size</code></td></tr><tr><th><a href="directive-dict.html#Context">Context:
|
||
</a></th><td>server config, virtual host, directory, .htaccess</td></tr><tr><th><a href="directive-dict.html#Override">Override:
|
||
</a></th><td>FileInfo</td></tr><tr><th><a href="directive-dict.html#Status">Status:
|
||
</a></th><td>Core</td></tr><tr><th><a href="directive-dict.html#Module">Module:
|
||
</a></th><td>core</td></tr></table>
|
||
<p>
|
||
The <code class="directive">FileETag</code> directive configures the file
|
||
attributes that are used to create the ETag (entity tag) response
|
||
header field when the document is based on a file. (The ETag
|
||
value is used in cache management to save network bandwidth.) In
|
||
Apache 1.3.22 and earlier, the ETag value was <em>always</em> formed
|
||
from the file's inode, size, and last-modified time (mtime). The
|
||
FileETag directive allows you to choose which of these -- if any
|
||
-- should be used. The recognized keywords are:
|
||
</p>
|
||
|
||
<dl>
|
||
<dt><strong>INode</strong></dt>
|
||
<dd>The file's i-node number will be included in the calculation</dd>
|
||
<dt><strong>MTime</strong></dt>
|
||
<dd>The date and time the file was last modified will be included</dd>
|
||
<dt><strong>Size</strong></dt>
|
||
<dd>The number of bytes in the file will be included</dd>
|
||
<dt><strong>All</strong></dt>
|
||
<dd>All available fields will be used. This is equivalent to:
|
||
<div class="example"><p><code>FileETag INode MTime Size</code></p></div></dd>
|
||
<dt><strong>None</strong></dt>
|
||
<dd>If a document is file-based, no ETag field will be included in the
|
||
response</dd>
|
||
</dl>
|
||
|
||
<p>The <code>INode</code>, <code>MTime</code>, and <code>Size</code>
|
||
keywords may be prefixed with either <code>+</code> or <code>-</code>,
|
||
which allow changes to be made to the default setting inherited
|
||
from a broader scope. Any keyword appearing without such a prefix
|
||
immediately and completely cancels the inherited setting.</p>
|
||
|
||
<p>If a directory's configuration includes
|
||
<code>FileETag<EFBFBD>INode<EFBFBD>MTime<EFBFBD>Size</code>, and a
|
||
subdirectory's includes <code>FileETag<EFBFBD>-INode</code>,
|
||
the setting for that subdirectory (which will be inherited by
|
||
any sub-subdirectories that don't override it) will be equivalent to
|
||
<code>FileETag<EFBFBD>MTime<EFBFBD>Size</code>.</p>
|
||
</div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div><div class="directive-section"><h2><a name="Files" id="Files"><Files></a> <a name="files" id="files">Directive</a></h2><table class="directive"><tr><th><a href="directive-dict.html#Description">Description:
|
||
</a></th><td>Contains directives that apply to matched
|
||
filenames</td></tr><tr><th><a href="directive-dict.html#Syntax">Syntax:
|
||
</a></th><td><code><Files <var>filename</var>> ... </Files></code></td></tr><tr><th><a href="directive-dict.html#Context">Context:
|
||
</a></th><td>server config, virtual host, directory, .htaccess</td></tr><tr><th><a href="directive-dict.html#Override">Override:
|
||
</a></th><td>All</td></tr><tr><th><a href="directive-dict.html#Status">Status:
|
||
</a></th><td>Core</td></tr><tr><th><a href="directive-dict.html#Module">Module:
|
||
</a></th><td>core</td></tr></table>
|
||
<p>The <code class="directive"><Files></code> directive
|
||
provides for access control by filename. It is comparable to the
|
||
<code class="directive"><a href="#directory">Directory</a></code>
|
||
directive and <code class="directive"><a href="#location">Location</a></code> directives. It should be
|
||
matched with a <code></Files></code> 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 class="directive"><Files></code>
|
||
sections are processed in the order they appear in the
|
||
configuration file, after the <code class="directive"><a href="#directory"><Directory></a></code> sections and
|
||
<code>.htaccess</code> files are read, but before <code class="directive"><a href="#location"><Location></a></code> sections. Note
|
||
that <code class="directive"><Files></code> can be nested
|
||
inside <code class="directive"><a href="#directory"><Directory></a></code> sections to restrict the
|
||
portion of the filesystem they apply to.</p>
|
||
|
||
<p>The <var>filename</var> 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>
|
||
|
||
<div class="example"><p><code>
|
||
<Files ~ "\.(gif|jpe?g|png)$">
|
||
</code></p></div>
|
||
|
||
<p>would match most common Internet graphics formats. In Apache 1.3
|
||
and later, <code class="directive"><a href="#filesmatch"><FilesMatch></a></code> is preferred, however.</p>
|
||
|
||
<p>Note that unlike <code class="directive"><a href="#directory"><Directory></a></code> and <code class="directive"><a href="#location"><Location></a></code> sections, <code class="directive"><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>
|
||
|
||
<h3>See also</h3><ul><li><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</li></ul></div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div><div class="directive-section"><h2><a name="FilesMatch" id="FilesMatch"><FilesMatch></a> <a name="filesmatch" id="filesmatch">Directive</a></h2><table class="directive"><tr><th><a href="directive-dict.html#Description">Description:
|
||
</a></th><td>Contains directives that apply to regular-expression matched
|
||
filenames</td></tr><tr><th><a href="directive-dict.html#Syntax">Syntax:
|
||
</a></th><td><code><FilesMatch <var>regex</var>> ... </FilesMatch></code></td></tr><tr><th><a href="directive-dict.html#Context">Context:
|
||
</a></th><td>server config, virtual host, directory, .htaccess</td></tr><tr><th><a href="directive-dict.html#Override">Override:
|
||
</a></th><td>All</td></tr><tr><th><a href="directive-dict.html#Status">Status:
|
||
</a></th><td>Core</td></tr><tr><th><a href="directive-dict.html#Module">Module:
|
||
</a></th><td>core</td></tr></table>
|
||
<p>The <code class="directive"><FilesMatch></code> directive
|
||
provides for access control by filename, just as the <code class="directive"><a href="#files"><Files></a></code> directive
|
||
does. However, it accepts a regular expression. For example:</p>
|
||
|
||
<div class="example"><p><code>
|
||
<FilesMatch "\.(gif|jpe?g|png)$">
|
||
</code></p></div>
|
||
|
||
<p>would match most common Internet graphics formats.</p>
|
||
<h3>See also</h3><ul><li><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</li></ul></div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div><div class="directive-section"><h2><a name="ForceType" id="ForceType">ForceType</a> <a name="forcetype" id="forcetype">Directive</a></h2><table class="directive"><tr><th><a href="directive-dict.html#Description">Description:
|
||
</a></th><td>Forces all matching files to be served with the specified
|
||
MIME content-type</td></tr><tr><th><a href="directive-dict.html#Syntax">Syntax:
|
||
</a></th><td><code>ForceType <var>MIME-type</var>|none</code></td></tr><tr><th><a href="directive-dict.html#Context">Context:
|
||
</a></th><td>directory, .htaccess</td></tr><tr><th><a href="directive-dict.html#Override">Override:
|
||
</a></th><td>FileInfo</td></tr><tr><th><a href="directive-dict.html#Status">Status:
|
||
</a></th><td>Core</td></tr><tr><th><a href="directive-dict.html#Module">Module:
|
||
</a></th><td>core</td></tr><tr><th><a href="directive-dict.html#Compatibility">Compatibility:
|
||
</a></th><td>Moved to the core in Apache 2.0</td></tr></table>
|
||
<p>When placed into an <code>.htaccess</code> file or a
|
||
<code class="directive"><a href="#directory"><Directory></a></code>, or
|
||
<code class="directive"><a href="#location"><Location></a></code> or
|
||
<code class="directive"><a href="#files"><Files></a></code>
|
||
section, this directive forces all matching files to be served
|
||
with the content type identification given by
|
||
<var>MIME-type</var>. 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>
|
||
|
||
<div class="example"><p><code>
|
||
ForceType image/gif
|
||
</code></p></div>
|
||
|
||
<p>Note that unlike <code class="directive"><a href="#defaulttype">DefaultType</a></code>,
|
||
this directive overrides all mime-type associations, including
|
||
filename extensions, that might identify the media type.</p>
|
||
|
||
<p>You can override any <code class="directive">ForceType</code> setting
|
||
by using the value of <code>none</code>:</p>
|
||
|
||
<div class="example"><p><code>
|
||
# force all files to be image/gif:<br />
|
||
<Location /images><br />
|
||
<span class="indent">
|
||
ForceType image/gif<br />
|
||
</span>
|
||
</Location><br />
|
||
<br />
|
||
# but normal mime-type associations here:<br />
|
||
<Location /images/mixed><br />
|
||
<span class="indent">
|
||
ForceType none<br />
|
||
</span>
|
||
</Location>
|
||
</code></p></div>
|
||
</div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div><div class="directive-section"><h2><a name="HostnameLookups" id="HostnameLookups">HostnameLookups</a> <a name="hostnamelookups" id="hostnamelookups">Directive</a></h2><table class="directive"><tr><th><a href="directive-dict.html#Description">Description:
|
||
</a></th><td>Enables DNS lookups on client IP addresses</td></tr><tr><th><a href="directive-dict.html#Syntax">Syntax:
|
||
</a></th><td><code>HostnameLookups on|off|double</code></td></tr><tr><th><a href="directive-dict.html#Default">Default:
|
||
</a></th><td><code>HostnameLookups off</code></td></tr><tr><th><a href="directive-dict.html#Context">Context:
|
||
</a></th><td>server config, virtual host, directory</td></tr><tr><th><a href="directive-dict.html#Status">Status:
|
||
</a></th><td>Core</td></tr><tr><th><a href="directive-dict.html#Module">Module:
|
||
</a></th><td>core</td></tr></table>
|
||
<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 <code class="module"><a href="../mod/mod_authz_host.html">mod_authz_host</a></code> 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 is off 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 <var>/support</var> directory, can be used to look up host
|
||
names from logged IP addresses offline.</p>
|
||
</div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div><div class="directive-section"><h2><a name="IdentityCheck" id="IdentityCheck">IdentityCheck</a> <a name="identitycheck" id="identitycheck">Directive</a></h2><table class="directive"><tr><th><a href="directive-dict.html#Description">Description:
|
||
</a></th><td>Enables logging of the RFC1413 identity of the remote
|
||
user</td></tr><tr><th><a href="directive-dict.html#Syntax">Syntax:
|
||
</a></th><td><code>IdentityCheck on|off</code></td></tr><tr><th><a href="directive-dict.html#Default">Default:
|
||
</a></th><td><code>IdentityCheck off</code></td></tr><tr><th><a href="directive-dict.html#Context">Context:
|
||
</a></th><td>server config, virtual host, directory</td></tr><tr><th><a href="directive-dict.html#Status">Status:
|
||
</a></th><td>Core</td></tr><tr><th><a href="directive-dict.html#Module">Module:
|
||
</a></th><td>core</td></tr></table>
|
||
<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.</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>
|
||
</div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div><div class="directive-section"><h2><a name="IfDefine" id="IfDefine"><IfDefine></a> <a name="ifdefine" id="ifdefine">Directive</a></h2><table class="directive"><tr><th><a href="directive-dict.html#Description">Description:
|
||
</a></th><td>Encloses directives that will be processed only
|
||
if a test is true at startup</td></tr><tr><th><a href="directive-dict.html#Syntax">Syntax:
|
||
</a></th><td><code><IfDefine [!]<var>parameter-name</var>> ...
|
||
</IfDefine></code></td></tr><tr><th><a href="directive-dict.html#Context">Context:
|
||
</a></th><td>server config, virtual host, directory, .htaccess</td></tr><tr><th><a href="directive-dict.html#Override">Override:
|
||
</a></th><td>All</td></tr><tr><th><a href="directive-dict.html#Status">Status:
|
||
</a></th><td>Core</td></tr><tr><th><a href="directive-dict.html#Module">Module:
|
||
</a></th><td>core</td></tr></table>
|
||
<p>The <code><IfDefine <var>test</var>>...</IfDefine>
|
||
</code> section is used to mark directives that are conditional. The
|
||
directives within an <code class="directive"><IfDefine></code>
|
||
section are only processed if the <var>test</var> is true. If <var>
|
||
test</var> is false, everything between the start and end markers is
|
||
ignored.</p>
|
||
|
||
<p>The <var>test</var> in the <code class="directive"><IfDefine></code> section directive can be one of two forms:</p>
|
||
|
||
<ul>
|
||
<li><var>parameter-name</var></li>
|
||
|
||
<li><code>!</code><var>parameter-name</var></li>
|
||
</ul>
|
||
|
||
<p>In the former case, the directives between the start and end
|
||
markers are only processed if the parameter named
|
||
<var>parameter-name</var> is defined. The second format reverses
|
||
the test, and only processes the directives if
|
||
<var>parameter-name</var> is <strong>not</strong> defined.</p>
|
||
|
||
<p>The <var>parameter-name</var> argument is a define as given on
|
||
the <code>httpd</code> command line via <code>-D<var>parameter-</var>
|
||
</code>, at the time the server was started.</p>
|
||
|
||
<p><code class="directive"><IfDefine></code> sections are
|
||
nest-able, which can be used to implement simple
|
||
multiple-parameter tests. Example:</p>
|
||
|
||
<div class="example"><p><code>
|
||
httpd -DReverseProxy ...<br />
|
||
<br />
|
||
# httpd.conf<br />
|
||
<IfDefine ReverseProxy><br />
|
||
<span class="indent">
|
||
LoadModule rewrite_module modules/mod_rewrite.so<br />
|
||
LoadModule proxy_module modules/libproxy.so<br />
|
||
</span>
|
||
</IfDefine>
|
||
</code></p></div>
|
||
</div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div><div class="directive-section"><h2><a name="IfModule" id="IfModule"><IfModule></a> <a name="ifmodule" id="ifmodule">Directive</a></h2><table class="directive"><tr><th><a href="directive-dict.html#Description">Description:
|
||
</a></th><td>Encloses directives that are processed conditional on the
|
||
presence or absence of a specific module</td></tr><tr><th><a href="directive-dict.html#Syntax">Syntax:
|
||
</a></th><td><code><IfModule [!]<var>module-name</var>> ...
|
||
</IfModule></code></td></tr><tr><th><a href="directive-dict.html#Context">Context:
|
||
</a></th><td>server config, virtual host, directory, .htaccess</td></tr><tr><th><a href="directive-dict.html#Override">Override:
|
||
</a></th><td>All</td></tr><tr><th><a href="directive-dict.html#Status">Status:
|
||
</a></th><td>Core</td></tr><tr><th><a href="directive-dict.html#Module">Module:
|
||
</a></th><td>core</td></tr></table>
|
||
<p>The <code><IfModule <var>test</var>>...</IfModule></code>
|
||
section is used to mark directives that are conditional on the presence of a
|
||
specific module. The directives within an <code class="directive"><IfModule></code> section are only processed if the <var>test</var>
|
||
is true. If <var>test</var> is false, everything between the start and
|
||
end markers is ignored.</p>
|
||
|
||
<p>The <var>test</var> in the <code class="directive"><IfModule></code> section directive can be one of two forms:</p>
|
||
|
||
<ul>
|
||
<li><var>module name</var></li>
|
||
|
||
<li>!<var>module name</var></li>
|
||
</ul>
|
||
|
||
<p>In the former case, the directives between the start and end
|
||
markers are only processed if the module named <var>module
|
||
name</var> is included in Apache -- either compiled in or
|
||
dynamically loaded using <code class="directive"><a href="../mod/mod_so.html#loadmodule">LoadModule</a></code>. The second format reverses the test,
|
||
and only processes the directives if <var>module name</var> is
|
||
<strong>not</strong> included.</p>
|
||
|
||
<p>The <var>module name</var> argument is the file name of the
|
||
module, at the time it was compiled. For example,
|
||
<code>mod_rewrite.c</code>. If a module consists of several
|
||
source files, use the name of the file containing the string
|
||
<code>STANDARD20_MODULE_STUFF</code>.</p>
|
||
|
||
<p><code class="directive"><IfModule></code> sections are
|
||
nest-able, which can be used to implement simple multiple-module
|
||
tests.</p>
|
||
|
||
<div class="note">This section should only be used if you need to have one
|
||
configuration file that works whether or not a specific module
|
||
is available. In normal operation, directives need not be
|
||
placed in <code class="directive"><IfModule></code>
|
||
sections.</div>
|
||
</div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div><div class="directive-section"><h2><a name="Include" id="Include">Include</a> <a name="include" id="include">Directive</a></h2><table class="directive"><tr><th><a href="directive-dict.html#Description">Description:
|
||
</a></th><td>Includes other configuration files from within
|
||
the server configuration files</td></tr><tr><th><a href="directive-dict.html#Syntax">Syntax:
|
||
</a></th><td><code>Include <var>file-path</var>|<var>directory-path</var></code></td></tr><tr><th><a href="directive-dict.html#Context">Context:
|
||
</a></th><td>server config, virtual host, directory</td></tr><tr><th><a href="directive-dict.html#Status">Status:
|
||
</a></th><td>Core</td></tr><tr><th><a href="directive-dict.html#Module">Module:
|
||
</a></th><td>core</td></tr><tr><th><a href="directive-dict.html#Compatibility">Compatibility:
|
||
</a></th><td>Wildcard matching available in 2.0.41 and later</td></tr></table>
|
||
<p>This directive allows inclusion of other configuration files
|
||
from within the server configuration files.</p>
|
||
|
||
<p>Shell-style (fnmatch) wildcard characters can be used to
|
||
include several files at once, in alphabetical order. In
|
||
addition, if <code class="directive">Include</code> points to a directory,
|
||
rather than a file, Apache will read all files in that directory
|
||
and any subdirectory. But including entire directories is not
|
||
recommended, because it is easy to accidentally leave temporary
|
||
files in a directory that can cause <code>httpd</code> to
|
||
fail.</p>
|
||
|
||
<p>The file path specified may be a fully qualified path (i.e.
|
||
starting with a slash), or may be relative to the
|
||
<code class="directive"><a href="#serverroot">ServerRoot</a></code> directory.</p>
|
||
|
||
<p>Examples:</p>
|
||
|
||
<div class="example"><p><code>
|
||
Include /usr/local/apache2/conf/ssl.conf<br />
|
||
Include /usr/local/apache2/conf/vhosts/*.conf
|
||
</code></p></div>
|
||
|
||
<p>Or, providing paths relative to your <code class="directive"><a href="#serverroot">ServerRoot</a></code> directory:</p>
|
||
|
||
<div class="example"><p><code>
|
||
Include conf/ssl.conf<br />
|
||
Include conf/vhosts/*.conf
|
||
</code></p></div>
|
||
|
||
<p>Running <code>apachectl configtest</code> will give you a list
|
||
of the files that are being processed during the configuration
|
||
check:</p>
|
||
|
||
<div class="example"><p><code>
|
||
root@host# apachectl configtest<br />
|
||
Processing config file: /usr/local/apache2/conf/ssl.conf<br />
|
||
Processing config file: /usr/local/apache2/conf/vhosts/vhost1.conf<br />
|
||
Processing config file: /usr/local/apache2/conf/vhosts/vhost2.conf<br />
|
||
Syntax OK
|
||
</code></p></div>
|
||
<h3>See also</h3><ul><li><a href="../programs/apachectl.html">apachectl</a></li></ul></div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div><div class="directive-section"><h2><a name="KeepAlive" id="KeepAlive">KeepAlive</a> <a name="keepalive" id="keepalive">Directive</a></h2><table class="directive"><tr><th><a href="directive-dict.html#Description">Description:
|
||
</a></th><td>Enables HTTP persistent connections</td></tr><tr><th><a href="directive-dict.html#Syntax">Syntax:
|
||
</a></th><td><code>KeepAlive on|off</code></td></tr><tr><th><a href="directive-dict.html#Default">Default:
|
||
</a></th><td><code>KeepAlive On</code></td></tr><tr><th><a href="directive-dict.html#Context">Context:
|
||
</a></th><td>server config, virtual host</td></tr><tr><th><a href="directive-dict.html#Status">Status:
|
||
</a></th><td>Core</td></tr><tr><th><a href="directive-dict.html#Module">Module:
|
||
</a></th><td>core</td></tr></table>
|
||
<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>
|
||
<h3>See also</h3><ul><li><code class="directive"><a href="#maxkeepaliverequests">MaxKeepAliveRequests</a></code></li></ul></div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div><div class="directive-section"><h2><a name="KeepAliveTimeout" id="KeepAliveTimeout">KeepAliveTimeout</a> <a name="keepalivetimeout" id="keepalivetimeout">Directive</a></h2><table class="directive"><tr><th><a href="directive-dict.html#Description">Description:
|
||
</a></th><td>Amount of time the server will wait for subsequent
|
||
requests on a persistent connection</td></tr><tr><th><a href="directive-dict.html#Syntax">Syntax:
|
||
</a></th><td><code>KeepAliveTimeout <var>seconds</var></code></td></tr><tr><th><a href="directive-dict.html#Default">Default:
|
||
</a></th><td><code>KeepAliveTimeout 15</code></td></tr><tr><th><a href="directive-dict.html#Context">Context:
|
||
</a></th><td>server config, virtual host</td></tr><tr><th><a href="directive-dict.html#Status">Status:
|
||
</a></th><td>Core</td></tr><tr><th><a href="directive-dict.html#Module">Module:
|
||
</a></th><td>core</td></tr></table>
|
||
<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
|
||
<code class="directive"><a href="#timeout">Timeout</a></code> directive applies.</p>
|
||
|
||
<p>Setting <code class="directive">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>
|
||
</div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div><div class="directive-section"><h2><a name="Limit" id="Limit"><Limit></a> <a name="limit" id="limit">Directive</a></h2><table class="directive"><tr><th><a href="directive-dict.html#Description">Description:
|
||
</a></th><td>Restrict enclosed access controls to only certain HTTP
|
||
methods</td></tr><tr><th><a href="directive-dict.html#Syntax">Syntax:
|
||
</a></th><td><code><Limit <var>method</var> [<var>method</var>] ... > ...
|
||
</Limit></code></td></tr><tr><th><a href="directive-dict.html#Context">Context:
|
||
</a></th><td>server config, virtual host, directory, .htaccess</td></tr><tr><th><a href="directive-dict.html#Override">Override:
|
||
</a></th><td>All</td></tr><tr><th><a href="directive-dict.html#Status">Status:
|
||
</a></th><td>Core</td></tr><tr><th><a href="directive-dict.html#Module">Module:
|
||
</a></th><td>core</td></tr></table>
|
||
<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 class="directive"><Limit></code> section.</strong></p>
|
||
|
||
<p>The purpose of the <code class="directive"><Limit></code>
|
||
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 <code><Limit></code>
|
||
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>
|
||
|
||
<div class="example"><p><code>
|
||
<Limit POST PUT DELETE><br />
|
||
<span class="indent">
|
||
Require valid-user<br />
|
||
</span>
|
||
</Limit>
|
||
</code></p></div>
|
||
|
||
<p>The method names listed can be one or more of: <code>GET</code>,
|
||
<code>POST</code>, <code>PUT</code>, <code>DELETE</code>,
|
||
<code>CONNECT</code>, <code>OPTIONS</code>, <code>TRACE</code>,
|
||
<code>PATCH</code>, <code>PROPFIND</code>, <code>PROPPATCH</code>,
|
||
<code>MKCOL</code>, <code>COPY</code>, <code>MOVE</code>,
|
||
<code>LOCK</code>, and <code>UNLOCK</code>. <strong>The method name is
|
||
case-sensitive.</strong> If <code>GET</code> is used it will also
|
||
restrict <code>HEAD</code> requests.</p>
|
||
</div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div><div class="directive-section"><h2><a name="LimitExcept" id="LimitExcept"><LimitExcept></a> <a name="limitexcept" id="limitexcept">Directive</a></h2><table class="directive"><tr><th><a href="directive-dict.html#Description">Description:
|
||
</a></th><td>Restrict access controls to all HTTP methods
|
||
except the named ones</td></tr><tr><th><a href="directive-dict.html#Syntax">Syntax:
|
||
</a></th><td><code><LimitExcept <var>method</var> [<var>method</var>] ... > ...
|
||
</LimitExcept></code></td></tr><tr><th><a href="directive-dict.html#Context">Context:
|
||
</a></th><td>server config, virtual host, directory, .htaccess</td></tr><tr><th><a href="directive-dict.html#Override">Override:
|
||
</a></th><td>All</td></tr><tr><th><a href="directive-dict.html#Status">Status:
|
||
</a></th><td>Core</td></tr><tr><th><a href="directive-dict.html#Module">Module:
|
||
</a></th><td>core</td></tr></table>
|
||
<p><code class="directive"><LimitExcept></code> and
|
||
<code></LimitExcept></code> 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 <code class="directive"><a href="#limit"><Limit></a></code> section and can be used to control
|
||
both standard and nonstandard/unrecognized methods. See the
|
||
documentation for <code class="directive"><a href="#limit"><Limit></a></code> for more details.</p>
|
||
|
||
<p>For example:</p>
|
||
|
||
<div class="example"><p><code>
|
||
<LimitExcept POST GET><br />
|
||
<span class="indent">
|
||
Require valid-user<br />
|
||
</span>
|
||
<LimitExcept>
|
||
</code></p></div>
|
||
|
||
</div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div><div class="directive-section"><h2><a name="LimitRequestBody" id="LimitRequestBody">LimitRequestBody</a> <a name="limitrequestbody" id="limitrequestbody">Directive</a></h2><table class="directive"><tr><th><a href="directive-dict.html#Description">Description:
|
||
</a></th><td>Restricts the total size of the HTTP request body sent
|
||
from the client</td></tr><tr><th><a href="directive-dict.html#Syntax">Syntax:
|
||
</a></th><td><code>LimitRequestBody <var>bytes</var></code></td></tr><tr><th><a href="directive-dict.html#Default">Default:
|
||
</a></th><td><code>LimitRequestBody 0</code></td></tr><tr><th><a href="directive-dict.html#Context">Context:
|
||
</a></th><td>server config, virtual host, directory, .htaccess</td></tr><tr><th><a href="directive-dict.html#Override">Override:
|
||
</a></th><td>All</td></tr><tr><th><a href="directive-dict.html#Status">Status:
|
||
</a></th><td>Core</td></tr><tr><th><a href="directive-dict.html#Module">Module:
|
||
</a></th><td>core</td></tr></table>
|
||
<p>This directive specifies the number of <var>bytes</var> 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 <code class="directive">LimitRequestBody</code> 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>
|
||
|
||
<p>If, for example, you are permitting file upload to a particular
|
||
location, and wich to limit the size of the uploaded file to 100K,
|
||
you might use the following directive:</p>
|
||
|
||
<div class="example"><p><code>
|
||
LimitRequestBody 102400
|
||
</code></p></div>
|
||
|
||
</div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div><div class="directive-section"><h2><a name="LimitRequestFields" id="LimitRequestFields">LimitRequestFields</a> <a name="limitrequestfields" id="limitrequestfields">Directive</a></h2><table class="directive"><tr><th><a href="directive-dict.html#Description">Description:
|
||
</a></th><td>Limits the number of HTTP request header fields that
|
||
will be accepted from the client</td></tr><tr><th><a href="directive-dict.html#Syntax">Syntax:
|
||
</a></th><td><code>LimitRequestFields <var>number</var></code></td></tr><tr><th><a href="directive-dict.html#Default">Default:
|
||
</a></th><td><code>LimitRequestFields 100</code></td></tr><tr><th><a href="directive-dict.html#Context">Context:
|
||
</a></th><td>server config</td></tr><tr><th><a href="directive-dict.html#Status">Status:
|
||
</a></th><td>Core</td></tr><tr><th><a href="directive-dict.html#Module">Module:
|
||
</a></th><td>core</td></tr></table>
|
||
<p><var>Number</var> 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 <code class="directive">LimitRequestFields</code> 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>
|
||
|
||
<p>For example:</p>
|
||
|
||
<div class="example"><p><code>
|
||
LimitRequestFields 50
|
||
</code></p></div>
|
||
|
||
</div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div><div class="directive-section"><h2><a name="LimitRequestFieldSize" id="LimitRequestFieldSize">LimitRequestFieldSize</a> <a name="limitrequestfieldsize" id="limitrequestfieldsize">Directive</a></h2><table class="directive"><tr><th><a href="directive-dict.html#Description">Description:
|
||
</a></th><td>Limits the size of the HTTP request header allowed from the
|
||
client</td></tr><tr><th><a href="directive-dict.html#Syntax">Syntax:
|
||
</a></th><td><code>LimitRequestFieldsize <var>bytes</var></code></td></tr><tr><th><a href="directive-dict.html#Default">Default:
|
||
</a></th><td><code>LimitRequestFieldsize 8190</code></td></tr><tr><th><a href="directive-dict.html#Context">Context:
|
||
</a></th><td>server config</td></tr><tr><th><a href="directive-dict.html#Status">Status:
|
||
</a></th><td>Core</td></tr><tr><th><a href="directive-dict.html#Module">Module:
|
||
</a></th><td>core</td></tr></table>
|
||
<p>This directive specifies the number of <var>bytes</var> 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 <code class="directive">LimitRequestFieldsize</code> 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.</p>
|
||
|
||
<p>For example:</p>
|
||
|
||
<div class="example"><p><code>
|
||
LimitRequestFieldSize 16380
|
||
</code></p></div>
|
||
|
||
<div class="note">Under normal conditions, the value should not be changed from
|
||
the default.</div>
|
||
|
||
</div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div><div class="directive-section"><h2><a name="LimitRequestLine" id="LimitRequestLine">LimitRequestLine</a> <a name="limitrequestline" id="limitrequestline">Directive</a></h2><table class="directive"><tr><th><a href="directive-dict.html#Description">Description:
|
||
</a></th><td>Limit the size of the HTTP request line that will be accepted
|
||
from the client</td></tr><tr><th><a href="directive-dict.html#Syntax">Syntax:
|
||
</a></th><td><code>LimitRequestLine <var>bytes</var></code></td></tr><tr><th><a href="directive-dict.html#Default">Default:
|
||
</a></th><td><code>LimitRequestLine 8190</code></td></tr><tr><th><a href="directive-dict.html#Context">Context:
|
||
</a></th><td>server config</td></tr><tr><th><a href="directive-dict.html#Status">Status:
|
||
</a></th><td>Core</td></tr><tr><th><a href="directive-dict.html#Module">Module:
|
||
</a></th><td>core</td></tr></table>
|
||
<p>This directive sets the number of <var>bytes</var> 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 <code class="directive">LimitRequestLine</code> 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
|
||
<code class="directive">LimitRequestLine</code> 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.</p>
|
||
|
||
<p>For example:</p>
|
||
|
||
<div class="example"><p><code>
|
||
LimitRequestLine 16380
|
||
</code></p></div>
|
||
|
||
<div class="note">Under normal conditions, the value should not be changed from
|
||
the default.</div>
|
||
</div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div><div class="directive-section"><h2><a name="LimitXMLRequestBody" id="LimitXMLRequestBody">LimitXMLRequestBody</a> <a name="limitxmlrequestbody" id="limitxmlrequestbody">Directive</a></h2><table class="directive"><tr><th><a href="directive-dict.html#Description">Description:
|
||
</a></th><td>Limits the size of an XML-based request body</td></tr><tr><th><a href="directive-dict.html#Syntax">Syntax:
|
||
</a></th><td><code>LimitXMLRequestBody <var>number</var></code></td></tr><tr><th><a href="directive-dict.html#Default">Default:
|
||
</a></th><td><code>LimitXMLRequestBody 1000000</code></td></tr><tr><th><a href="directive-dict.html#Context">Context:
|
||
</a></th><td>server config, virtual host, directory, .htaccess</td></tr><tr><th><a href="directive-dict.html#Override">Override:
|
||
</a></th><td>All</td></tr><tr><th><a href="directive-dict.html#Status">Status:
|
||
</a></th><td>Core</td></tr><tr><th><a href="directive-dict.html#Module">Module:
|
||
</a></th><td>core</td></tr></table>
|
||
<p>Limit (in bytes) on maximum size of an XML-based request
|
||
body. A value of <code>0</code> will disable any checking.</p>
|
||
|
||
<p>Example:</p>
|
||
|
||
<div class="example"><p><code>
|
||
LimitXMLRequestBody 0
|
||
</code></p></div>
|
||
|
||
</div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div><div class="directive-section"><h2><a name="Location" id="Location"><Location></a> <a name="location" id="location">Directive</a></h2><table class="directive"><tr><th><a href="directive-dict.html#Description">Description:
|
||
</a></th><td>Applies the enclosed directives only to matching
|
||
URLs</td></tr><tr><th><a href="directive-dict.html#Syntax">Syntax:
|
||
</a></th><td><code><Location
|
||
URL-path|URL> ... </Location></code></td></tr><tr><th><a href="directive-dict.html#Context">Context:
|
||
</a></th><td>server config, virtual host</td></tr><tr><th><a href="directive-dict.html#Status">Status:
|
||
</a></th><td>Core</td></tr><tr><th><a href="directive-dict.html#Module">Module:
|
||
</a></th><td>core</td></tr></table>
|
||
<p>The <code class="directive"><Location></code> directive
|
||
provides for access control by URL. It is similar to the
|
||
<code class="directive"><a href="#directory"><Directory></a></code>
|
||
directive, and starts a subsection which is terminated with a
|
||
<code></Location></code> directive. <code class="directive"><Location></code> sections are processed in the
|
||
order they appear in the configuration file, after the <code class="directive"><a href="#directory"><Directory></a></code> sections and
|
||
<code>.htaccess</code> files are read, and after the <code class="directive"><a href="#files"><Files></a></code> 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 a
|
||
URL-path of the form <code>/path/</code>. No scheme, hostname,
|
||
port, or query string may be included. 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>Extended regular
|
||
expressions can also be used, with the addition of the
|
||
<code>~</code> character. For example:</p>
|
||
|
||
<div class="example"><p><code>
|
||
<Location ~ "/(extra|special)/data">
|
||
</code></p></div>
|
||
|
||
<p>would match URLs that contained the substring "/extra/data" or
|
||
"/special/data". In Apache 1.3 and above, a new directive
|
||
<code class="directive"><a href="#locationmatch"><LocationMatch></a></code>
|
||
exists which behaves identical to the regex version of
|
||
<code class="directive"><Location></code>.</p>
|
||
|
||
<p>The <code class="directive"><Location></code>
|
||
functionality is especially useful when combined with the
|
||
<code class="directive"><a href="#sethandler">SetHandler</a></code>
|
||
directive. For example, to enable status requests, but allow them
|
||
only from browsers at foo.com, you might use:</p>
|
||
|
||
<div class="example"><p><code>
|
||
<Location /status><br />
|
||
<span class="indent">
|
||
SetHandler server-status<br />
|
||
Order Deny,Allow<br />
|
||
Deny from all<br />
|
||
Allow from .foo.com<br />
|
||
</span>
|
||
</Location>
|
||
</code></p></div>
|
||
|
||
<div class="note"><h3>Note about / (slash)</h3>
|
||
<p>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 class="directive"><a href="#locationmatch"><LocationMatch></a></code>
|
||
directive and the regex version of <code class="directive"><Location></code> require you to explicitly specify multiple
|
||
slashes if that is your intention.</p>
|
||
|
||
<p>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 class="directive"><Location></code> directive behaves similarly when used for
|
||
proxy requests. But when (non-regex) <code class="directive"><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>
|
||
</div>
|
||
<h3>See also</h3><ul><li><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</li></ul></div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div><div class="directive-section"><h2><a name="LocationMatch" id="LocationMatch"><LocationMatch></a> <a name="locationmatch" id="locationmatch">Directive</a></h2><table class="directive"><tr><th><a href="directive-dict.html#Description">Description:
|
||
</a></th><td>Applies the enclosed directives only to regular-expression
|
||
matching URLs</td></tr><tr><th><a href="directive-dict.html#Syntax">Syntax:
|
||
</a></th><td><code><LocationMatch
|
||
<var>regex</var>> ... </LocationMatch></code></td></tr><tr><th><a href="directive-dict.html#Context">Context:
|
||
</a></th><td>server config, virtual host</td></tr><tr><th><a href="directive-dict.html#Status">Status:
|
||
</a></th><td>Core</td></tr><tr><th><a href="directive-dict.html#Module">Module:
|
||
</a></th><td>core</td></tr></table>
|
||
<p>The <code class="directive"><LocationMatch></code> directive
|
||
provides for access control by URL, in an identical manner to
|
||
<code class="directive"><a href="#location"><Location></a></code>. However,
|
||
it takes a regular expression as an argument instead of a simple
|
||
string. For example:</p>
|
||
|
||
<div class="example"><p><code>
|
||
<LocationMatch "/(extra|special)/data">
|
||
</code></p></div>
|
||
|
||
<p>would match URLs that contained the substring <code>/extra/data</code>
|
||
or <code>/special/data</code>.</p>
|
||
<h3>See also</h3><ul><li><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</li></ul></div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div><div class="directive-section"><h2><a name="LogLevel" id="LogLevel">LogLevel</a> <a name="loglevel" id="loglevel">Directive</a></h2><table class="directive"><tr><th><a href="directive-dict.html#Description">Description:
|
||
</a></th><td>Controls the verbosity of the ErrorLog</td></tr><tr><th><a href="directive-dict.html#Syntax">Syntax:
|
||
</a></th><td><code>LogLevel <var>level</var></code></td></tr><tr><th><a href="directive-dict.html#Default">Default:
|
||
</a></th><td><code>LogLevel warn</code></td></tr><tr><th><a href="directive-dict.html#Context">Context:
|
||
</a></th><td>server config, virtual host</td></tr><tr><th><a href="directive-dict.html#Status">Status:
|
||
</a></th><td>Core</td></tr><tr><th><a href="directive-dict.html#Module">Module:
|
||
</a></th><td>core</td></tr></table>
|
||
<p><code class="directive">LogLevel</code> adjusts the verbosity of the
|
||
messages recorded in the error logs (see <code class="directive"><a href="#errorlog">ErrorLog</a></code> directive). The following
|
||
<var>level</var>s are available, in order of decreasing
|
||
significance:</p>
|
||
|
||
<table class="bordered">
|
||
<tr>
|
||
<th><strong>Level</strong> </th>
|
||
|
||
<th><strong>Description</strong> </th>
|
||
|
||
<th><strong>Example</strong> </th>
|
||
</tr>
|
||
|
||
<tr>
|
||
<td><code>emerg</code> </td>
|
||
|
||
<td>Emergencies - system is unusable.</td>
|
||
|
||
<td>"Child cannot open lock file. Exiting"</td>
|
||
</tr>
|
||
|
||
<tr>
|
||
<td><code>alert</code> </td>
|
||
|
||
<td>Action must be taken immediately.</td>
|
||
|
||
<td>"getpwuid: couldn't determine user name from uid"</td>
|
||
</tr>
|
||
|
||
<tr>
|
||
<td><code>crit</code> </td>
|
||
|
||
<td>Critical Conditions.</td>
|
||
|
||
<td>"socket: Failed to get a socket, exiting child"</td>
|
||
</tr>
|
||
|
||
<tr>
|
||
<td><code>error</code> </td>
|
||
|
||
<td>Error conditions.</td>
|
||
|
||
<td>"Premature end of script headers"</td>
|
||
</tr>
|
||
|
||
<tr>
|
||
<td><code>warn</code> </td>
|
||
|
||
<td>Warning conditions.</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>
|
||
|
||
<td>"httpd: caught SIGBUS, attempting to dump core in
|
||
..."</td>
|
||
</tr>
|
||
|
||
<tr>
|
||
<td><code>info</code> </td>
|
||
|
||
<td>Informational.</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>
|
||
|
||
<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>
|
||
|
||
<p>For example:</p>
|
||
|
||
<div class="example"><p><code>
|
||
LogLevel notice
|
||
</code></p></div>
|
||
</div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div><div class="directive-section"><h2><a name="MaxKeepAliveRequests" id="MaxKeepAliveRequests">MaxKeepAliveRequests</a> <a name="maxkeepaliverequests" id="maxkeepaliverequests">Directive</a></h2><table class="directive"><tr><th><a href="directive-dict.html#Description">Description:
|
||
</a></th><td>Number of requests allowed on a persistent
|
||
connection</td></tr><tr><th><a href="directive-dict.html#Syntax">Syntax:
|
||
</a></th><td><code>MaxKeepAliveRequests <var>number</var></code></td></tr><tr><th><a href="directive-dict.html#Default">Default:
|
||
</a></th><td><code>MaxKeepAliveRequests 100</code></td></tr><tr><th><a href="directive-dict.html#Context">Context:
|
||
</a></th><td>server config, virtual host</td></tr><tr><th><a href="directive-dict.html#Status">Status:
|
||
</a></th><td>Core</td></tr><tr><th><a href="directive-dict.html#Module">Module:
|
||
</a></th><td>core</td></tr></table>
|
||
<p>The <code class="directive">MaxKeepAliveRequests</code> directive
|
||
limits the number of requests allowed per connection when
|
||
<code class="directive"><a href="#keepalive">KeepAlive</a></code> 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>
|
||
|
||
<p>For example:</p>
|
||
|
||
<div class="example"><p><code>
|
||
MaxKeepAliveRequests 500
|
||
</code></p></div>
|
||
</div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div><div class="directive-section"><h2><a name="NameVirtualHost" id="NameVirtualHost">NameVirtualHost</a> <a name="namevirtualhost" id="namevirtualhost">Directive</a></h2><table class="directive"><tr><th><a href="directive-dict.html#Description">Description:
|
||
</a></th><td>Designates an IP address for name-virtual
|
||
hosting</td></tr><tr><th><a href="directive-dict.html#Syntax">Syntax:
|
||
</a></th><td><code>NameVirtualHost <var>addr</var>[:<var>port</var>]</code></td></tr><tr><th><a href="directive-dict.html#Context">Context:
|
||
</a></th><td>server config</td></tr><tr><th><a href="directive-dict.html#Status">Status:
|
||
</a></th><td>Core</td></tr><tr><th><a href="directive-dict.html#Module">Module:
|
||
</a></th><td>core</td></tr></table>
|
||
<p>The <code class="directive">NameVirtualHost</code> directive is a
|
||
required directive if you want to configure <a href="../vhosts/">name-based virtual hosts</a>.</p>
|
||
|
||
<p>Although <var>addr</var> can be hostname it is recommended
|
||
that you always use an IP address, e.g.</p>
|
||
|
||
<div class="example"><p><code>
|
||
NameVirtualHost 111.22.33.44
|
||
</code></p></div>
|
||
|
||
<p>With the <code class="directive">NameVirtualHost</code> 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>
|
||
|
||
<p>Note: the "main server" and any _default_ servers will
|
||
<strong>never</strong> be served for a request to a
|
||
<code class="directive">NameVirtualHost</code> IP Address (unless for some
|
||
reason you specify <code class="directive">NameVirtualHost</code> 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, e.g.</p>
|
||
|
||
<div class="example"><p><code>
|
||
NameVirtualHost 111.22.33.44:8080
|
||
</code></p></div>
|
||
|
||
<p>IPv6 addresses must be enclosed in square brackets, as shown
|
||
in the following example:</p>
|
||
|
||
<div class="example"><p><code>
|
||
NameVirtualHost [fe80::a00:20ff:fea7:ccea]:8080
|
||
</code></p></div>
|
||
|
||
<p>To receive requests on all interfaces, you can use an argument of
|
||
*</p>
|
||
|
||
<div class="example"><p><code>
|
||
NameVirtualHost *
|
||
</code></p></div>
|
||
|
||
<div class="note"><h3>Argument to <VirtualHost> directive</h3>
|
||
<p>Note that the argument to the <VirtualHost> directive must
|
||
exactly match the argument to the <code class="directive">NameVirtualHost</code> directive.</p>
|
||
|
||
<div class="example"><p><code>
|
||
NameVirtualHost 1.2.3.4<br />
|
||
<VirtualHost 1.2.3.4><br />
|
||
# ...<br />
|
||
</VirtualHost><br />
|
||
</code></p></div>
|
||
</div>
|
||
<h3>See also</h3><ul><li><a href="../vhosts/">Virtual Hosts
|
||
documentation</a></li></ul></div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div><div class="directive-section"><h2><a name="Options" id="Options">Options</a> <a name="options" id="options">Directive</a></h2><table class="directive"><tr><th><a href="directive-dict.html#Description">Description:
|
||
</a></th><td>Configures what features are available in a particular
|
||
directory</td></tr><tr><th><a href="directive-dict.html#Syntax">Syntax:
|
||
</a></th><td><code>Options
|
||
[+|-]<var>option</var> [[+|-]<var>option</var>] ...</code></td></tr><tr><th><a href="directive-dict.html#Default">Default:
|
||
</a></th><td><code>Options All</code></td></tr><tr><th><a href="directive-dict.html#Context">Context:
|
||
</a></th><td>server config, virtual host, directory, .htaccess</td></tr><tr><th><a href="directive-dict.html#Override">Override:
|
||
</a></th><td>Options</td></tr><tr><th><a href="directive-dict.html#Status">Status:
|
||
</a></th><td>Core</td></tr><tr><th><a href="directive-dict.html#Module">Module:
|
||
</a></th><td>core</td></tr></table>
|
||
<p>The <code class="directive">Options</code> directive controls which
|
||
server features are available in a particular directory.</p>
|
||
|
||
<p><var>option</var> 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>
|
||
Execution of CGI scripts is permitted.</dd>
|
||
|
||
<dt>FollowSymLinks</dt>
|
||
|
||
<dd>
|
||
|
||
The server will follow symbolic links in this directory.
|
||
<div class="note">
|
||
<p>Even though the server follows the symlink it does <em>not</em>
|
||
change the pathname used to match against <code class="directive"><a href="#directory"><Directory></a></code> sections.</p>
|
||
<p>Note also, that this option <strong>gets ignored</strong> if set
|
||
inside a <code class="directive"><a href="#location"><Location></a></code>
|
||
section.</p>
|
||
</div></dd>
|
||
|
||
<dt>Includes</dt>
|
||
|
||
<dd>
|
||
Server-side includes are permitted.</dd>
|
||
|
||
<dt>IncludesNOEXEC</dt>
|
||
|
||
<dd>
|
||
|
||
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>
|
||
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>
|
||
<a href="../content-negotiation.html">Content negotiated</a>
|
||
MultiViews are allowed.</dd>
|
||
|
||
<dt>SymLinksIfOwnerMatch</dt>
|
||
|
||
<dd>
|
||
|
||
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 <code class="directive"><a href="#location"><Location></a></code>
|
||
section.</dd>
|
||
</dl>
|
||
<p>Normally, if multiple <code class="directive">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 class="directive">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>
|
||
|
||
<p>For example, without any + and - symbols:</p>
|
||
|
||
<div class="example"><p><code>
|
||
<Directory /web/docs><br />
|
||
<span class="indent">
|
||
Options Indexes FollowSymLinks<br />
|
||
</span>
|
||
</Directory><br />
|
||
<br />
|
||
<Directory /web/docs/spec><br />
|
||
<span class="indent">
|
||
Options Includes<br />
|
||
</span>
|
||
</Directory>
|
||
</code></p></div>
|
||
|
||
<p>then only <code>Includes</code> will be set for the
|
||
/web/docs/spec directory. However if the second
|
||
<code class="directive">Options</code> directive uses the + and - symbols:</p>
|
||
|
||
<div class="example"><p><code>
|
||
<Directory /web/docs><br />
|
||
<span class="indent">
|
||
Options Indexes FollowSymLinks<br />
|
||
</span>
|
||
</Directory><br />
|
||
<br />
|
||
<Directory /web/docs/spec><br />
|
||
<span class="indent">
|
||
Options +Includes -Indexes<br />
|
||
</span>
|
||
</Directory>
|
||
</code></p></div>
|
||
|
||
<p>then the options <code>FollowSymLinks</code> and
|
||
<code>Includes</code> are set for the /web/docs/spec directory.</p>
|
||
|
||
|
||
<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>
|
||
</div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div><div class="directive-section"><h2><a name="Require" id="Require">Require</a> <a name="require" id="require">Directive</a></h2><table class="directive"><tr><th><a href="directive-dict.html#Description">Description:
|
||
</a></th><td>Selects which authenticated users can access
|
||
a resource</td></tr><tr><th><a href="directive-dict.html#Syntax">Syntax:
|
||
</a></th><td><code>Require <var>entity-name</var> [<var>entity-name</var>] ...</code></td></tr><tr><th><a href="directive-dict.html#Context">Context:
|
||
</a></th><td>directory, .htaccess</td></tr><tr><th><a href="directive-dict.html#Override">Override:
|
||
</a></th><td>AuthConfig</td></tr><tr><th><a href="directive-dict.html#Status">Status:
|
||
</a></th><td>Core</td></tr><tr><th><a href="directive-dict.html#Module">Module:
|
||
</a></th><td>core</td></tr></table>
|
||
<p>This directive selects which authenticated users can access
|
||
a directory. The allowed syntaxes are:</p>
|
||
|
||
<ul>
|
||
<li>
|
||
Require user <var>userid</var> [<var>userid</var>] ...
|
||
|
||
<p>Only the named users can access the directory.</p>
|
||
</li>
|
||
|
||
<li>
|
||
Require group <var>group-name</var> [<var>group-name</var>] ...
|
||
|
||
|
||
<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><code class="directive">Require</code> must be accompanied by
|
||
<code class="directive"><a href="#authname">AuthName</a></code> and <code class="directive"><a href="#authtype">AuthType</a></code> directives, and directives such
|
||
as <code class="directive"><a href="../mod/mod_authn_file.html#authuserfile">AuthUserFile</a></code>
|
||
and <code class="directive"><a href="../mod/mod_authz_groupfile.html#authgroupfile">AuthGroupFile</a></code> (to
|
||
define users and groups) in order to work correctly. Example:</p>
|
||
|
||
<div class="example"><p><code>
|
||
AuthType Basic<br />
|
||
AuthName "Restricted Directory"<br />
|
||
AuthUserFile /web/users<br />
|
||
AuthGroupFile /web/groups<br />
|
||
Require group admin
|
||
</code></p></div>
|
||
|
||
<p>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 class="directive">Require</code> statement into a
|
||
<code class="directive"><a href="#limit"><Limit></a></code>
|
||
section.</p>
|
||
<h3>See also</h3><ul><li><code class="directive"><a href="#satisfy">Satisfy</a></code></li><li><code class="module"><a href="../mod/mod_authz_host.html">mod_authz_host</a></code></li></ul></div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div><div class="directive-section"><h2><a name="RLimitCPU" id="RLimitCPU">RLimitCPU</a> <a name="rlimitcpu" id="rlimitcpu">Directive</a></h2><table class="directive"><tr><th><a href="directive-dict.html#Description">Description:
|
||
</a></th><td>Limits the CPU consumption of processes launched
|
||
by Apache children</td></tr><tr><th><a href="directive-dict.html#Syntax">Syntax:
|
||
</a></th><td><code>RLimitCPU <var>number</var>|max [<var>number</var>|max]</code></td></tr><tr><th><a href="directive-dict.html#Default">Default:
|
||
</a></th><td><code>Unset; uses operating system defaults</code></td></tr><tr><th><a href="directive-dict.html#Context">Context:
|
||
</a></th><td>server config, virtual host, directory, .htaccess</td></tr><tr><th><a href="directive-dict.html#Override">Override:
|
||
</a></th><td>All</td></tr><tr><th><a href="directive-dict.html#Status">Status:
|
||
</a></th><td>Core</td></tr><tr><th><a href="directive-dict.html#Module">Module:
|
||
</a></th><td>core</td></tr></table>
|
||
<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>CPU resource limits are expressed in seconds per
|
||
process.</p>
|
||
<h3>See also</h3><ul><li><code class="directive"><a href="#rlimitmem">RLimitMEM</a></code></li><li><code class="directive"><a href="#rlimitnproc">RLimitNPROC</a></code></li></ul></div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div><div class="directive-section"><h2><a name="RLimitMEM" id="RLimitMEM">RLimitMEM</a> <a name="rlimitmem" id="rlimitmem">Directive</a></h2><table class="directive"><tr><th><a href="directive-dict.html#Description">Description:
|
||
</a></th><td>Limits the memory consumption of processes launched
|
||
by Apache children</td></tr><tr><th><a href="directive-dict.html#Syntax">Syntax:
|
||
</a></th><td><code>RLimitMEM <var>number</var>|max [<var>number</var>|max]</code></td></tr><tr><th><a href="directive-dict.html#Default">Default:
|
||
</a></th><td><code>Unset; uses operating system defaults</code></td></tr><tr><th><a href="directive-dict.html#Context">Context:
|
||
</a></th><td>server config, virtual host, directory, .htaccess</td></tr><tr><th><a href="directive-dict.html#Override">Override:
|
||
</a></th><td>All</td></tr><tr><th><a href="directive-dict.html#Status">Status:
|
||
</a></th><td>Core</td></tr><tr><th><a href="directive-dict.html#Module">Module:
|
||
</a></th><td>core</td></tr></table>
|
||
<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>Memory resource limits are expressed in bytes per
|
||
process.</p>
|
||
<h3>See also</h3><ul><li><code class="directive"><a href="#rlimitcpu">RLimitCPU</a></code></li><li><code class="directive"><a href="#rlimitnproc">RLimitNPROC</a></code></li></ul></div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div><div class="directive-section"><h2><a name="RLimitNPROC" id="RLimitNPROC">RLimitNPROC</a> <a name="rlimitnproc" id="rlimitnproc">Directive</a></h2><table class="directive"><tr><th><a href="directive-dict.html#Description">Description:
|
||
</a></th><td>Limits the number of processes that can be launched by
|
||
processes launched by Apache children</td></tr><tr><th><a href="directive-dict.html#Syntax">Syntax:
|
||
</a></th><td><code>RLimitNPROC <var>number</var>|max [<var>number</var>|max]</code></td></tr><tr><th><a href="directive-dict.html#Default">Default:
|
||
</a></th><td><code>Unset; uses operating system defaults</code></td></tr><tr><th><a href="directive-dict.html#Context">Context:
|
||
</a></th><td>server config, virtual host, directory, .htaccess</td></tr><tr><th><a href="directive-dict.html#Override">Override:
|
||
</a></th><td>All</td></tr><tr><th><a href="directive-dict.html#Status">Status:
|
||
</a></th><td>Core</td></tr><tr><th><a href="directive-dict.html#Module">Module:
|
||
</a></th><td>core</td></tr></table>
|
||
<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><code>cannot fork</code></strong> messages in the
|
||
error_log.</p>
|
||
<h3>See also</h3><ul><li><code class="directive"><a href="#rlimitmem">RLimitMEM</a></code></li><li><code class="directive"><a href="#rlimitcpu">RLimitCPU</a></code></li></ul></div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div><div class="directive-section"><h2><a name="Satisfy" id="Satisfy">Satisfy</a> <a name="satisfy" id="satisfy">Directive</a></h2><table class="directive"><tr><th><a href="directive-dict.html#Description">Description:
|
||
</a></th><td>Interaction between host-level access control and
|
||
user authentication</td></tr><tr><th><a href="directive-dict.html#Syntax">Syntax:
|
||
</a></th><td><code>Satisfy any|all</code></td></tr><tr><th><a href="directive-dict.html#Default">Default:
|
||
</a></th><td><code>Satisfy all</code></td></tr><tr><th><a href="directive-dict.html#Context">Context:
|
||
</a></th><td>directory, .htaccess</td></tr><tr><th><a href="directive-dict.html#Override">Override:
|
||
</a></th><td>AuthConfig</td></tr><tr><th><a href="directive-dict.html#Status">Status:
|
||
</a></th><td>Core</td></tr><tr><th><a href="directive-dict.html#Module">Module:
|
||
</a></th><td>core</td></tr></table>
|
||
<p>Access policy if both <code class="directive"><a href="../mod/mod_authz_host.html#allow">Allow</a></code> and <code class="directive"><a href="#require">Require</a></code> used. The parameter can be
|
||
either <var>all</var> or <var>any</var>. 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 (<var>all</var>) 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>For example, if you wanted to let people on your network have
|
||
unrestricted access to a portion of your website, but require that
|
||
people outside of your network provide a password, you could use a
|
||
configuration similar to the following:</p>
|
||
|
||
<div class="example"><p><code>
|
||
Require valid-user<br />
|
||
Allow from 192.168.1<br />
|
||
Satisfy any
|
||
</code></p></div>
|
||
|
||
<h3>See also</h3><ul><li><code class="directive"><a href="../mod/mod_authz_host.html#allow">Allow</a></code></li><li><code class="directive"><a href="#require">Require</a></code></li></ul></div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div><div class="directive-section"><h2><a name="ScriptInterpreterSource" id="ScriptInterpreterSource">ScriptInterpreterSource</a> <a name="scriptinterpretersource" id="scriptinterpretersource">Directive</a></h2><table class="directive"><tr><th><a href="directive-dict.html#Description">Description:
|
||
</a></th><td>Technique for locating the interpreter for CGI
|
||
scripts</td></tr><tr><th><a href="directive-dict.html#Syntax">Syntax:
|
||
</a></th><td><code>ScriptInterpreterSource registry|script</code></td></tr><tr><th><a href="directive-dict.html#Default">Default:
|
||
</a></th><td><code>ScriptInterpreterSource script</code></td></tr><tr><th><a href="directive-dict.html#Context">Context:
|
||
</a></th><td>server config, virtual host, directory, .htaccess</td></tr><tr><th><a href="directive-dict.html#Override">Override:
|
||
</a></th><td>FileInfo</td></tr><tr><th><a href="directive-dict.html#Status">Status:
|
||
</a></th><td>Core</td></tr><tr><th><a href="directive-dict.html#Module">Module:
|
||
</a></th><td>core</td></tr><tr><th><a href="directive-dict.html#Compatibility">Compatibility:
|
||
</a></th><td>Win32 only</td></tr></table>
|
||
<p>This directive is used to control how Apache 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 <code>ScriptInterpreterSource registry</code> will
|
||
cause the Windows Registry to be searched using the script file
|
||
extension (e.g., .pl) as a search key.</p>
|
||
</div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div><div class="directive-section"><h2><a name="ServerAdmin" id="ServerAdmin">ServerAdmin</a> <a name="serveradmin" id="serveradmin">Directive</a></h2><table class="directive"><tr><th><a href="directive-dict.html#Description">Description:
|
||
</a></th><td>Email address that the server includes in error
|
||
messages sent to the client</td></tr><tr><th><a href="directive-dict.html#Syntax">Syntax:
|
||
</a></th><td><code>ServerAdmin <var>email-address</var></code></td></tr><tr><th><a href="directive-dict.html#Context">Context:
|
||
</a></th><td>server config, virtual host</td></tr><tr><th><a href="directive-dict.html#Status">Status:
|
||
</a></th><td>Core</td></tr><tr><th><a href="directive-dict.html#Module">Module:
|
||
</a></th><td>core</td></tr></table>
|
||
<p>The <code class="directive">ServerAdmin</code> 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, e.g.</p>
|
||
|
||
<div class="example"><p><code>
|
||
ServerAdmin www-admin@foo.example.com
|
||
</code></p></div>
|
||
<p>as users do not always mention that they are talking about the
|
||
server!</p>
|
||
</div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div><div class="directive-section"><h2><a name="ServerAlias" id="ServerAlias">ServerAlias</a> <a name="serveralias" id="serveralias">Directive</a></h2><table class="directive"><tr><th><a href="directive-dict.html#Description">Description:
|
||
</a></th><td>Alternate names for a host used when matching requests
|
||
to name-virtual hosts</td></tr><tr><th><a href="directive-dict.html#Syntax">Syntax:
|
||
</a></th><td><code>ServerAlias <var>hostname</var> [<var>hostname</var>] ...</code></td></tr><tr><th><a href="directive-dict.html#Context">Context:
|
||
</a></th><td>virtual host</td></tr><tr><th><a href="directive-dict.html#Status">Status:
|
||
</a></th><td>Core</td></tr><tr><th><a href="directive-dict.html#Module">Module:
|
||
</a></th><td>core</td></tr></table>
|
||
<p>The <code class="directive">ServerAlias</code> directive sets the
|
||
alternate names for a host, for use with <a href="../vhosts/name-based.html">name-based virtual hosts</a>.</p>
|
||
|
||
<div class="example"><p><code>
|
||
<VirtualHost *><br />
|
||
ServerName server.domain.com<br />
|
||
ServerAlias server server2.domain.com server2<br />
|
||
# ...<br />
|
||
</VirtualHost>
|
||
</code></p></div>
|
||
<h3>See also</h3><ul><li><a href="../vhosts/">Apache Virtual Host documentation</a></li></ul></div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div><div class="directive-section"><h2><a name="ServerName" id="ServerName">ServerName</a> <a name="servername" id="servername">Directive</a></h2><table class="directive"><tr><th><a href="directive-dict.html#Description">Description:
|
||
</a></th><td>Hostname and port that the server uses to identify
|
||
itself</td></tr><tr><th><a href="directive-dict.html#Syntax">Syntax:
|
||
</a></th><td><code>ServerName <var>fully-qualified-domain-name</var>[:<var>port</var>]</code></td></tr><tr><th><a href="directive-dict.html#Context">Context:
|
||
</a></th><td>server config, virtual host</td></tr><tr><th><a href="directive-dict.html#Status">Status:
|
||
</a></th><td>Core</td></tr><tr><th><a href="directive-dict.html#Module">Module:
|
||
</a></th><td>core</td></tr><tr><th><a href="directive-dict.html#Compatibility">Compatibility:
|
||
</a></th><td>In version 2.0, this
|
||
directive supersedes the functionality of the Port
|
||
directive from version 1.3.</td></tr></table>
|
||
<p>The <code class="directive">ServerName</code> directive sets the hostname and
|
||
port that the server uses to identify itself. This is used when
|
||
creating redirection URLs. For example, if the name of the
|
||
machine hosting the webserver is <code>simple.example.com</code>,
|
||
but the machine also has the DNS alias <code>www.example.com</code>
|
||
and you wish the webserver to be so identified, the following
|
||
directive should be used:</p>
|
||
|
||
<div class="example"><p><code>
|
||
ServerName www.example.com:80
|
||
</code></p></div>
|
||
|
||
<p>If no <code class="directive">ServerName</code> is specified, then the
|
||
server attempts to deduce the hostname by performing a reverse
|
||
lookup on the IP address. If no port is specified in the
|
||
servername, then the server will use the port from the incoming
|
||
request. For optimal reliability and predictability, you should
|
||
specify an explicit hostname and port using the
|
||
<code class="directive">ServerName</code> directive.</p>
|
||
|
||
<p>If you are using <a href="../vhosts/name-based.html">name-based virtual hosts</a>,
|
||
the <code class="directive">ServerName</code> inside a
|
||
<code class="directive"><a href="#virtualhost"><VirtualHost></a></code>
|
||
section specifies what hostname must appear in the request's
|
||
<code>Host:</code> header to match this virtual host.</p>
|
||
|
||
<p>See the description of the
|
||
<code class="directive"><a href="#usecanonicalname">UseCanonicalName</a></code> directive for
|
||
settings which determine whether self-referential URL's (e.g., by the
|
||
<code class="module"><a href="../mod/mod_dir.html">mod_dir</a></code> module) will refer to the
|
||
specified port, or to the port number given in the client's request.
|
||
</p>
|
||
<h3>See also</h3><ul><li><a href="../dns-caveats.html">DNS Issues</a></li><li><a href="../vhosts/">Apache virtual host
|
||
documentation</a></li><li><code class="directive"><a href="#usecanonicalname">UseCanonicalName</a></code></li><li><code class="directive"><a href="#namevirtualhost">NameVirtualHost</a></code></li><li><code class="directive"><a href="#serveralias">ServerAlias</a></code></li></ul></div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div><div class="directive-section"><h2><a name="ServerPath" id="ServerPath">ServerPath</a> <a name="serverpath" id="serverpath">Directive</a></h2><table class="directive"><tr><th><a href="directive-dict.html#Description">Description:
|
||
</a></th><td>Legacy URL pathname for a name-virtual host that
|
||
is accessed by an incompatible browser</td></tr><tr><th><a href="directive-dict.html#Syntax">Syntax:
|
||
</a></th><td><code>ServerPath <var>URL-path</var></code></td></tr><tr><th><a href="directive-dict.html#Context">Context:
|
||
</a></th><td>virtual host</td></tr><tr><th><a href="directive-dict.html#Status">Status:
|
||
</a></th><td>Core</td></tr><tr><th><a href="directive-dict.html#Module">Module:
|
||
</a></th><td>core</td></tr></table>
|
||
<p>The <code class="directive">ServerPath</code> directive sets the legacy
|
||
URL pathname for a host, for use with <a href="../vhosts/">name-based virtual hosts</a>.</p>
|
||
<h3>See also</h3><ul><li><a href="../vhosts/">Apache Virtual Host documentation</a></li></ul></div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div><div class="directive-section"><h2><a name="ServerRoot" id="ServerRoot">ServerRoot</a> <a name="serverroot" id="serverroot">Directive</a></h2><table class="directive"><tr><th><a href="directive-dict.html#Description">Description:
|
||
</a></th><td>Base directory for the server installation</td></tr><tr><th><a href="directive-dict.html#Syntax">Syntax:
|
||
</a></th><td><code>ServerRoot <var>directory-path</var></code></td></tr><tr><th><a href="directive-dict.html#Default">Default:
|
||
</a></th><td><code>ServerRoot /usr/local/apache</code></td></tr><tr><th><a href="directive-dict.html#Context">Context:
|
||
</a></th><td>server config</td></tr><tr><th><a href="directive-dict.html#Status">Status:
|
||
</a></th><td>Core</td></tr><tr><th><a href="directive-dict.html#Module">Module:
|
||
</a></th><td>core</td></tr></table>
|
||
<p>The <code class="directive">ServerRoot</code> 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>
|
||
|
||
<div class="example"><h3>Example</h3><p><code>
|
||
ServerRoot /home/httpd
|
||
</code></p></div>
|
||
|
||
<h3>See also</h3><ul><li><a href="../invoking.html">the <code>-d</code>
|
||
option to <code>httpd</code></a></li><li><a href="../misc/security_tips.html#serverroot">the
|
||
security tips</a> for information on how to properly set
|
||
permissions on the ServerRoot</li></ul></div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div><div class="directive-section"><h2><a name="ServerSignature" id="ServerSignature">ServerSignature</a> <a name="serversignature" id="serversignature">Directive</a></h2><table class="directive"><tr><th><a href="directive-dict.html#Description">Description:
|
||
</a></th><td>Configures the footer on server-generated documents</td></tr><tr><th><a href="directive-dict.html#Syntax">Syntax:
|
||
</a></th><td><code>ServerSignature On|Off|EMail</code></td></tr><tr><th><a href="directive-dict.html#Default">Default:
|
||
</a></th><td><code>ServerSignature Off</code></td></tr><tr><th><a href="directive-dict.html#Context">Context:
|
||
</a></th><td>server config, virtual host, directory, .htaccess</td></tr><tr><th><a href="directive-dict.html#Override">Override:
|
||
</a></th><td>All</td></tr><tr><th><a href="directive-dict.html#Status">Status:
|
||
</a></th><td>Core</td></tr><tr><th><a href="directive-dict.html#Module">Module:
|
||
</a></th><td>core</td></tr></table>
|
||
<p>The <code class="directive">ServerSignature</code> 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 <code>Off</code>
|
||
setting, which is the default, suppresses the error line (and is
|
||
therefore compatible with the behavior of Apache-1.2 and
|
||
below). The <code>On</code> setting simply adds a line with the
|
||
server version number and <code class="directive"><a href="#servername">ServerName</a></code> of the serving virtual host,
|
||
and the <code>EMail</code> setting additionally creates a
|
||
"mailto:" reference to the <code class="directive"><a href="#serveradmin">ServerAdmin</a></code> of the referenced
|
||
document.</p>
|
||
|
||
<p>After version 2.0.44, the details of the server version number
|
||
presented are controlled by the <code class="directive"><a href="#servertokens">ServerTokens</a></code> directive.</p>
|
||
<h3>See also</h3><ul><li><code class="directive"><a href="#servertokens">ServerTokens</a></code></li></ul></div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div><div class="directive-section"><h2><a name="ServerTokens" id="ServerTokens">ServerTokens</a> <a name="servertokens" id="servertokens">Directive</a></h2><table class="directive"><tr><th><a href="directive-dict.html#Description">Description:
|
||
</a></th><td>Configures the Server HTTP response header</td></tr><tr><th><a href="directive-dict.html#Syntax">Syntax:
|
||
</a></th><td><code>ServerTokens Major|Minor|Minimal|ProductOnly|OS|Full</code></td></tr><tr><th><a href="directive-dict.html#Default">Default:
|
||
</a></th><td><code>ServerTokens Full</code></td></tr><tr><th><a href="directive-dict.html#Context">Context:
|
||
</a></th><td>server config</td></tr><tr><th><a href="directive-dict.html#Status">Status:
|
||
</a></th><td>Core</td></tr><tr><th><a href="directive-dict.html#Module">Module:
|
||
</a></th><td>core</td></tr></table>
|
||
<p>This directive controls whether <code>Server</code> 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>): <code>Server:
|
||
Apache</code></dd>
|
||
|
||
<dt><code>ServerTokens Major</code></dt>
|
||
|
||
<dd>Server sends (<em>e.g.</em>): <code>Server:
|
||
Apache/2</code></dd>
|
||
|
||
<dt><code>ServerTokens Minor</code></dt>
|
||
|
||
<dd>Server sends (<em>e.g.</em>): <code>Server:
|
||
Apache/2.0</code></dd>
|
||
|
||
<dt><code>ServerTokens Min[imal]</code></dt>
|
||
|
||
<dd>Server sends (<em>e.g.</em>): <code>Server:
|
||
Apache/2.0.41</code></dd>
|
||
|
||
<dt><code>ServerTokens OS</code></dt>
|
||
|
||
<dd>Server sends (<em>e.g.</em>): <code>Server: Apache/2.0.41
|
||
(Unix)</code></dd>
|
||
|
||
<dt><code>ServerTokens Full</code> (or not specified)</dt>
|
||
|
||
<dd>Server sends (<em>e.g.</em>): <code>Server: Apache/2.0.41
|
||
(Unix) PHP/4.2.2 MyMod/1.2</code></dd>
|
||
</dl>
|
||
|
||
<p>This setting applies to the entire server, and cannot be
|
||
enabled or disabled on a virtualhost-by-virtualhost basis.</p>
|
||
|
||
<p>After version 2.0.44, this directive also controls the
|
||
information presented by the <code class="directive"><a href="#serversignature">ServerSignature</a></code> directive.</p>
|
||
<h3>See also</h3><ul><li><code class="directive"><a href="#serversignature">ServerSignature</a></code></li></ul></div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div><div class="directive-section"><h2><a name="SetHandler" id="SetHandler">SetHandler</a> <a name="sethandler" id="sethandler">Directive</a></h2><table class="directive"><tr><th><a href="directive-dict.html#Description">Description:
|
||
</a></th><td>Forces all matching files to be processed by a
|
||
handler</td></tr><tr><th><a href="directive-dict.html#Syntax">Syntax:
|
||
</a></th><td><code>SetHandler <var>handler-name</var>|none</code></td></tr><tr><th><a href="directive-dict.html#Context">Context:
|
||
</a></th><td>server config, virtual host, directory, .htaccess</td></tr><tr><th><a href="directive-dict.html#Override">Override:
|
||
</a></th><td>FileInfo</td></tr><tr><th><a href="directive-dict.html#Status">Status:
|
||
</a></th><td>Core</td></tr><tr><th><a href="directive-dict.html#Module">Module:
|
||
</a></th><td>core</td></tr><tr><th><a href="directive-dict.html#Compatibility">Compatibility:
|
||
</a></th><td>Moved into the core in Apache 2.0</td></tr></table>
|
||
<p>When placed into an <code>.htaccess</code> file or a
|
||
<code class="directive"><a href="#directory"><Directory></a></code> or
|
||
<code class="directive"><a href="#location"><Location></a></code>
|
||
section, this directive forces all matching files to be parsed
|
||
through the <a href="../handler.html">handler</a> given by
|
||
<var>handler-name</var>. 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>
|
||
|
||
<div class="example"><p><code>
|
||
SetHandler imap-file
|
||
</code></p></div>
|
||
|
||
<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 httpd.conf:</p>
|
||
|
||
<div class="example"><p><code>
|
||
<Location /status><br />
|
||
<span class="indent">
|
||
SetHandler server-status<br />
|
||
</span>
|
||
</Location>
|
||
</code></p></div>
|
||
<h3>See also</h3><ul><li><code class="directive"><a href="../mod/mod_mime.html#addhandler">AddHandler</a></code></li></ul></div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div><div class="directive-section"><h2><a name="SetInputFilter" id="SetInputFilter">SetInputFilter</a> <a name="setinputfilter" id="setinputfilter">Directive</a></h2><table class="directive"><tr><th><a href="directive-dict.html#Description">Description:
|
||
</a></th><td>Sets the filters that will process client requests and POST
|
||
input</td></tr><tr><th><a href="directive-dict.html#Syntax">Syntax:
|
||
</a></th><td><code>SetInputFilter <var>filter</var>[;<var>filter</var>...]</code></td></tr><tr><th><a href="directive-dict.html#Context">Context:
|
||
</a></th><td>server config, virtual host, directory, .htaccess</td></tr><tr><th><a href="directive-dict.html#Override">Override:
|
||
</a></th><td>FileInfo</td></tr><tr><th><a href="directive-dict.html#Status">Status:
|
||
</a></th><td>Core</td></tr><tr><th><a href="directive-dict.html#Module">Module:
|
||
</a></th><td>core</td></tr></table>
|
||
<p>The <code class="directive">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
|
||
<code class="directive"><a href="../mod/mod_mime.html#addinputfilter">AddInputFilter</a></code>
|
||
directive.</p>
|
||
|
||
<p>If more than one filter is specified, they must be separated
|
||
by semicolons in the order in which they should process the
|
||
content.</p>
|
||
<h3>See also</h3><ul><li><a href="../filter.html">Filters</a> documentation</li></ul></div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div><div class="directive-section"><h2><a name="SetOutputFilter" id="SetOutputFilter">SetOutputFilter</a> <a name="setoutputfilter" id="setoutputfilter">Directive</a></h2><table class="directive"><tr><th><a href="directive-dict.html#Description">Description:
|
||
</a></th><td>Sets the filters that will process responses from the
|
||
server</td></tr><tr><th><a href="directive-dict.html#Syntax">Syntax:
|
||
</a></th><td><code>SetOutputFilter <var>filter</var>[;<var>filter</var>...]</code></td></tr><tr><th><a href="directive-dict.html#Context">Context:
|
||
</a></th><td>server config, virtual host, directory, .htaccess</td></tr><tr><th><a href="directive-dict.html#Override">Override:
|
||
</a></th><td>FileInfo</td></tr><tr><th><a href="directive-dict.html#Status">Status:
|
||
</a></th><td>Core</td></tr><tr><th><a href="directive-dict.html#Module">Module:
|
||
</a></th><td>core</td></tr></table>
|
||
<p>The <code class="directive">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
|
||
<code class="directive"><a href="../mod/mod_mime.html#addoutputfilter">AddOutputFilter</a></code>
|
||
directive.</p>
|
||
|
||
<p>For example, the following configuration will process all files
|
||
in the <code>/www/data/</code> directory for server-side
|
||
includes.</p>
|
||
|
||
<div class="example"><p><code>
|
||
<Directory /www/data/><br />
|
||
<span class="indent">
|
||
SetOutputFilter INCLUDES<br />
|
||
</span>
|
||
</Directory>
|
||
</code></p></div>
|
||
|
||
<p>If more than one filter is specified, they must be separated
|
||
by semicolons in the order in which they should process the
|
||
content.</p>
|
||
<h3>See also</h3><ul><li><a href="../filter.html">Filters</a> documentation</li></ul></div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div><div class="directive-section"><h2><a name="TimeOut" id="TimeOut">TimeOut</a> <a name="timeout" id="timeout">Directive</a></h2><table class="directive"><tr><th><a href="directive-dict.html#Description">Description:
|
||
</a></th><td>Amount of time the server will wait for
|
||
certain events before failing a request</td></tr><tr><th><a href="directive-dict.html#Syntax">Syntax:
|
||
</a></th><td><code>TimeOut <var>number</var></code></td></tr><tr><th><a href="directive-dict.html#Default">Default:
|
||
</a></th><td><code>TimeOut 300</code></td></tr><tr><th><a href="directive-dict.html#Context">Context:
|
||
</a></th><td>server config</td></tr><tr><th><a href="directive-dict.html#Status">Status:
|
||
</a></th><td>Core</td></tr><tr><th><a href="directive-dict.html#Module">Module:
|
||
</a></th><td>core</td></tr></table>
|
||
<p>The <code class="directive">TimeOut</code> 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>
|
||
|
||
<p>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>
|
||
</div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div><div class="directive-section"><h2><a name="UseCanonicalName" id="UseCanonicalName">UseCanonicalName</a> <a name="usecanonicalname" id="usecanonicalname">Directive</a></h2><table class="directive"><tr><th><a href="directive-dict.html#Description">Description:
|
||
</a></th><td>Configures how the server determines its own name and
|
||
port</td></tr><tr><th><a href="directive-dict.html#Syntax">Syntax:
|
||
</a></th><td><code>UseCanonicalName on|off|dns</code></td></tr><tr><th><a href="directive-dict.html#Default">Default:
|
||
</a></th><td><code>UseCanonicalName on</code></td></tr><tr><th><a href="directive-dict.html#Context">Context:
|
||
</a></th><td>server config, virtual host, directory</td></tr><tr><th><a href="directive-dict.html#Status">Status:
|
||
</a></th><td>Core</td></tr><tr><th><a href="directive-dict.html#Module">Module:
|
||
</a></th><td>core</td></tr></table>
|
||
<p>In many situations Apache must construct a <em>self-referential</em>
|
||
URL -- that is, a URL that refers back to the same server. With
|
||
<code>UseCanonicalName on</code> Apache will use the hostname and port
|
||
specified in the <code class="directive"><a href="#servername">ServerName</a></code>
|
||
directive to construct the 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, as defined above). 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
|
||
authenticate twice (once for <code>www</code> and once again
|
||
for <code>www.domain.com</code> -- see <a href="http://httpd.apache.org/docs/misc/FAQ.html#prompted-twice">the
|
||
FAQ on this subject for more information</a>). But if
|
||
<code class="directive">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>
|
||
|
||
<div class="warning"><h3>Warning:</h3>
|
||
<p>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>
|
||
</div>
|
||
<h3>See also</h3><ul><li><code class="directive"><a href="#servername">ServerName</a></code></li><li><code class="directive"><a href="../mod/mpm_common.html#listen">Listen</a></code></li></ul></div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div><div class="directive-section"><h2><a name="VirtualHost" id="VirtualHost"><VirtualHost></a> <a name="virtualhost" id="virtualhost">Directive</a></h2><table class="directive"><tr><th><a href="directive-dict.html#Description">Description:
|
||
</a></th><td>Contains directives that apply only to a specific
|
||
hostname or IP address</td></tr><tr><th><a href="directive-dict.html#Syntax">Syntax:
|
||
</a></th><td><code><VirtualHost
|
||
<var>addr</var>[:<var>port</var>] [<var>addr</var>[:<var>port</var>]]
|
||
...> ... </VirtualHost></code></td></tr><tr><th><a href="directive-dict.html#Context">Context:
|
||
</a></th><td>server config</td></tr><tr><th><a href="directive-dict.html#Status">Status:
|
||
</a></th><td>Core</td></tr><tr><th><a href="directive-dict.html#Module">Module:
|
||
</a></th><td>core</td></tr></table>
|
||
<p><code class="directive"><VirtualHost></code> and
|
||
<code></VirtualHost></code> are used to enclose a group of
|
||
directives that will apply only to a particular virtual host. Any
|
||
directive that 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 <code class="directive"><VirtualHost></code>
|
||
section. <var>Addr</var> 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>
|
||
|
||
<li>The character *, which is used only in combination with
|
||
<code>NameVirtualHost *</code> to match all IP addresses; or</li>
|
||
|
||
<li>The string <code>_default_</code>, which is used only
|
||
with IP virtual hosting to catch unmatched IP addresses.</li>
|
||
</ul>
|
||
|
||
<div class="example"><h3>Example</h3><p><code>
|
||
<VirtualHost 10.1.2.3><br />
|
||
<span class="indent">
|
||
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 />
|
||
</span>
|
||
</VirtualHost>
|
||
</code></p></div>
|
||
|
||
|
||
<p>IPv6 addresses must be specified in square brackets because
|
||
the optional port number could not be determined otherwise. An
|
||
IPv6 example is shown below:</p>
|
||
|
||
<div class="example"><p><code>
|
||
<VirtualHost [fe80::a00:20ff:fea7:ccea]><br />
|
||
<span class="indent">
|
||
ServerAdmin webmaster@host.example.com<br />
|
||
DocumentRoot /www/docs/host.example.com<br />
|
||
ServerName host.example.com<br />
|
||
ErrorLog logs/host.example.com-error_log<br />
|
||
TransferLog logs/host.example.com-access_log<br />
|
||
</span>
|
||
</VirtualHost>
|
||
</code></p></div>
|
||
|
||
<p>Each Virtual Host 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).</p>
|
||
|
||
<div class="note"><h3>Note</h3>
|
||
<p>The use of <code class="directive"><VirtualHost></code> does
|
||
<strong>not</strong> affect what addresses Apache listens on. You
|
||
may need to ensure that Apache is listening on the correct addresses
|
||
using <code class="directive"><a href="../mod/mpm_common.html#listen">Listen</a></code>.</p>
|
||
</div>
|
||
|
||
<p>When using IP-based virtual hosting, 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 IP-match occurs. (But note that any IP
|
||
address that matches a <code class="directive"><a href="#namevirtualhost">NameVirtualHost</a></code> directive will use neither
|
||
the "main" server config nor the _default_ virtual host. See the <a href="../vhosts/name-based.html">name-based virtual hosting</a>
|
||
documentation for further details.)</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 class="directive"><a href="../mod/mpm_common.html#listen">Listen</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>
|
||
|
||
<div class="warning"><h3>Security</h3>
|
||
<p>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>
|
||
</div>
|
||
<h3>See also</h3><ul><li><a href="../vhosts/">Apache Virtual Host documentation</a></li><li><a href="../dns-caveats.html">Warnings about DNS and
|
||
Apache</a></li><li><a href="../bind.html">Setting
|
||
which addresses and ports Apache uses</a></li><li><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</li></ul></div></div><div id="footer"><p class="apache">Maintained by the <a href="http://httpd.apache.org/docs-project/">Apache HTTP Server Documentation Project</a></p><p class="menu"><a href="../mod/">Modules</a> | <a href="../mod/directives.html">Directives</a> | <a href="../faq/">FAQ</a> | <a href="../glossary.html">Glossary</a> | <a href="../sitemap.html">Sitemap</a></p></div></body></html> |