core.html.en

    <p>The default is <code>Off</code> in order to save the network
    traffic for those sites that don't truly need the reverse
    lookups done. It is also better for the end users because they
    don't have to suffer the extra latency that a lookup entails.
    Heavily loaded sites should leave this directive
    <code>Off</code>, since DNS lookups can take considerable
    amounts of time. The utility <code class="program"><a href="../programs/logresolve.html">logresolve</a></code>, compiled by
    default to the <code>bin</code> subdirectory of your installation
    directory, can be used to look up host names from logged IP addresses
    offline.</p>

    <p>Finally, if you have <a href="mod_authz_host.html#reqhost">hostname-based Require
    directives</a>, a hostname lookup will be performed regardless of
    the setting of <code>HostnameLookups</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="HttpProtocolOptions" id="HttpProtocolOptions">HttpProtocolOptions</a> <a name="httpprotocoloptions" id="httpprotocoloptions">Directive</a></h2>
<table class="directive">
<tr><th><a href="directive-dict.html#Description">Description:</a></th><td>Modify restrictions on HTTP Request Messages</td></tr>
<tr><th><a href="directive-dict.html#Syntax">Syntax:</a></th><td><code>HttpProtocolOptions [Strict|Unsafe] [RegisteredMethods|LenientMethods]
 [Allow0.9|Require1.0]</code></td></tr>
<tr><th><a href="directive-dict.html#Default">Default:</a></th><td><code>HttpProtocolOptions Strict LenientMethods Allow0.9</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>2.2.32 or 2.4.24 and later</td></tr>
</table>
    <p>This directive changes the rules applied to the HTTP Request Line
    (<a href="https://tools.ietf.org/html/rfc7230#section-3.1.1">RFC 7230 3.1.1</a>) and the HTTP Request Header Fields
    (<a href="https://tools.ietf.org/html/rfc7230#section-3.2">RFC 7230 3.2</a>), which are now applied by default or using
    the <code>Strict</code> option. Due to legacy modules, applications or
    custom user-agents which must be deprecated the <code>Unsafe</code>
    option has been added to revert to the legacy behaviors.</p>

    <p>These rules are applied prior to request processing,
    so must be configured at the global or default (first) matching
    virtual host section, by IP/port interface (and not by name)
    to be honored.</p>

    <p>The directive accepts three parameters from the following list
       of choices, applying the default to the ones not specified:</p>

    <dl>
    <dt>Strict|Unsafe</dt>
    <dd>
      <p>Prior to the introduction of this directive, the Apache HTTP Server
      request message parsers were tolerant of a number of forms of input
      which did not conform to the protocol.
      <a href="https://tools.ietf.org/html/rfc7230#section-9.4">RFC 7230 9.4 Request Splitting</a> and
      <a href="https://tools.ietf.org/html/rfc7230#section-9.5">9.5 Response Smuggling</a> call out only two of the potential
      risks of accepting non-conformant request messages, while
      <a href="https://tools.ietf.org/html/rfc7230#section-3.5">RFC 7230 3.5</a> "Message Parsing Robustness" identify the
      risks of accepting obscure whitespace and request message formatting. 
      As of the introduction of this directive, all grammar rules of the
      specification are enforced in the default <code>Strict</code> operating
      mode, and the strict whitespace suggested by section 3.5 is enforced
      and cannot be relaxed.</p>

      <div class="warning"><h3>Security risks of Unsafe</h3>
        <p>Users are strongly cautioned against toggling the <code>Unsafe</code>
        mode of operation, particularly on outward-facing, publicly accessible
        server deployments.  If an interface is required for faulty monitoring
        or other custom service consumers running on an intranet, users should
        toggle the Unsafe option only on a specific virtual host configured
        to service their internal private network.</p>
      </div>

      <div class="example"><h3>Example of a request leading to HTTP 400 with Strict mode</h3><p><code>
        
        # Missing CRLF<br />
        GET / HTTP/1.0\n\n
      </code></p></div>
      <div class="warning"><h3>Command line tools and CRLF</h3>
        <p>Some tools need to be forced to use CRLF, otherwise httpd will return
        a HTTP 400 response like described in the above use case. For example,
        the <strong>OpenSSL s_client needs the -crlf parameter to work
        properly</strong>.</p>
        <p>The <code class="directive"><a href="../mod/mod_dumpio.html#dumpioinput">DumpIOInput</a></code> directive
        can help while reviewing the HTTP request to identify issues like the
        absence of CRLF.</p>
      </div>
    </dd>
    <dt>RegisteredMethods|LenientMethods</dt>
    <dd>
      <p><a href="https://tools.ietf.org/html/rfc7231#section-4.1">RFC 7231 4.1</a> "Request Methods" "Overview" requires that
      origin servers shall respond with a HTTP 501 status code when an
      unsupported method is encountered in the request line.
      This already happens when the <code>LenientMethods</code> option is used,
      but administrators may wish to toggle the <code>RegisteredMethods</code>
      option and register any non-standard methods using the
      <code class="directive"><a href="#registerhttpmethod">RegisterHttpMethod</a></code>
      directive, particularly if the <code>Unsafe</code>
      option has been toggled.</p>

      <div class="warning"><h3>Forward Proxy compatibility</h3>
        <p>The <code>RegisteredMethods</code> option should <strong>not</strong>
        be toggled for forward proxy hosts, as the methods supported by the
        origin servers are unknown to the proxy server.</p>
      </div>

      <div class="example"><h3>Example of a request leading to HTTP 501 with LenientMethods mode</h3><p><code>
        
        # Unknown HTTP method<br />
        WOW / HTTP/1.0\r\n\r\n<br /><br />
        # Lowercase HTTP method<br />
        get / HTTP/1.0\r\n\r\n<br />
      </code></p></div>
      </dd>
      <dt>Allow0.9|Require1.0</dt>
      <dd>
      <p><a href="https://tools.ietf.org/html/rfc2616#section-19.6">RFC 2616 19.6</a> "Compatibility With Previous Versions" had
      encouraged HTTP servers to support legacy HTTP/0.9 requests. RFC 7230
      supersedes this with "The expectation to support HTTP/0.9 requests has
      been removed" and offers additional comments in 
      <a href="https://tools.ietf.org/html/rfc7230#appendix-A">RFC 7230 Appendix A</a>. The <code>Require1.0</code> option allows
      the user to remove support of the default <code>Allow0.9</code> option's
      behavior.</p>

      <div class="example"><h3>Example of a request leading to HTTP 400 with Require1.0 mode</h3><p><code>
        
        # Unsupported HTTP version<br />
        GET /\r\n\r\n
      </code></p></div>
    </dd>
    </dl>
    <p>Reviewing the messages logged to the
    <code class="directive"><a href="#errorlog">ErrorLog</a></code>, configured with
    <code class="directive"><a href="#loglevel">LogLevel</a></code> <code>debug</code> level,
    can help identify such faulty requests along with their origin.
    Users should pay particular attention to the 400 responses in the access
    log for invalid requests which were unexpectedly rejected.</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="If" id="If">&lt;If&gt;</a> <a name="if" id="if">Directive</a></h2>
<table class="directive">
<tr><th><a href="directive-dict.html#Description">Description:</a></th><td>Contains directives that apply only if a condition is
satisfied by a request at runtime</td></tr>
<tr><th><a href="directive-dict.html#Syntax">Syntax:</a></th><td><code>&lt;If <var>expression</var>&gt; ... &lt;/If&gt;</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>
<tr><th><a href="directive-dict.html#Compatibility">Compatibility:</a></th><td>Nested conditions are evaluated in 2.4.26 and later</td></tr>
</table>
    <p>The <code class="directive">&lt;If&gt;</code> directive
    evaluates an expression at runtime, and applies the enclosed
    directives if and only if the expression evaluates to true.
    For example:</p>

    <pre class="prettyprint lang-config">&lt;If "-z req('Host')"&gt;</pre>


    <p>would match HTTP/1.0 requests without a <var>Host:</var> header.
    Expressions may contain various shell-like operators for string
    comparison (<code>==</code>, <code>!=</code>, <code>&lt;</code>, ...),
    integer comparison (<code>-eq</code>, <code>-ne</code>, ...),
    and others (<code>-n</code>, <code>-z</code>, <code>-f</code>, ...).
    It is also possible to use regular expressions, </p>

    <pre class="prettyprint lang-config">&lt;If "%{QUERY_STRING} =~ /(delete|commit)=.*?elem/"&gt;</pre>


    <p>shell-like pattern matches and many other operations. These operations
    can be done on request headers (<code>req</code>), environment variables
    (<code>env</code>), and a large number of other properties. The full
    documentation is available in <a href="../expr.html">Expressions in
    Apache HTTP Server</a>.</p>

    <p>Only directives that support the <a href="directive-dict.html#Context">directory context</a> can be used within this configuration section.</p>

    <div class="warning">
    Certain variables, such as <code>CONTENT_TYPE</code> and other
    response headers, are set after &lt;If&gt; conditions have already
    been evaluated, and so will not be available to use in this
    directive.
    </div>


<h3>See also</h3>
<ul>
<li><a href="../expr.html">Expressions in Apache HTTP Server</a>,
for a complete reference and more examples.</li>
<li><code class="directive"><a href="#elseif">&lt;ElseIf&gt;</a></code></li>
<li><code class="directive"><a href="#else">&lt;Else&gt;</a></code></li>
<li><a href="../sections.html">How &lt;Directory&gt;, &lt;Location&gt;,
    &lt;Files&gt; sections work</a> for an explanation of how these
    different sections are combined when a request is received.
    <code class="directive">&lt;If&gt;</code>,
    <code class="directive">&lt;ElseIf&gt;</code>, and
    <code class="directive">&lt;Else&gt;</code> are applied last.</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="IfDefine" id="IfDefine">&lt;IfDefine&gt;</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>&lt;IfDefine [!]<var>parameter-name</var>&gt; ...
    &lt;/IfDefine&gt;</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>&lt;IfDefine <var>test</var>&gt;...&lt;/IfDefine&gt;
    </code> section is used to mark directives that are conditional. The
    directives within an <code class="directive">&lt;IfDefine&gt;</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">&lt;IfDefine&gt;</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 class="program"><a href="../programs/httpd.html">httpd</a></code> command line via <code>-D<var>parameter</var>
    </code> at the time the server was started or by the <code class="directive"><a href="#define">Define</a></code> directive.</p>

    <p><code class="directive">&lt;IfDefine&gt;</code> sections are
    nest-able, which can be used to implement simple
    multiple-parameter tests. Example:</p>

    <div class="example"><p><code>httpd -DReverseProxy -DUseCache -DMemCache ...</code></p></div>
    <pre class="prettyprint lang-config">&lt;IfDefine ReverseProxy&gt;
  LoadModule proxy_module   modules/mod_proxy.so
  LoadModule proxy_http_module   modules/mod_proxy_http.so
  &lt;IfDefine UseCache&gt;
    LoadModule cache_module   modules/mod_cache.so
    &lt;IfDefine MemCache&gt;
      LoadModule mem_cache_module   modules/mod_mem_cache.so
    &lt;/IfDefine&gt;
    &lt;IfDefine !MemCache&gt;
      LoadModule cache_disk_module   modules/mod_cache_disk.so
    &lt;/IfDefine&gt;
  &lt;/IfDefine&gt;
&lt;/IfDefine&gt;</pre>


</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">&lt;IfModule&gt;</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>&lt;IfModule [!]<var>module-file</var>|<var>module-identifier</var>&gt; ...
    &lt;/IfModule&gt;</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>
<tr><th><a href="directive-dict.html#Compatibility">Compatibility:</a></th><td>Module identifiers are available in version 2.1 and
later.</td></tr>
</table>
    <p>The <code>&lt;IfModule <var>test</var>&gt;...&lt;/IfModule&gt;</code>
    section is used to mark directives that are conditional on the presence of
    a specific module. The directives within an <code class="directive">&lt;IfModule&gt;</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">&lt;IfModule&gt;</code> section directive can be one of two forms:</p>

    <ul>
      <li><var>module</var></li>

      <li>!<var>module</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</var>
    is included in Apache httpd -- 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</var> is
    <strong>not</strong> included.</p>

    <p>The <var>module</var> argument can be either the module identifier or
    the file name of the module, at the time it was compiled.  For example,
    <code>rewrite_module</code> is the identifier and
    <code>mod_rewrite.c</code> is the file name. 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">&lt;IfModule&gt;</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">&lt;IfModule&gt;</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>|<var>wildcard</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>Directory
wildcard matching available in 2.3.6 and later</td></tr>
</table>
    <p>This directive allows inclusion of other configuration files
    from within the server configuration files.</p>

    <p>Shell-style (<code>fnmatch()</code>) wildcard characters can be used
    in the filename or directory parts of the path 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 httpd will read all files in that directory and any subdirectory.
    However, including entire directories is not recommended, because it is
    easy to accidentally leave temporary files in a directory that can cause
    <code class="program"><a href="../programs/httpd.html">httpd</a></code> to fail. Instead, we encourage you to use the
    wildcard syntax shown below, to include files that match a particular
    pattern, such as *.conf, for example.</p>

    <p>The <code class="directive"><a href="#include">Include</a></code> directive will
    <strong>fail with an error</strong> if a wildcard expression does not
    match any file. The <code class="directive"><a href="#includeoptional">IncludeOptional</a></code>
    directive can be used if non-matching wildcards should be ignored.</p>

    <p>The file path specified may be an absolute path, or may be relative
    to the <code class="directive"><a href="#serverroot">ServerRoot</a></code> directory.</p>

    <p>Examples:</p>

    <pre class="prettyprint lang-config">Include /usr/local/apache2/conf/ssl.conf
Include /usr/local/apache2/conf/vhosts/*.conf</pre>


    <p>Or, providing paths relative to your <code class="directive"><a href="#serverroot">ServerRoot</a></code> directory:</p>

    <pre class="prettyprint lang-config">Include conf/ssl.conf
Include conf/vhosts/*.conf</pre>


    <p>Wildcards may be included in the directory or file portion of the
    path. This example will fail if there is no subdirectory in conf/vhosts
    that contains at least one *.conf file:</p>

    <pre class="prettyprint lang-config">Include conf/vhosts/*/*.conf</pre>


    <p>Alternatively, the following command will just be ignored in case of
    missing files or directories:</p>

    <pre class="prettyprint lang-config">IncludeOptional conf/vhosts/*/*.conf</pre>



<h3>See also</h3>
<ul>
<li><code class="directive"><a href="#includeoptional">IncludeOptional</a></code></li>
<li><code class="program"><a href="../programs/apachectl.html">apachectl</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="IncludeOptional" id="IncludeOptional">IncludeOptional</a> <a name="includeoptional" id="includeoptional">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>IncludeOptional <var>file-path</var>|<var>directory-path</var>|<var>wildcard</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>Available in 2.3.6 and later</td></tr>
</table>
    <p>This directive allows inclusion of other configuration files
    from within the server configuration files. It works identically to the
    <code class="directive"><a href="#include">Include</a></code> directive, with the
    exception that if wildcards do not match any file or directory, the
    <code class="directive"><a href="#includeoptional">IncludeOptional</a></code> directive will be
    silently ignored instead of causing an error.</p>

<h3>See also</h3>
<ul>
<li><code class="directive"><a href="#include">Include</a></code></li>
<li><code class="program"><a href="../programs/apachectl.html">apachectl</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="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, set
    <code>KeepAlive On</code>.</p>

    <p>For HTTP/1.0 clients, Keep-Alive connections will only be
    used if they are specifically requested by a client. In
    addition, a Keep-Alive connection with an HTTP/1.0 client can
    only be used when the length of the content is known in
    advance. This implies that dynamic content such as CGI output,
    SSI pages, and server-generated directory listings will
    generally not use Keep-Alive connections to HTTP/1.0 clients.
    For HTTP/1.1 clients, persistent connections are the default
    unless otherwise specified. If the client requests it, chunked
    encoding will be used in order to send content of unknown
    length over persistent connections.</p>

    <p>When a client uses a Keep-Alive connection, it will be counted
    as a single "request" for the <code class="directive"><a href="../mod/mpm_common.html#maxconnectionsperchild">MaxConnectionsPerChild</a></code> directive, regardless
    of how many requests are sent using the connection.</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>num</var>[ms]</code></td></tr>
<tr><th><a href="directive-dict.html#Default">Default:</a></th><td><code>KeepAliveTimeout 5</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 httpd will wait for a subsequent
    request before closing the connection. By adding a postfix of ms the
    timeout can be also set in milliseconds. 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>

    <p>If <code class="directive">KeepAliveTimeout</code> is <strong>not</strong>
    set for a name-based virtual host, the value of the first defined
    virtual host best matching the local IP and port will be used.</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">&lt;Limit&gt;</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>&lt;Limit <var>method</var> [<var>method</var>] ... &gt; ...
    &lt;/Limit&gt;</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, Limit</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">&lt;Limit&gt;</code> section.</strong></p>

    <p>The purpose of the <code class="directive">&lt;Limit&gt;</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 class="directive">&lt;Limit&gt;</code> bracket <strong>will have no
    effect</strong>. The following example applies the access control
    only to the methods <code>POST</code>, <code>PUT</code>, and
    <code>DELETE</code>, leaving all other methods unprotected:</p>

    <pre class="prettyprint lang-config">&lt;Limit POST PUT DELETE&gt;
  Require valid-user
&lt;/Limit&gt;</pre>


    <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>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. The <code>TRACE</code> method
    cannot be limited (see <code class="directive"><a href="#traceenable">TraceEnable</a></code>).</p>

    <div class="warning">A <code class="directive"><a href="#limitexcept">&lt;LimitExcept&gt;</a></code> section should always be
    used in preference to a <code class="directive">&lt;Limit&gt;</code>
    section when restricting access, since a <code class="directive"><a href="#limitexcept">&lt;LimitExcept&gt;</a></code> section provides protection
    against arbitrary methods.</div>

    <p>The <code class="directive">&lt;Limit&gt;</code> and
    <code class="directive"><a href="#limitexcept">&lt;LimitExcept&gt;</a></code>
    directives may be nested.  In this case, each successive level of
    <code class="directive">&lt;Limit&gt;</code> or <code class="directive"><a href="#limitexcept">&lt;LimitExcept&gt;</a></code> directives must
    further restrict the set of methods to which access controls apply.</p>

    <div class="warning">When using
    <code class="directive">&lt;Limit&gt;</code> or
    <code class="directive">&lt;LimitExcept&gt;</code> directives with
    the <code class="directive"><a href="../mod/mod_authz_core.html#require">Require</a></code> directive,
    note that the first <code class="directive"><a href="../mod/mod_authz_core.html#require">Require</a></code>
    to succeed authorizes the request, regardless of the presence of other
    <code class="directive"><a href="../mod/mod_authz_core.html#require">Require</a></code> directives.</div>

    <p>For example, given the following configuration, all users will
    be authorized for <code>POST</code> requests, and the
    <code>Require group editors</code> directive will be ignored
    in all cases:</p>

    <pre class="prettyprint lang-config">&lt;LimitExcept GET&gt;
  Require valid-user
&lt;/LimitExcept&gt;
&lt;Limit POST&gt;
  Require group editors
&lt;/Limit&gt;</pre>


</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">&lt;LimitExcept&gt;</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>&lt;LimitExcept <var>method</var> [<var>method</var>] ... &gt; ...
    &lt;/LimitExcept&gt;</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, Limit</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">&lt;LimitExcept&gt;</code> and
    <code>&lt;/LimitExcept&gt;</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">&lt;Limit&gt;</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">&lt;Limit&gt;</a></code> for more details.</p>

    <p>For example:</p>

    <pre class="prettyprint lang-config">&lt;LimitExcept POST GET&gt;
  Require valid-user
&lt;/LimitExcept&gt;</pre>



</div>
<div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
<div class="directive-section"><h2><a name="LimitInternalRecursion" id="LimitInternalRecursion">LimitInternalRecursion</a> <a name="limitinternalrecursion" id="limitinternalrecursion">Directive</a></h2>
<table class="directive">
<tr><th><a href="directive-dict.html#Description">Description:</a></th><td>Determine maximum number of internal redirects and nested
subrequests</td></tr>
<tr><th><a href="directive-dict.html#Syntax">Syntax:</a></th><td><code>LimitInternalRecursion <var>number</var> [<var>number</var>]</code></td></tr>
<tr><th><a href="directive-dict.html#Default">Default:</a></th><td><code>LimitInternalRecursion 10</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>An internal redirect happens, for example, when using the <code class="directive"><a href="../mod/mod_actions.html#action">Action</a></code> directive, which internally
    redirects the original request to a CGI script. A subrequest is Apache httpd's
    mechanism to find out what would happen for some URI if it were requested.
    For example, <code class="module"><a href="../mod/mod_dir.html">mod_dir</a></code> uses subrequests to look for the
    files listed in the <code class="directive"><a href="../mod/mod_dir.html#directoryindex">DirectoryIndex</a></code>
    directive.</p>

    <p><code class="directive">LimitInternalRecursion</code> prevents the server
    from crashing when entering an infinite loop of internal redirects or
    subrequests. Such loops are usually caused by misconfigurations.</p>

    <p>The directive stores two different limits, which are evaluated on
    per-request basis. The first <var>number</var> is the maximum number of
    internal redirects that may follow each other. The second <var>number</var>
    determines how deeply subrequests may be nested. If you specify only one
    <var>number</var>, it will be assigned to both limits.</p>

    <pre class="prettyprint lang-config">LimitInternalRecursion 5</pre>


</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. See the note below for the limited applicability
    to proxy requests.</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 retrieving form information.
    Implementations of the <code>PUT</code> 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 wish to limit the size of the uploaded file to 100K,
    you might use the following directive:</p>

    <pre class="prettyprint lang-config">LimitRequestBody 102400</pre>


    <div class="note"><p>For a full description of how this directive is interpreted by
    proxy requests, see the <code class="module"><a href="../mod/mod_proxy.html">mod_proxy</a></code> documentation.</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, 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><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>

    <pre class="prettyprint lang-config">LimitRequestFields 50</pre>


     <div class="warning"><h3>Warning</h3>
     <p> When name-based virtual hosting is used, the value for this
     directive is taken from the default (first-listed) virtual host for the
     local IP and port combination.</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, 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 specifies the number of <var>bytes</var>
    that will be allowed in an HTTP request header.</p>

    <p>The <code class="directive">LimitRequestFieldSize</code> directive
    allows the server administrator to set the limit
    on the allowed size of an HTTP request header field. 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. SPNEGO
    authentication headers can be up to 12392 bytes.</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>

    <pre class="prettyprint lang-config">LimitRequestFieldSize 4094</pre>


    <div class="note">Under normal conditions, the value should not be changed from
    the default.</div>

    <div class="warning"><h3>Warning</h3>
    <p> When name-based virtual hosting is used, the value for this
    directive is taken from the default (first-listed) virtual host best
    matching the current IP address and port combination.</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="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, 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 number of <var>bytes</var> that will be
    allowed on the HTTP request-line.</p>

    <p>The <code class="directive">LimitRequestLine</code> directive allows
    the server administrator to set the limit on the allowed size
    of a client's HTTP request-line. 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 <code>GET</code> 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>

    <pre class="prettyprint lang-config">LimitRequestLine 4094</pre>


    <div class="note">Under normal conditions, the value should not be changed from
    the default.</div>

    <div class="warning"><h3>Warning</h3>
    <p> When name-based virtual hosting is used, the value for this
    directive is taken from the default (first-listed) virtual host best
    matching the current IP address and port combination.</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="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>bytes</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>

    <pre class="prettyprint lang-config">LimitXMLRequestBody 0</pre>



</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">&lt;Location&gt;</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>&lt;Location
    <var>URL-path</var>|<var>URL</var>&gt; ... &lt;/Location&gt;</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">&lt;Location&gt;</code> directive
    limits the scope of the enclosed directives by URL. It is similar to the
    <code class="directive"><a href="#directory">&lt;Directory&gt;</a></code>
    directive, and starts a subsection which is terminated with a
    <code>&lt;/Location&gt;</code> directive. <code class="directive">&lt;Location&gt;</code> sections are processed in the
    order they appear in the configuration file, after the <code class="directive"><a href="#directory">&lt;Directory&gt;</a></code> sections and
    <code>.htaccess</code> files are read, and after the <code class="directive"><a href="#files">&lt;Files&gt;</a></code> sections.</p>

    <p><code class="directive">&lt;Location&gt;</code> sections operate
    completely outside the filesystem.  This has several consequences.
    Most importantly, <code class="directive">&lt;Location&gt;</code>
    directives should not be used to control access to filesystem
    locations.  Since several different URLs may map to the same
    filesystem location, such access controls may by circumvented.</p>

    <p>The enclosed directives will be applied to the request if the path component
    of the URL meets <em>any</em> of the following criteria:
    </p>
    <ul>
      <li>The specified location matches exactly the path component of the URL.
      </li>
      <li>The specified location, which ends in a forward slash, is a prefix
      of the path component of the URL (treated as a context root).
      </li>
      <li>The specified location, with the addition of a trailing slash, is a
      prefix of the path component of the URL (also treated as a context root).
      </li>
    </ul>
    <p>
    In the example below, where no trailing slash is used, requests to
    /private1, /private1/ and /private1/file.txt will have the enclosed
    directives applied, but /private1other would not.
    </p>
    <pre class="prettyprint lang-config">&lt;Location "/private1"&gt;
    #  ...
&lt;/Location&gt;</pre>

    <p>
    In the example below, where a trailing slash is used, requests to
    /private2/ and /private2/file.txt will have the enclosed
    directives applied, but /private2 and /private2other would not.
    </p>
    <pre class="prettyprint lang-config">&lt;Location "/private2<em>/</em>"&gt;
    # ...
&lt;/Location&gt;</pre>


    <div class="note"><h3>When to use <code class="directive">&lt;Location&gt;</code></h3>

    <p>Use <code class="directive">&lt;Location&gt;</code> to apply
    directives to content that lives outside the filesystem.  For
    content that lives in the filesystem, use <code class="directive"><a href="#directory">&lt;Directory&gt;</a></code> and <code class="directive"><a href="#files">&lt;Files&gt;</a></code>.  An exception is
    <code>&lt;Location "/"&gt;</code>, which is an easy way to
    apply a configuration to the entire server.</p>
    </div>

    <p>For all origin (non-proxy) requests, the URL to be matched is a
    URL-path of the form <code>/path/</code>.  <em>No scheme, hostname,
    port, or query string may be included.</em>  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, <code>?</code> matches
    any single character, and <code>*</code> matches any sequences of
    characters. Neither wildcard character matches a / in the URL-path.</p>

    <p><a class="glossarylink" href="../glossary.html#regex" title="see glossary">Regular expressions</a>
    can also be used, with the addition of the <code>~</code>
    character. For example:</p>

    <pre class="prettyprint lang-config">&lt;Location ~ "/(extra|special)/data"&gt;
    #...
&lt;/Location&gt;</pre>


    <p>would match URLs that contained the substring <code>/extra/data</code>
    or <code>/special/data</code>. The directive <code class="directive"><a href="#locationmatch">&lt;LocationMatch&gt;</a></code> behaves
    identical to the regex version of <code class="directive">&lt;Location&gt;</code>, and is preferred, for the
    simple reason that <code>~</code> is hard to distinguish from
    <code>-</code> in many fonts.</p>

    <p>The <code class="directive">&lt;Location&gt;</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 <code>example.com</code>, you might use:</p>

    <pre class="prettyprint lang-config">&lt;Location "/status"&gt;
  SetHandler server-status
  Require host example.com
&lt;/Location&gt;</pre>


    <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">&lt;LocationMatch&gt;</a></code>
      directive and the regex version of <code class="directive">&lt;Location&gt;</code> require you to explicitly specify multiple
      slashes if that is your intention.</p>

      <p>For example, <code>&lt;LocationMatch "^/abc"&gt;</code> would match
      the request URL <code>/abc</code> but not the request URL <code>
      //abc</code>. The (non-regex) <code class="directive">&lt;Location&gt;</code> directive behaves similarly when used for
      proxy requests. But when (non-regex) <code class="directive">&lt;Location&gt;</code> is used for non-proxy requests it will
      implicitly match multiple slashes with a single slash. For example,
      if you specify <code>&lt;Location "/abc/def"&gt;</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 &lt;Directory&gt;, &lt;Location&gt;
    and &lt;Files&gt; sections work</a> for an explanation of how these
    different sections are combined when a request is received.</li>
<li><code class="directive"><a href="#locationmatch">LocationMatch</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="LocationMatch" id="LocationMatch">&lt;LocationMatch&gt;</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>&lt;LocationMatch
    <var>regex</var>&gt; ... &lt;/LocationMatch&gt;</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">&lt;LocationMatch&gt;</code> directive
    limits the scope of the enclosed directives by URL, in an identical manner
    to <code class="directive"><a href="#location">&lt;Location&gt;</a></code>. However,
    it takes a <a class="glossarylink" href="../glossary.html#regex" title="see glossary">regular expression</a>
    as an argument instead of a simple string. For example:</p>

    <pre class="prettyprint lang-config">&lt;LocationMatch "/(extra|special)/data"&gt;
    # ...
&lt;/LocationMatch&gt;</pre>


    <p>would match URLs that contained the substring <code>/extra/data</code>
    or <code>/special/data</code>.</p>

    <div class="note"><p>If the intent is that a URL <strong>starts with</strong>
    <code>/extra/data</code>, rather than merely
    <strong>contains</strong> <code>/extra/data</code>, prefix the
    regular expression with a <code>^</code> to require this.</p>

    <pre class="prettyprint lang-config">&lt;LocationMatch "^/(extra|special)/data"&gt;</pre>

    </div>

    <p>From 2.4.8 onwards, named groups and backreferences are captured and
    written to the environment with the corresponding name prefixed with
    "MATCH_" and in upper case. This allows elements of URLs to be referenced
    from within <a href="../expr.html">expressions</a> and modules like
    <code class="module"><a href="../mod/mod_rewrite.html">mod_rewrite</a></code>. In order to prevent confusion, numbered
    (unnamed) backreferences are ignored. Use named groups instead.</p>

    <pre class="prettyprint lang-config">&lt;LocationMatch "^/combined/(?&lt;sitename&gt;[^/]+)"&gt;
    require ldap-group cn=%{env:MATCH_SITENAME},ou=combined,o=Example
&lt;/LocationMatch&gt;</pre>


<h3>See also</h3>
<ul>
<li><a href="../sections.html">How &lt;Directory&gt;, &lt;Location&gt;
    and &lt;Files&gt; 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>module</var>:]<var>level</var>
    [<var>module</var>:<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, 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>Per-module and per-directory configuration is available in
    Apache HTTP Server 2.3.6 and later</td></tr>
</table>
    <p><code class="directive">LogLevel</code> adjusts the verbosity of the