httpd-cvs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From rbo...@apache.org
Subject svn commit: r1040999 [2/2] - /httpd/httpd/trunk/docs/manual/mod/core.xml.es
Date Wed, 01 Dec 2010 13:21:15 GMT

Added: httpd/httpd/trunk/docs/manual/mod/core.xml.es
URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/manual/mod/core.xml.es?rev=1040999&view=auto
==============================================================================
--- httpd/httpd/trunk/docs/manual/mod/core.xml.es (added)
+++ httpd/httpd/trunk/docs/manual/mod/core.xml.es Wed Dec  1 13:21:15 2010
@@ -0,0 +1,4058 @@
+<?xml version="1.0"?>
+<!DOCTYPE modulesynopsis SYSTEM "../style/modulesynopsis.dtd">
+<?xml-stylesheet type="text/xsl" href="../style/manual.en.xsl"?>
+<!-- $LastChangedRevision: 1040494 $ -->
+
+<!--
+ Licensed to the Apache Software Foundation (ASF) under one or more
+ contributor license agreements.  See the NOTICE file distributed with
+ this work for additional information regarding copyright ownership.
+ The ASF licenses this file to You under the Apache License, Version 2.0
+ (the "License"); you may not use this file except in compliance with
+ the License.  You may obtain a copy of the License at
+
+     http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+
+<modulesynopsis metafile="core.xml.meta">
+
+<name>core</name>
+<description>Funcionalides básicas del Servidor HTTP Apache que siempre están presentes.</description>
+<status>Core</status>
+
+<directivesynopsis>
+<name>AcceptFilter</name>
+<description>Configura mejoras para un Protocolo de Escucha de Sockets</description>
+<syntax>AcceptFilter <var>protocol</var> <var>accept_filter</var></syntax>
+<contextlist><context>server config</context></contextlist>
+<compatibility>Disponible en Apache httpd 2.1.5 y posteriores.
+En Windows desde Apache httpd 2.3.3 y posteriores.</compatibility>
+
+<usage>
+    <p>Esta directiva hace posible mejoras específicas a nivel de sistema operativo
+       y a través del tipo de Protocolo para un socket que escucha.
+       La premisa básica es que el kernel no envíe un socket al servidor
+       hasta que o bien los datos se hayan recibido o bien se haya almacenado
+       en el buffer una Respuesta HTTP completa.  
+       Actualmente sólo están soportados
+       <a href="http://www.freebsd.org/cgi/man.cgi?query=accept_filter&amp;sektion=9">
+       Accept Filters</a> sobre FreeBSD, <code>TCP_DEFER_ACCEPT</code> sobre Linux, 
+       y AcceptEx() sobre Windows.</p>
+
+    <p>El uso de <code>none</code> para un argumento desactiva cualquier filtro 
+       aceptado para ese protocolo. Esto es útil para protocolos que requieren que un
+       servidor envíe datos primeros, tales como <code>ftp:</code> o <code>nntp</code>:</p>
+    <example>AcceptFilter nntp none</example>
+
+    <p>Los nombres de protocolo por defecto son <code>https</code> para el puerto 443
+       y <code>http</code> para todos los demás puertos. Para especificar que se está
+       utilizando otro protocolo con un puerto escuchando, añade el argumento <var>protocol</var>
+       a la directiva <directive module="mpm_common">Listen</directive>.</p>
+
+    <p>Sobre FreeBDS los valores por defecto:</p>
+    <example>
+        AcceptFilter http httpready <br/>
+        AcceptFilter https dataready
+    </example>
+    
+    <p>El filtro <code>httpready</code> almacena en el buffer peticiones HTTP completas
+       a nivel de kernel.  Una vez que la petición es recibida, el kernel la envía al servidor. 
+       Consulta la página man de
+       <a href="http://www.freebsd.org/cgi/man.cgi?query=accf_http&amp;sektion=9">
+       accf_http(9)</a> para más detalles.  Puesto que las peticiones HTTPS
+       están encriptadas, sólo se utiliza el filtro
+       <a href="http://www.freebsd.org/cgi/man.cgi?query=accf_data&amp;sektion=9">accf_data(9)</a>.</p>
+
+    <p>Sobre Linux los valores por defecto son:</p>
+    <example>
+        AcceptFilter http data <br/>
+        AcceptFilter https data
+    </example>
+
+    <p>En Linux, <code>TCP_DEFER_ACCEPT</code> no soporta el buffering en peticiones http.
+       Cualquier valor además de <code>none</code> habilitará 
+       <code>TCP_DEFER_ACCEPT</code> en ese socket. Para más detalles 
+       ver la página man de Linux 
+       <a href="http://homepages.cwi.nl/~aeb/linux/man2html/man7/tcp.7.html">
+       tcp(7)</a>.</p>
+
+    <p>Sobre Windows los valores por defecto son:</p>
+    <example>
+        AcceptFilter http data <br/>
+        AcceptFilter https data
+    </example>
+
+    <p>Sobre Windows mpm_winnt interpreta el argumento AcceptFilter para conmutar la API
+       AcceptEx(), y no soporta el buffering sobre el protocolo http.  Hay dos valores
+       que utilizan la API Windows AcceptEx() y que recuperan sockets de red
+       entre conexciones.  <code>data</code> espera hasta que los datos han sido
+       transmitidos como se comentaba anteriormente, y el buffer inicial de datos y las
+       direcciones de red son recuperadas a partir de una única llamada AcceptEx().
+       <code>connect</code> utiliza la API AcceptEx() API, y recupera también
+       las direccciones de red, pero a diferencia de <code>none</code> 
+       la opción <code>connect</code> no espera a la transmisión inicial de los datos.</p>
+
+    <p>Sobre Windows, <code>none</code> prefiere accept() antes que AcceptEx()
+       y no recuperará sockets entre las conexiones.  Lo que es útil para los adaptadores de
+       red con un soporte precario de drivers, así como para algunos proveedores de red
+       tales como drivers vpn, o filtros de spam, de virus o de spyware.</p>  
+
+</usage>
+<seealso><directive>Protocol</directive></seealso>
+</directivesynopsis>
+
+<directivesynopsis>
+<name>AcceptPathInfo</name>
+<description>Los recursos aceptan información sobre su ruta</description>
+<syntax>AcceptPathInfo On|Off|Default</syntax>
+<default>AcceptPathInfo Default</default>
+<contextlist><context>server config</context>
+<context>virtual host</context><context>directory</context>
+<context>.htaccess</context></contextlist>
+<override>FileInfo</override>
+<compatibility>Disponible en Apache httpd 2.0.30 y posteriores</compatibility>
+
+<usage>
+
+    <p>Esta directiva controla si las peticiones que contienen información sobre la ruta
+    que sigue un fichero que existe (o un fichero que no existe pero en un directorio que
+    sí existe) serán aceptadas o denegadas.  La información de ruta puede estar disponible
+    para los scripts en la variable de entorno <code>PATH_INFO</code>.</p>
+
+    <p>Por ejemplo, asumamos que la ubicación <code>/test/</code> apunta a
+    un directorio que contiene únicamente el fichero
+    <code>here.html</code>.  Entonces, las peticiones tanto para
+    <code>/test/here.html/more</code> como para
+    <code>/test/nothere.html/more</code> recogen
+    <code>/more</code> como <code>PATH_INFO</code>.</p>
+
+    <p>Los tres posibles argumentos para la directiva
+    <directive>AcceptPathInfo</directive> son los siguientes:</p>
+    <dl>
+    <dt><code>Off</code></dt><dd>Una petición sólo será aceptada si
+    se corresponde con una ruta literal que existe.  Por lo tanto, una petición
+    con una información de ruta después del nombre de fichero tal como
+    <code>/test/here.html/more</code> en el ejemplo anterior devolverá
+    un error 404 NOT FOUND.</dd>
+
+    <dt><code>On</code></dt><dd>Una petición será aceptada si una
+    ruta principal de acceso se corresponde con un fichero que existe. El ejemplo
+    anterior <code>/test/here.html/more</code> será aceptado si
+    <code>/test/here.html</code> corresponde a un fichero válido.</dd>
+
+    <dt><code>Default</code></dt><dd>La gestión de las peticiones
+    con información de ruta está determinada por el <a
+    href="../handler.html">controlador</a> responsable de la petición.
+    El controlador principal para para ficheros normales rechaza por defecto
+    peticiones <code>PATH_INFO</code>. Los controladores que sirven scripts, tales como <a
+    href="mod_cgi.html">cgi-script</a> e <a
+    href="mod_isapi.html">isapi-handler</a>, normalmente aceptan
+    <code>PATH_INFO</code> por defecto.</dd>
+    </dl>
+
+    <p>El objetivo principal de la directiva <code>AcceptPathInfo</code>
+    es permitirte sobreescribir la opción del controlador
+    de aceptar or rechazar <code>PATH_INFO</code>. 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 <code>PATH_INFO</code>.  The core handler would usually reject
+    the request, so you can use the following configuration to enable
+    such a script:</p>
+
+    <example>
+      &lt;Files "mypaths.shtml"&gt;<br />
+      <indent>
+        Options +Includes<br />
+        SetOutputFilter INCLUDES<br />
+        AcceptPathInfo On<br />
+      </indent>
+      &lt;/Files&gt;
+    </example>
+
+</usage>
+</directivesynopsis>
+
+<directivesynopsis>
+<name>AccessFileName</name>
+<description>Name of the distributed configuration file</description>
+<syntax>AccessFileName <var>filename</var> [<var>filename</var>] ...</syntax>
+<default>AccessFileName .htaccess</default>
+<contextlist><context>server config</context><context>virtual host</context>
+</contextlist>
+
+<usage>
+    <p>While processing a request 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 <a href="#allowoverride">enabled for that
+    directory</a>. For example:</p>
+
+    <example>
+      AccessFileName .acl
+    </example>
+
+    <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>
+
+    <example>
+      &lt;Directory /&gt;<br />
+      <indent>
+        AllowOverride None<br />
+      </indent>
+      &lt;/Directory&gt;
+    </example>
+</usage>
+<seealso><directive module="core">AllowOverride</directive></seealso>
+<seealso><a href="../configuring.html">Configuration Files</a></seealso>
+<seealso><a href="../howto/htaccess.html">.htaccess Files</a></seealso>
+</directivesynopsis>
+
+<directivesynopsis>
+<name>AddDefaultCharset</name>
+<description>Default charset parameter to be added when a response
+content-type is <code>text/plain</code> or <code>text/html</code></description>
+<syntax>AddDefaultCharset On|Off|<var>charset</var></syntax>
+<default>AddDefaultCharset Off</default>
+<contextlist><context>server config</context>
+<context>virtual host</context><context>directory</context>
+<context>.htaccess</context></contextlist>
+<override>FileInfo</override>
+
+<usage>
+    <p>This directive specifies a default value for the media type
+    charset parameter (the name of a character encoding) to be added
+    to a response if and only if the response's content-type is either
+    <code>text/plain</code> or <code>text/html</code>.  This should override
+    any charset specified in the body of the response via a <code>META</code>
+    element, though the exact behavior is often dependent on the user's client
+    configuration. A setting of <code>AddDefaultCharset Off</code>
+    disables this functionality. <code>AddDefaultCharset On</code> enables
+    a default charset of <code>iso-8859-1</code>. Any other value is assumed
+    to be the <var>charset</var> to be used, which should be one of the
+    <a href="http://www.iana.org/assignments/character-sets">IANA registered
+    charset values</a> for use in Internet media types (MIME types).
+    For example:</p>
+
+    <example>
+      AddDefaultCharset utf-8
+    </example>
+
+    <p><directive>AddDefaultCharset</directive> should only be used when all
+    of the text resources to which it applies are known to be in that
+    character encoding and it is too inconvenient to label their charset
+    individually. One such example is to add the charset parameter
+    to resources containing generated content, such as legacy CGI
+    scripts, that might be vulnerable to cross-site scripting attacks
+    due to user-provided data being included in the output.  Note, however,
+    that a better solution is to just fix (or delete) those scripts, since
+    setting a default charset does not protect users that have enabled
+    the "auto-detect character encoding" feature on their browser.</p>
+</usage>
+<seealso><directive module="mod_mime">AddCharset</directive></seealso>
+</directivesynopsis>
+
+<directivesynopsis>
+<name>AllowEncodedSlashes</name>
+<description>Determines whether encoded path separators in URLs are allowed to
+be passed through</description>
+<syntax>AllowEncodedSlashes On|Off</syntax>
+<default>AllowEncodedSlashes Off</default>
+<contextlist><context>server config</context><context>virtual host</context>
+</contextlist>
+<compatibility>Available in Apache httpd 2.0.46 and later</compatibility>
+
+<usage>
+    <p>The <directive>AllowEncodedSlashes</directive> directive allows URLs
+    which contain encoded path separators (<code>%2F</code> for <code>/</code>
+    and additionally <code>%5C</code> for <code>\</code> on according systems)
+    to be used. Normally such URLs are refused with a 404 (Not found) error.</p>
+
+    <p>Turning <directive>AllowEncodedSlashes</directive> <code>On</code> is
+    mostly useful when used in conjunction with <code>PATH_INFO</code>.</p>
+
+    <note><title>Note</title>
+      <p>Allowing encoded slashes does <em>not</em> imply <em>decoding</em>.
+      Occurrences of <code>%2F</code> or <code>%5C</code> (<em>only</em> on
+      according systems) will be left as such in the otherwise decoded URL
+      string.</p>
+    </note>
+</usage>
+<seealso><directive module="core">AcceptPathInfo</directive></seealso>
+</directivesynopsis>
+
+<directivesynopsis>
+<name>AllowOverride</name>
+<description>Types of directives that are allowed in
+<code>.htaccess</code> files</description>
+<syntax>AllowOverride All|None|<var>directive-type</var>
+[<var>directive-type</var>] ...</syntax>
+<default>AllowOverride None (2.3.9 and later), AllowOverride All (2.3.8 and earlier)</default>
+<contextlist><context>directory</context></contextlist>
+
+<usage>
+    <p>When the server finds an <code>.htaccess</code> file (as
+    specified by <directive module="core">AccessFileName</directive>)
+    it needs to know which directives declared in that file can override
+    earlier configuration directives.</p>
+
+    <note><title>Only available in &lt;Directory&gt; sections</title>
+    <directive>AllowOverride</directive> is valid only in
+    <directive type="section" module="core">Directory</directive>
+    sections specified without regular expressions, not in <directive
+    type="section" module="core">Location</directive>, <directive
+    module="core" type="section">DirectoryMatch</directive> or
+    <directive type="section" module="core">Files</directive> sections.
+    </note>
+
+    <p>When this directive is set to <code>None</code>, then
+    <a href="#accessfilename">.htaccess</a> files are completely ignored.
+    In this case, the server will not even attempt to read
+    <code>.htaccess</code> 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
+    <code>.htaccess</code> 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 (<directive
+      module="mod_authn_dbm">AuthDBMGroupFile</directive>,
+      <directive module="mod_authn_dbm">AuthDBMUserFile</directive>,
+      <directive module="mod_authz_groupfile">AuthGroupFile</directive>,
+      <directive module="mod_authn_core">AuthName</directive>,
+      <directive module="mod_authn_core">AuthType</directive>, <directive
+      module="mod_authn_file">AuthUserFile</directive>, <directive
+      module="mod_authz_core">Require</directive>, <em>etc.</em>).</dd>
+
+      <dt>FileInfo</dt>
+
+      <dd>
+      Allow use of the directives controlling document types
+     (<directive module="core">ErrorDocument</directive>,
+      <directive module="core">ForceType</directive>,
+      <directive module="mod_negotiation">LanguagePriority</directive>,
+      <directive module="core">SetHandler</directive>,
+      <directive module="core">SetInputFilter</directive>,
+      <directive module="core">SetOutputFilter</directive>, and
+      <module>mod_mime</module> Add* and Remove* directives),
+      document meta data (<directive
+      module="mod_headers">Header</directive>, <directive
+      module="mod_headers">RequestHeader</directive>, <directive
+      module="mod_setenvif">SetEnvIf</directive>, <directive
+      module="mod_setenvif">SetEnvIfNoCase</directive>, <directive
+      module="mod_setenvif">BrowserMatch</directive>, <directive
+      module="mod_usertrack">CookieExpires</directive>, <directive
+      module="mod_usertrack">CookieDomain</directive>, <directive
+      module="mod_usertrack">CookieStyle</directive>, <directive
+      module="mod_usertrack">CookieTracking</directive>, <directive
+      module="mod_usertrack">CookieName</directive>),
+      <module>mod_rewrite</module> directives <directive
+      module="mod_rewrite">RewriteEngine</directive>, <directive
+      module="mod_rewrite">RewriteOptions</directive>, <directive
+      module="mod_rewrite">RewriteBase</directive>, <directive
+      module="mod_rewrite">RewriteCond</directive>, <directive
+      module="mod_rewrite">RewriteRule</directive>) and
+      <directive module="mod_actions">Action</directive> from
+      <module>mod_actions</module>.
+      </dd>
+
+      <dt>Indexes</dt>
+
+      <dd>
+      Allow use of the directives controlling directory indexing
+      (<directive
+      module="mod_autoindex">AddDescription</directive>,
+      <directive module="mod_autoindex">AddIcon</directive>, <directive
+      module="mod_autoindex">AddIconByEncoding</directive>,
+      <directive module="mod_autoindex">AddIconByType</directive>,
+      <directive module="mod_autoindex">DefaultIcon</directive>, <directive
+      module="mod_dir">DirectoryIndex</directive>, <directive
+      module="mod_autoindex">FancyIndexing</directive>, <directive
+      module="mod_autoindex">HeaderName</directive>, <directive
+      module="mod_autoindex">IndexIgnore</directive>, <directive
+      module="mod_autoindex">IndexOptions</directive>, <directive
+      module="mod_autoindex">ReadmeName</directive>,
+      <em>etc.</em>).</dd>
+
+      <dt>Limit</dt>
+
+      <dd>
+      Allow use of the directives controlling host access (<directive
+      module="mod_authz_host">Allow</directive>, <directive
+      module="mod_authz_host">Deny</directive> and <directive
+      module="mod_authz_host">Order</directive>).</dd>
+
+      <dt>Options[=<var>Option</var>,...]</dt>
+
+      <dd>
+      Allow use of the directives controlling specific directory
+      features (<directive module="core">Options</directive> and
+      <directive module="mod_include">XBitHack</directive>).
+      An equal sign may be given followed by a comma (but no spaces)
+      separated lists of options that may be set using the <directive
+      module="core">Options</directive> command.</dd>
+    </dl>
+
+    <p>Example:</p>
+
+    <example>
+      AllowOverride AuthConfig Indexes
+    </example>
+
+    <p>In the example above all directives that are neither in the group
+    <code>AuthConfig</code> nor <code>Indexes</code> cause an internal
+    server error.</p>
+
+    <note><p>For security and performance reasons, do not set
+    <code>AllowOverride</code> to anything other than <code>None</code> 
+    in your <code>&lt;Directory /&gt;</code> block. Instead, find (or
+    create) the <code>&lt;Directory&gt;</code> block that refers to the
+    directory where you're actually planning to place a
+    <code>.htaccess</code> file.</p>
+    </note>
+</usage>
+
+<seealso><directive module="core">AccessFileName</directive></seealso>
+<seealso><a href="../configuring.html">Configuration Files</a></seealso>
+<seealso><a href="../howto/htaccess.html">.htaccess Files</a></seealso>
+</directivesynopsis>
+
+<directivesynopsis>
+<name>CGIMapExtension</name>
+<description>Technique for locating the interpreter for CGI
+scripts</description>
+<syntax>CGIMapExtension <var>cgi-path</var> <var>.extension</var></syntax>
+<contextlist><context>directory</context><context>.htaccess</context>
+</contextlist>
+<override>FileInfo</override>
+<compatibility>NetWare only</compatibility>
+
+<usage>
+    <p>This directive is used to control how Apache httpd 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 <code>.foo</code> extension to
+    be passed to the FOO interpreter.</p>
+</usage>
+</directivesynopsis>
+
+<directivesynopsis>
+<name>ContentDigest</name>
+<description>Enables the generation of <code>Content-MD5</code> HTTP Response
+headers</description>
+<syntax>ContentDigest On|Off</syntax>
+<default>ContentDigest Off</default>
+<contextlist><context>server config</context><context>virtual host</context>
+<context>directory</context><context>.htaccess</context>
+</contextlist>
+<override>Options</override>
+<status>Experimental</status>
+
+<usage>
+    <p>This directive enables the generation of
+    <code>Content-MD5</code> headers as defined in RFC1864
+    respectively RFC2616.</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>
+
+    <example>
+      Content-MD5: AuLb7Dp1rqtRtxz2m9kRpA==
+    </example>
+
+    <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 <module>core</module>, and not by any module. For example,
+    SSI documents, output from CGI scripts, and byte range responses
+    do not have this header.</p>
+</usage>
+</directivesynopsis>
+
+<directivesynopsis>
+<name>DefaultType</name>
+<description>This directive has no effect other than to emit warnings
+if the value is not <code>none</code>. In prior versions, DefaultType
+would specify a default media type to assign to response content for
+which no other media type configuration could be found.
+</description>
+<syntax>DefaultType <var>media-type|none</var></syntax>
+<default>DefaultType none</default>
+<contextlist><context>server config</context><context>virtual host</context>
+<context>directory</context><context>.htaccess</context>
+</contextlist>
+<override>FileInfo</override>
+<compatibility>The argument <code>none</code> is available in Apache httpd 2.2.7 and later.  All other choices are DISABLED for 2.3.x and later.</compatibility>
+
+<usage>
+    <p>This directive has been disabled.  For backwards compatibility
+    of configuration files, it may be specified with the value
+    <code>none</code>, meaning no default media type. For example:</p>
+
+    <example>
+      DefaultType None
+    </example>
+
+    <p><code>DefaultType None</code> is only available in
+    httpd-2.2.7 and later.</p>
+
+    <p>Use the mime.types configuration file and the
+    <directive module="mod_mime">AddType</directive> to configure media
+    type assignments via file extensions, or the
+    <directive module="core">ForceType</directive> directive to configure
+    the media type for specific resources. Otherwise, the server will
+    send the response without a Content-Type header field and the
+    recipient may attempt to guess the media type.</p>
+</usage>
+</directivesynopsis>
+
+<directivesynopsis>
+<name>Define</name>
+<description>Define the existence of a variable</description>
+<syntax>Define <var>parameter-name</var></syntax>
+<contextlist><context>server config</context></contextlist>
+
+<usage>
+    <p>Equivalent to passing the <code>-D</code> argument to <program
+    >httpd</program>.</p>
+    <p>This directive can be used to toggle the use of <directive module="core"
+    type="section">IfDefine</directive> sections without needing to alter
+    <code>-D</code> arguments in any startup scripts.</p>
+</usage>
+</directivesynopsis>
+
+<directivesynopsis type="section">
+<name>Directory</name>
+<description>Enclose a group of directives that apply only to the
+named file-system directory, sub-directories, and their contents.</description>
+<syntax>&lt;Directory <var>directory-path</var>&gt;
+... &lt;/Directory&gt;</syntax>
+<contextlist><context>server config</context><context>virtual host</context>
+</contextlist>
+
+<usage>
+    <p><directive type="section">Directory</directive> and
+    <code>&lt;/Directory&gt;</code> are used to enclose a group of
+    directives that will apply only to the named directory,
+    sub-directories of that directory, and the files within the respective 
+    directories.  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, <code>?</code> matches
+    any single character, and <code>*</code> matches any sequences of
+    characters. You may also use <code>[]</code> character ranges. None
+    of the wildcards match a `/' character, so <code>&lt;Directory
+    /*/public_html&gt;</code> will not match
+    <code>/home/user/public_html</code>, but <code>&lt;Directory
+    /home/*/public_html&gt;</code> will match. Example:</p>
+
+    <example>
+      &lt;Directory /usr/local/httpd/htdocs&gt;<br />
+      <indent>
+        Options Indexes FollowSymLinks<br />
+      </indent>
+      &lt;/Directory&gt;
+    </example>
+
+    <note>
+      <p>Be careful with the <var>directory-path</var> arguments:
+      They have to literally match the filesystem path which Apache httpd uses
+      to access the files. Directives applied to a particular
+      <code>&lt;Directory&gt;</code> will not apply to files accessed from
+      that same directory via a different path, such as via different symbolic
+      links.</p>
+    </note>
+
+    <p><glossary ref="regex">Regular
+    expressions</glossary> can also be used, with the addition of the
+    <code>~</code> character. For example:</p>
+
+    <example>
+      &lt;Directory ~ "^/www/.*/[0-9]{3}"&gt;
+    </example>
+
+    <p>would match directories in <code>/www/</code> that consisted of
+    three numbers.</p>
+
+    <p>If multiple (non-regular expression) <directive
+    type="section">Directory</directive> sections
+    match the directory (or one of 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>
+
+    <example>
+      &lt;Directory /&gt;<br />
+      <indent>
+        AllowOverride None<br />
+      </indent>
+      &lt;/Directory&gt;<br />
+      <br />
+      &lt;Directory /home/&gt;<br />
+      <indent>
+        AllowOverride FileInfo<br />
+      </indent>
+      &lt;/Directory&gt;
+    </example>
+
+    <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</code>).</li>
+
+      <li>Apply any <code>FileInfo</code> directives in
+      <code>/home/.htaccess</code>, <code>/home/web/.htaccess</code> and
+      <code>/home/web/dir/.htaccess</code> in that order.</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>
+
+    <example>
+      &lt;Directory ~ abc$&gt;<br />
+      <indent>
+        # ... directives here ...<br />
+      </indent>
+      &lt;/Directory&gt;
+    </example>
+
+    <p>the regular expression section won't be considered until after
+    all normal <directive type="section">Directory</directive>s and
+    <code>.htaccess</code> files have been applied. Then the regular
+    expression will match on <code>/home/abc/public_html/abc</code> and
+    the corresponding <directive type="section">Directory</directive> will
+    be applied.</p>
+
+   <p><strong>Note that the default access for
+    <code>&lt;Directory /&gt;</code> is <code>Allow from All</code>.
+    This means that Apache httpd will serve any file mapped from an URL. It is
+    recommended that you change this with a block such
+    as</strong></p>
+
+    <example>
+      &lt;Directory /&gt;<br />
+      <indent>
+        Order Deny,Allow<br />
+        Deny from All<br />
+      </indent>
+      &lt;/Directory&gt;
+    </example>
+
+    <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 occur in the <code>httpd.conf</code> file.
+    <directive type="section">Directory</directive> directives
+    cannot nest, and cannot appear in a <directive module="core"
+    type="section">Limit</directive> or <directive module="core"
+    type="section">LimitExcept</directive> section.</p>
+</usage>
+<seealso><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</seealso>
+</directivesynopsis>
+
+<directivesynopsis type="section">
+<name>DirectoryMatch</name>
+<description>Enclose directives that apply to
+the contents of file-system directories matching a regular expression.</description>
+<syntax>&lt;DirectoryMatch <var>regex</var>&gt;
+... &lt;/DirectoryMatch&gt;</syntax>
+<contextlist><context>server config</context><context>virtual host</context>
+</contextlist>
+
+<usage>
+    <p><directive type="section">DirectoryMatch</directive> and
+    <code>&lt;/DirectoryMatch&gt;</code> are used to enclose a group
+    of directives which will apply only to the named directory (and the files within), 
+    the same as <directive module="core" type="section">Directory</directive>. 
+    However, it takes as an argument a 
+    <glossary ref="regex">regular expression</glossary>.  For example:</p>
+
+    <example>
+      &lt;DirectoryMatch "^/www/(.+/)?[0-9]{3}"&gt;
+    </example>
+
+    <p>would match directories in <code>/www/</code> that consisted of three
+    numbers.</p>
+
+   <note><title>Compatability</title>
+      Prior to 2.3.9, this directive implicitly applied to sub-directories
+      (like <directive module="core" type="section">Directory</directive>) and
+      could not match the end of line symbol ($).  In 2.3.9 and later,
+      only directories that match the expression are affected by the enclosed
+      directives.
+    </note>
+
+    <note><title>Trailing Slash</title>
+      This directive applies to requests for directories that may or may 
+      not end in a trailing slash, so expressions that are anchored to the 
+      end of line ($) must be written with care.
+    </note>
+</usage>
+<seealso><directive type="section" module="core">Directory</directive> for
+a description of how regular expressions are mixed in with normal
+<directive type="section">Directory</directive>s</seealso>
+<seealso><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</seealso>
+</directivesynopsis>
+
+<directivesynopsis>
+<name>DocumentRoot</name>
+<description>Directory that forms the main document tree visible
+from the web</description>
+<syntax>DocumentRoot <var>directory-path</var></syntax>
+<default>DocumentRoot /usr/local/apache/htdocs</default>
+<contextlist><context>server config</context><context>virtual host</context>
+</contextlist>
+
+<usage>
+    <p>This directive sets the directory from which <program>httpd</program>
+    will serve files. Unless matched by a directive like <directive
+    module="mod_alias">Alias</directive>, the server appends the
+    path from the requested URL to the document root to make the
+    path to the document. Example:</p>
+
+    <example>
+      DocumentRoot /usr/web
+    </example>
+
+    <p>then an access to
+    <code>http://www.my.host.com/index.html</code> refers to
+    <code>/usr/web/index.html</code>. If the <var>directory-path</var> is 
+    not absolute then it is assumed to be relative to the <directive 
+    module="core">ServerRoot</directive>.</p>
+
+    <p>The <directive>DocumentRoot</directive> should be specified without
+    a trailing slash.</p>
+</usage>
+<seealso><a href="../urlmapping.html#documentroot">Mapping URLs to Filesystem
+Locations</a></seealso>
+</directivesynopsis>
+
+<directivesynopsis>
+<name>EnableMMAP</name>
+<description>Use memory-mapping to read files during delivery</description>
+<syntax>EnableMMAP On|Off</syntax>
+<default>EnableMMAP On</default>
+<contextlist><context>server config</context><context>virtual host</context>
+<context>directory</context><context>.htaccess</context>
+</contextlist>
+<override>FileInfo</override>
+
+<usage>
+    <p>This directive controls whether the <program>httpd</program> 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 <module>mod_include</module> -- Apache httpd
+    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 <program>httpd</program>.</li>
+    <li>Deleting or truncating a file while <program>httpd</program>
+      has it memory-mapped can cause <program>httpd</program> to
+      crash with a segmentation fault.
+    </li>
+    </ul>
+
+    <p>For server configurations that are vulnerable to these problems,
+    you should disable memory-mapping of delivered files by specifying:</p>
+
+    <example>
+      EnableMMAP Off
+    </example>
+
+    <p>For NFS mounted files, this feature may be disabled explicitly for
+    the offending files by specifying:</p>
+
+    <example>
+      &lt;Directory "/path-to-nfs-files"&gt;
+      <indent>
+        EnableMMAP Off
+      </indent>
+      &lt;/Directory&gt;
+    </example>
+</usage>
+</directivesynopsis>
+
+<directivesynopsis>
+<name>EnableSendfile</name>
+<description>Use the kernel sendfile support to deliver files to the client</description>
+<syntax>EnableSendfile On|Off</syntax>
+<default>EnableSendfile Off</default>
+<contextlist><context>server config</context><context>virtual host</context>
+<context>directory</context><context>.htaccess</context>
+</contextlist>
+<override>FileInfo</override>
+<compatibility>Available in version 2.0.44 and later. Default changed to Off in
+version 2.3.9.</compatibility>
+
+<usage>
+    <p>This directive controls whether <program>httpd</program> 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 httpd uses sendfile to deliver the file contents
+    without ever reading the file if the OS supports it.</p>
+
+    <p>This sendfile mechanism avoids separate 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>On Linux the use of sendfile triggers TCP-checksum
+    offloading bugs on certain networking cards when using IPv6.</li>
+    <li>On Linux on Itanium, sendfile may be unable to handle files
+    over 2GB in size.</li>
+    <li>With a network-mounted <directive
+    module="core">DocumentRoot</directive> (e.g., NFS, SMB, CIFS, FUSE),
+    the kernel may be unable to serve the network file through
+    its own cache.</li>
+    </ul>
+
+    <p>For server configurations that are not vulnerable to these problems,
+    you may enable this feature by specifying:</p>
+
+    <example>
+      EnableSendfile On
+    </example>
+
+    <p>For network mounted files, this feature may be disabled explicitly
+    for the offending files by specifying:</p>
+
+    <example>
+      &lt;Directory "/path-to-nfs-files"&gt;
+      <indent>
+        EnableSendfile Off
+      </indent>
+      &lt;/Directory&gt;
+    </example>
+    <p>Please note that the per-directory and .htaccess configuration
+       of <directive>EnableSendfile</directive> is not supported by
+       <module>mod_cache_disk</module>.
+       Only global definition of <directive>EnableSendfile</directive>
+       is taken into account by the module.
+    </p>
+</usage>
+</directivesynopsis>
+
+<directivesynopsis>
+<name>Error</name>
+<description>Abort configuration parsing with a custom error message</description>
+<syntax>Error <var>message</var></syntax>
+<contextlist><context>server config</context><context>virtual host</context>
+<context>directory</context><context>.htaccess</context>
+</contextlist>
+<compatibility>2.3.9 and later</compatibility>
+
+<usage>
+    <p>If an error can be detected within the configuration, this
+    directive can be used to generate a custom error message, and halt
+    configuration parsing.  The typical use is for reporting required
+    modules which are missing from the configuration.</p>
+
+    <example><title>Example</title>
+      # ensure that mod_include is loaded<br />
+      &lt;IfModule !include_module&gt;<br />
+      Error mod_include is required by mod_foo.  Load it with LoadModule.<br />
+      &lt;/IfModule&gt;<br />
+      <br />
+      # ensure that exactly one of SSL,NOSSL is defined<br />
+      &lt;IfDefine SSL&gt;<br />
+      &lt;IfDefine NOSSL&gt;<br />
+      Error Both SSL and NOSSL are defined.  Define only one of them.<br />
+      &lt;/IfDefine&gt;<br />
+      &lt;/IfDefine&gt;<br />
+      &lt;IfDefine !SSL&gt;<br />
+      &lt;IfDefine !NOSSL&gt;<br />
+      Error Either SSL or NOSSL must be defined.<br />
+      &lt;/IfDefine&gt;<br />
+      &lt;/IfDefine&gt;<br />
+    </example>
+
+</usage>
+</directivesynopsis>
+
+<directivesynopsis>
+<name>ErrorDocument</name>
+<description>What the server will return to the client
+in case of an error</description>
+<syntax>ErrorDocument <var>error-code</var> <var>document</var></syntax>
+<contextlist><context>server config</context><context>virtual host</context>
+<context>directory</context><context>.htaccess</context>
+</contextlist>
+<override>FileInfo</override>
+<compatibility>Quoting syntax for text messages is different in Apache HTTP Server
+2.0</compatibility>
+
+<usage>
+    <p>In the event of a problem or error, Apache httpd 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 <directive>ErrorDocument</directive>
+    directive, which is followed by the HTTP response code and a URL
+    or a message. Apache httpd will sometimes offer additional information
+    regarding the problem/error.</p>
+
+    <p>URLs can begin with a slash (/) for local web-paths (relative
+    to the <directive module="core">DocumentRoot</directive>), or be a
+    full URL which the client can resolve. Alternatively, a message
+    can be provided to be displayed by the browser. Examples:</p>
+
+    <example>
+      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"
+    </example>
+
+    <p>Additionally, the special value <code>default</code> can be used
+    to specify Apache httpd's simple hardcoded message.  While not required
+    under normal circumstances, <code>default</code> will restore
+    Apache httpd's simple hardcoded message for configurations that would
+    otherwise inherit an existing <directive>ErrorDocument</directive>.</p>
+
+    <example>
+      ErrorDocument 404 /cgi-bin/bad_urls.pl<br /><br />
+      &lt;Directory /web/docs&gt;<br />
+      <indent>
+        ErrorDocument 404 default<br />
+      </indent>
+      &lt;/Directory&gt;
+    </example>
+
+    <p>Note that when you specify an <directive>ErrorDocument</directive>
+    that points to a remote URL (ie. anything with a method such as
+    <code>http</code> in front of it), Apache HTTP Server 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
+    <code>ErrorDocument 401</code> directive then it must refer to a local
+    document.</strong></p>
+
+    <p>Microsoft Internet Explorer (MSIE) will by default 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 Knowledge Base article <a
+    href="http://support.microsoft.com/default.aspx?scid=kb;en-us;Q294807"
+    >Q294807</a>.</p>
+
+    <p>Although most error messages can be overriden, there are certain
+    circumstances where the internal messages are used regardless of the
+    setting of <directive module="core">ErrorDocument</directive>.  In
+    particular, if a malformed request is detected, normal request processing
+    will be immediately halted and the internal error message returned.
+    This is necessary to guard against security problems caused by
+    bad requests.</p>
+   
+    <p>If you are using mod_proxy, you may wish to enable
+    <directive module="mod_proxy">ProxyErrorOverride</directive> so that you can provide
+    custom error messages on behalf of your Origin servers. If you don't enable ProxyErrorOverride,
+    Apache httpd will not generate custom error documents for proxied content.</p>
+</usage>
+
+<seealso><a href="../custom-error.html">documentation of
+    customizable responses</a></seealso>
+</directivesynopsis>
+
+<directivesynopsis>
+<name>ErrorLog</name>
+<description>Location where the server will log errors</description>
+<syntax> ErrorLog <var>file-path</var>|syslog[:<var>facility</var>]</syntax>
+<default>ErrorLog logs/error_log (Unix) ErrorLog logs/error.log (Windows and OS/2)</default>
+<contextlist><context>server config</context><context>virtual host</context>
+</contextlist>
+
+<usage>
+    <p>The <directive>ErrorLog</directive> directive sets the name of
+    the file to which the server will log any errors it encounters. If
+    the <var>file-path</var> is not absolute then it is assumed to be 
+    relative to the <directive module="core">ServerRoot</directive>.</p>
+
+    <example><title>Example</title>
+    ErrorLog /var/log/httpd/error_log
+    </example>
+
+    <p>If the <var>file-path</var>
+    begins with a pipe character "<code>|</code>" then it is assumed to be a
+    command to spawn to handle the error log.</p>
+
+    <example><title>Example</title>
+    ErrorLog "|/usr/local/bin/httpd_errors"
+    </example>
+
+    <p>See the notes on <a href="../logs.html#piped">piped logs</a> for
+    more information.</p>
+
+    <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).  The facility is effectively global, and if it is changed
+    in individual virtual hosts, the final facility specified affects the
+    entire server.</p>
+
+    <example><title>Example</title>
+    ErrorLog syslog:user
+    </example>
+
+    <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 log files are stored is writable by
+    anyone other than the user that starts the server.</p>
+    <note type="warning"><title>Note</title>
+      <p>When entering a file path on non-Unix platforms, care should be taken
+      to make sure that only forward slashed are used even though the platform
+      may allow the use of back slashes. In general it is a good idea to always 
+      use forward slashes throughout the configuration files.</p>
+    </note>
+</usage>
+<seealso><directive module="core">LogLevel</directive></seealso>
+<seealso><a href="../logs.html">Apache HTTP Server Log Files</a></seealso>
+</directivesynopsis>
+
+<directivesynopsis>
+<name>ErrorLogFormat</name>
+<description>Format specification for error log entries</description>
+<syntax> ErrorLog [connection|request] <var>format</var></syntax>
+<contextlist><context>server config</context><context>virtual host</context>
+</contextlist>
+<compatibility>Available in Apache httpd 2.3.9 and later</compatibility>
+
+<usage>
+    <p><directive>ErrorLogFormat</directive> allows to specify what
+    supplementary information is logged in the error log in addition to the
+    actual log message.</p>
+
+    <example><title>Simple example</title>
+        ErrorLogFormat "[%t] [%l] [pid %P] %F: %E: [client %a] %M"
+    </example>
+
+    <p>Specifying <code>connection</code> or <code>request</code> as first
+    paramter allows to specify additional formats, causing additional
+    information to be logged when the first message is logged for a specific
+    connection or request, respectivly. This additional information is only
+    logged once per connection/request. If a connection or request is processed
+    without causing any log message, the additional information is not logged
+    either.</p>
+
+    <p>It can happen that some format string items do not produce output.  For
+    example, the Referer header is only present if the log message is
+    associated to a request and the log message happens at a time when the
+    Referer header has already been read from the client.  If no output is
+    produced, the default behaviour is to delete everything from the preceeding
+    space character to the next space character.  This means the log line is
+    implicitly divided into fields on non-whitespace to whitespace transitions.
+    If a format string item does not produce output, the whole field is
+    ommitted.  For example, if the remote address <code>%a</code> in the log
+    format <code>[%t] [%l] [%a] %M&nbsp;</code> is not available, the surrounding
+    brackets are not logged either.  Space characters can be escaped with a
+    backslash to prevent them from delimiting a field.  The combination '%&nbsp;'
+    (percent space) is a zero-witdh field delimiter that does not produce any
+    output.</p>
+
+    <p>The above behaviour can be changed by adding modifiers to the format
+    string item. A <code>-</code> (minus) modifier causes a minus to be logged if the
+    respective item does not produce any output. In once-per-connection/request
+    formats, it is also possible to use the <code>+</code> (plus) modifier. If an
+    item with the plus modifier does not produce any output, the whole line is
+    ommitted.</p>
+
+    <p>A number as modifier can be used to assign a log severity level to a
+    format item. The item will only be logged if the severity of the log
+    message is not higher than the specified log severity level. The number can
+    range from 1 (alert) over 4 (warn) and 7 (debug) to 15 (trace8).</p>
+
+    <p>Some format string items accept additional parameters in braces.</p>
+
+    <table border="1" style="zebra">
+    <columnspec><column width=".2"/><column width=".8"/></columnspec>
+
+    <tr><th>Format&nbsp;String</th> <th>Description</th></tr>
+
+    <tr><td><code>%%</code></td>
+        <td>The percent sign</td></tr>
+
+    <tr><td><code>%...a</code></td>
+        <td>Remote IP-address and port</td></tr>
+
+    <tr><td><code>%...A</code></td>
+        <td>Local IP-address and port</td></tr>
+
+    <tr><td><code>%...{name}e</code></td>
+        <td>Request environment variable <code>name</code></td></tr>
+
+    <tr><td><code>%...E</code></td>
+        <td>APR/OS error status code and string</td></tr>
+
+    <tr><td><code>%...F</code></td>
+        <td>Source file name and line number of the log call</td></tr>
+
+    <tr><td><code>%...{name}i</code></td>
+        <td>Request header <code>name</code></td></tr>
+
+    <tr><td><code>%...k</code></td>
+        <td>Number of keep-alive requests on this connection</td></tr>
+
+    <tr><td><code>%...l</code></td>
+        <td>Loglevel of the message</td></tr>
+
+    <tr><td><code>%...L</code></td>
+        <td>Log ID of the request</td></tr>
+
+    <tr><td><code>%...{c}L</code></td>
+        <td>Log ID of the connection</td></tr>
+
+    <tr><td><code>%...{C}L</code></td>
+        <td>Log ID of the connection if used in connection scope, empty otherwise</td></tr>
+
+    <tr><td><code>%...m</code></td>
+        <td>Name of the module logging the message</td></tr>
+
+    <tr><td><code>%M</code></td>
+        <td>The actual log message</td></tr>
+
+    <tr><td><code>%...{name}n</code></td>
+        <td>Request note <code>name</code></td></tr>
+
+    <tr><td><code>%...P</code></td>
+        <td>Process ID of current process</td></tr>
+
+    <tr><td><code>%...T</code></td>
+        <td>Thread ID of current thread</td></tr>
+
+    <tr><td><code>%...t</code></td>
+        <td>The current time</td></tr>
+
+    <tr><td><code>%...{u}t</code></td>
+        <td>The current time including micro-seconds</td></tr>
+
+    <tr><td><code>%...{cu}t</code></td>
+        <td>The current time in compact ISO 8601 format, including
+            micro-seconds</td></tr>
+
+    <tr><td><code>%...v</code></td>
+        <td>The canonical <directive module="core">ServerName</directive>
+            of the current server.</td></tr>
+
+    <tr><td><code>%...V</code></td>
+        <td>The server name of the server serving the request according to the
+            <directive module="core" >UseCanonicalName</directive>
+            setting.</td></tr>
+
+    <tr><td><code>\&nbsp;</code> (backslash space)</td>
+        <td>Non-field delimiting space</td></tr>
+
+    <tr><td><code>%&nbsp;</code> (percent space)</td>
+        <td>Field delimiter (no output)</td></tr>
+    </table>
+
+    <p>The log ID format <code>%L</code> produces a unique id for a connection
+    or request. This can be used to correlate which log lines belong to the
+    same connection or request, which request happens on which connection.
+    A <code>%L</code> format string is also available in
+    <module>mod_log_config</module>, to allow to correlate access log entries
+    with error log lines. If <module>mod_unique_id</module> is loaded, its
+    unique id will be used as log ID for requests.</p>
+
+    <example><title>Example (somewhat similar to default format)</title>
+        ErrorLogFormat "[%{u}t] [%-m:%l] [pid %P] %7F: %E: [client\ %a]
+        %M%&nbsp;,\&nbsp;referer\&nbsp;%{Referer}i"
+    </example>
+
+    <example><title>Example (similar to the 2.2.x format)</title>
+        ErrorLogFormat "[%t] [%l] %7F: %E: [client\ %a]
+        %M%&nbsp;,\&nbsp;referer\&nbsp;%{Referer}i"
+    </example>
+
+    <example><title>Advanced example with request/connection log IDs</title>
+        ErrorLogFormat "[%{uc}t] [%-m:%-l] [R:%L] [C:%{C}L] %7F: %E: %M"<br/>
+        ErrorLogFormat request "[%{uc}t] [R:%L] Request %k on C:%{c}L pid:%P tid:%T"<br/>
+        ErrorLogFormat request "[%{uc}t] [R:%L] UA:'%+{User-Agent}i'"<br/>
+        ErrorLogFormat request "[%{uc}t] [R:%L] Referer:'%+{Referer}i'"<br/>
+        ErrorLogFormat connection "[%{uc}t] [C:%{c}L] local\ %a remote\ %A"<br/>
+    </example>
+
+</usage>
+<seealso><directive module="core">ErrorLog</directive></seealso>
+<seealso><directive module="core">LogLevel</directive></seealso>
+<seealso><a href="../logs.html">Apache HTTP Server Log Files</a></seealso>
+</directivesynopsis>
+
+<directivesynopsis>
+<name>ExtendedStatus</name>
+<description>Keep track of extended status information for each 
+request</description>
+<syntax>ExtendedStatus On|Off</syntax>
+<default>ExtendedStatus Off[*]</default>
+<contextlist><context>server config</context></contextlist>
+
+<usage>
+    <p>This option tracks additional data per worker about the
+    currently executing request, and a utilization summary; you 
+    can see these variables during runtime by configuring 
+    <module>mod_status</module>.  Note that other modules may
+    rely on this scoreboard.</p>
+
+    <p>This setting applies to the entire server, and cannot be
+    enabled or disabled on a virtualhost-by-virtualhost basis.
+    The collection of extended status information can slow down
+    the server.  Also note that this setting cannot be changed
+    during a graceful restart.</p>
+
+    <note>
+    <p>Note that loading <module>mod_status</module> will change 
+    the default behavior to ExtendedStatus On, while other
+    third party modules may do the same.  Such modules rely on
+    collecting detailed information about the state of all workers.
+    The default is changed by <module>mod_status</module> beginning
+    with version 2.3.6; the previous default was always Off.</p>
+    </note>
+
+</usage>
+
+</directivesynopsis>
+
+<directivesynopsis>
+<name>FileETag</name>
+<description>File attributes used to create the ETag
+HTTP response header for static files</description>
+<syntax>FileETag <var>component</var> ...</syntax>
+<default>FileETag INode MTime Size</default>
+<contextlist><context>server config</context><context>virtual host</context>
+<context>directory</context><context>.htaccess</context>
+</contextlist>
+<override>FileInfo</override>
+
+<usage>
+    <p>
+    The <directive>FileETag</directive> directive configures the file
+    attributes that are used to create the <code>ETag</code> (entity
+    tag) response header field when the document is based on a static file.
+    (The <code>ETag</code> value is used in cache management to save
+    network bandwidth.) The
+    <directive>FileETag</directive> 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:
+         <example>FileETag INode MTime Size</example></dd>
+     <dt><strong>None</strong></dt>
+     <dd>If a document is file-based, no <code>ETag</code> 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&nbsp;INode&nbsp;MTime&nbsp;Size</code>, and a
+    subdirectory's includes <code>FileETag&nbsp;-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&nbsp;MTime&nbsp;Size</code>.</p>
+    <note type="warning"><title>Warning</title>
+    Do not change the default for directories or locations that have WebDAV
+    enabled and use <module>mod_dav_fs</module> as a storage provider.
+    <module>mod_dav_fs</module> uses <code>INode&nbsp;MTime&nbsp;Size</code>
+    as a fixed format for <code>ETag</code> comparisons on conditional requests.
+    These conditional requests will break if the <code>ETag</code> format is
+    changed via <directive>FileETag</directive>.
+    </note>
+    <note><title>Server Side Includes</title>
+    An ETag is not generated for responses parsed by <module>mod_include</module>, 
+    since the response entity can change without a change of the INode, MTime, or Size 
+    of the static file with embedded SSI directives.
+    </note>
+
+</usage>
+</directivesynopsis>
+
+<directivesynopsis type="section">
+<name>Files</name>
+<description>Contains directives that apply to matched
+filenames</description>
+<syntax>&lt;Files <var>filename</var>&gt; ... &lt;/Files&gt;</syntax>
+<contextlist><context>server config</context><context>virtual host</context>
+<context>directory</context><context>.htaccess</context>
+</contextlist>
+<override>All</override>
+
+<usage>
+    <p>The <directive type="section">Files</directive> directive
+    limits the scope of the enclosed directives by filename. It is comparable
+    to the <directive module="core" type="section">Directory</directive>
+    and <directive module="core" type="section">Location</directive>
+    directives. It should be matched with a <code>&lt;/Files&gt;</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. <directive type="section">Files</directive>
+    sections are processed in the order they appear in the
+    configuration file, after the <directive module="core"
+    type="section">Directory</directive> sections and
+    <code>.htaccess</code> files are read, but before <directive
+    type="section" module="core">Location</directive> sections. Note
+    that <directive type="section">Files</directive> can be nested
+    inside <directive type="section"
+    module="core">Directory</directive> 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 <code>?</code> matches any single character,
+    and <code>*</code> matches any sequences of characters.
+    <glossary ref="regex">Regular expressions</glossary> 
+    can also be used, with the addition of the
+    <code>~</code> character. For example:</p>
+
+    <example>
+      &lt;Files ~ "\.(gif|jpe?g|png)$"&gt;
+    </example>
+
+    <p>would match most common Internet graphics formats. <directive
+    module="core" type="section">FilesMatch</directive> is preferred,
+    however.</p>
+
+    <p>Note that unlike <directive type="section"
+    module="core">Directory</directive> and <directive type="section"
+    module="core">Location</directive> sections, <directive
+    type="section">Files</directive> sections can be used inside
+    <code>.htaccess</code> files. This allows users to control access to
+    their own files, at a file-by-file level.</p>
+
+</usage>
+<seealso><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</seealso>
+</directivesynopsis>
+
+<directivesynopsis type="section">
+<name>FilesMatch</name>
+<description>Contains directives that apply to regular-expression matched
+filenames</description>
+<syntax>&lt;FilesMatch <var>regex</var>&gt; ... &lt;/FilesMatch&gt;</syntax>
+<contextlist><context>server config</context><context>virtual host</context>
+<context>directory</context><context>.htaccess</context>
+</contextlist>
+<override>All</override>
+
+<usage>
+    <p>The <directive type="section">FilesMatch</directive> directive
+    limits the scope of the enclosed directives by filename, just as the
+    <directive module="core" type="section">Files</directive> directive
+    does. However, it accepts a <glossary ref="regex">regular 
+    expression</glossary>. For example:</p>
+
+    <example>
+      &lt;FilesMatch "\.(gif|jpe?g|png)$"&gt;
+    </example>
+
+    <p>would match most common Internet graphics formats.</p>
+</usage>
+
+<seealso><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</seealso>
+</directivesynopsis>
+
+<directivesynopsis>
+<name>ForceType</name>
+<description>Forces all matching files to be served with the specified
+media type in the HTTP Content-Type header field</description>
+<syntax>ForceType <var>media-type</var>|None</syntax>
+<contextlist><context>directory</context><context>.htaccess</context>
+</contextlist>
+<override>FileInfo</override>
+<compatibility>Moved to the core in Apache httpd 2.0</compatibility>
+
+<usage>
+    <p>When placed into an <code>.htaccess</code> file or a
+    <directive type="section" module="core">Directory</directive>, or
+    <directive type="section" module="core">Location</directive> or
+    <directive type="section" module="core">Files</directive>
+    section, this directive forces all matching files to be served
+    with the content type identification given by
+    <var>media-type</var>. For example, if you had a directory full of
+    GIF files, but did not want to label them all with <code>.gif</code>,
+    you might want to use:</p>
+
+    <example>
+      ForceType image/gif
+    </example>
+
+    <p>Note that this directive overrides other indirect media type
+    associations defined in mime.types or via the
+    <directive module="mod_mime">AddType</directive>.</p>
+
+    <p>You can also override more general
+    <directive>ForceType</directive> settings
+    by using the value of <code>None</code>:</p>
+
+    <example>
+      # force all files to be image/gif:<br />
+      &lt;Location /images&gt;<br />
+        <indent>
+          ForceType image/gif<br />
+        </indent>
+      &lt;/Location&gt;<br />
+      <br />
+      # but normal mime-type associations here:<br />
+      &lt;Location /images/mixed&gt;<br />
+      <indent>
+        ForceType None<br />
+      </indent>
+      &lt;/Location&gt;
+    </example>
+
+    <p>This directive primarily overrides the content types generated for
+    static files served out of the filesystem.  For resources other than 
+    static files, where the generator of the response typically specifies 
+    a Content-Type, this directive has no effect.</p>
+
+</usage>
+</directivesynopsis>
+<directivesynopsis>
+<name>GprofDir</name>
+<description>Directory to write gmon.out profiling data to.  </description>
+<syntax>GprofDir <var>/tmp/gprof/</var>|<var>/tmp/gprof/</var>%</syntax>
+<contextlist><context>server config</context><context>virtual host</context>
+</contextlist>
+
+<usage>
+    <p>When the server has been compiled with gprof profiling suppport,
+    <directive>GprofDir</directive> causes <code>gmon.out</code> files to
+    be written to the specified directory when the process exits.  If the
+    argument ends with a percent symbol ('%'), subdirectories are created
+    for each process id.</p>
+
+    <p>This directive currently only works with the <module>prefork</module> 
+    MPM.</p>
+</usage>
+</directivesynopsis>
+
+<directivesynopsis>
+<name>HostnameLookups</name>
+<description>Enables DNS lookups on client IP addresses</description>
+<syntax>HostnameLookups On|Off|Double</syntax>
+<default>HostnameLookups Off</default>
+<contextlist><context>server config</context><context>virtual host</context>
+<context>directory</context></contextlist>
+
+<usage>
+    <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 lookup. 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 <module>mod_authz_host</module> 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 <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 <program>logresolve</program>, 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>
+</usage>
+</directivesynopsis>
+
+<directivesynopsis type="section">
+<name>If</name>
+<description>Contains directives that apply only if a condition is
+satisfied by a request at runtime</description>
+<syntax>&lt;If <var>expression</var>&gt; ... &lt;/If&gt;</syntax>
+<contextlist><context>server config</context><context>virtual host</context>
+<context>directory</context><context>.htaccess</context>
+</contextlist>
+<override>All</override>
+
+<usage>
+    <p>The <directive type="section">If</directive> directive
+    evaluates an expression at runtime, and applies the enclosed
+    directives if and only if the expression evaluates to true.
+    For example:</p>
+
+    <example>
+        &lt;If "$req{Host} = ''"&gt;
+    </example>
+
+    <p>would match HTTP/1.0 requests without a <var>Host:</var> header.</p>
+
+    <p>You may compare the value of any variable in the request headers
+    ($req), response headers ($resp) or environment ($env) in your
+    expression.</p>
+
+    <p>Apart from <code>=</code>, <code>If</code> can use the <code>IN</code>
+    operator to compare if the expression is in a given range:</p>
+
+    <example>
+        &lt;If %{REQUEST_METHOD} IN GET,HEAD,OPTIONS&gt;
+    </example>
+
+</usage>
+
+<seealso><a href="../expr.html">Expressions in Apache HTTP Server</a>,
+for a complete reference and more examples.</seealso>
+<seealso><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.
+    <directive type="section">If</directive> has the same precedence
+    and usage as <directive type="section">Files</directive></seealso>
+</directivesynopsis>
+
+<directivesynopsis type="section">
+<name>IfDefine</name>
+<description>Encloses directives that will be processed only
+if a test is true at startup</description>
+<syntax>&lt;IfDefine [!]<var>parameter-name</var>&gt; ...
+    &lt;/IfDefine&gt;</syntax>
+<contextlist><context>server config</context><context>virtual host</context>
+<context>directory</context><context>.htaccess</context>
+</contextlist>
+<override>All</override>
+
+<usage>
+    <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 <directive type="section">IfDefine</directive>
+    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 <directive type="section"
+    >IfDefine</directive> 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
+    <program>httpd</program> command line via <code>-D<var>parameter</var>
+    </code> at the time the server was started or by the <directive
+    module="core">Define</directive> directive.</p>
+
+    <p><directive type="section">IfDefine</directive> sections are
+    nest-able, which can be used to implement simple
+    multiple-parameter tests. Example:</p>
+
+    <example>
+      httpd -DReverseProxy -DUseCache -DMemCache ...<br />
+      <br />
+      # httpd.conf<br />
+      &lt;IfDefine ReverseProxy&gt;<br />
+      <indent>
+        LoadModule proxy_module   modules/mod_proxy.so<br />
+        LoadModule proxy_http_module   modules/mod_proxy_http.so<br />
+        &lt;IfDefine UseCache&gt;<br />
+        <indent>
+          LoadModule cache_module   modules/mod_cache.so<br />
+          &lt;IfDefine MemCache&gt;<br />
+          <indent>
+            LoadModule mem_cache_module   modules/mod_mem_cache.so<br />
+          </indent>
+          &lt;/IfDefine&gt;<br />
+          &lt;IfDefine !MemCache&gt;<br />
+          <indent>
+            LoadModule cache_disk_module   modules/mod_cache_disk.so<br />
+          </indent>
+          &lt;/IfDefine&gt;
+        </indent>
+        &lt;/IfDefine&gt;
+      </indent>
+      &lt;/IfDefine&gt;
+    </example>
+</usage>
+</directivesynopsis>
+
+<directivesynopsis type="section">
+<name>IfModule</name>
+<description>Encloses directives that are processed conditional on the
+presence or absence of a specific module</description>
+<syntax>&lt;IfModule [!]<var>module-file</var>|<var>module-identifier</var>&gt; ...
+    &lt;/IfModule&gt;</syntax>
+<contextlist><context>server config</context><context>virtual host</context>
+<context>directory</context><context>.htaccess</context>
+</contextlist>
+<override>All</override>
+<compatibility>Module identifiers are available in version 2.1 and
+later.</compatibility>
+
+<usage>
+    <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 <directive type="section"
+    >IfModule</directive> 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 <directive type="section"
+    >IfModule</directive> 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 <directive module="mod_so"
+    >LoadModule</directive>. 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><directive type="section">IfModule</directive> sections are
+    nest-able, which can be used to implement simple multiple-module
+    tests.</p>
+
+    <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 <directive type="section">IfModule</directive>
+    sections.</note>
+</usage>
+</directivesynopsis>
+
+<directivesynopsis>
+<name>Include</name>
+<description>Includes other configuration files from within
+the server configuration files</description>
+<syntax>Include [<var>optional</var>|<var>strict</var>] <var>file-path</var>|<var>directory-path</var>|<var>wildcard</var></syntax>
+<contextlist><context>server config</context><context>virtual host</context>
+<context>directory</context>
+</contextlist>
+<compatibility>Wildcard matching available in 2.0.41 and later, directory
+wildcard matching available in 2.3.6 and later</compatibility>
+
+<usage>
+    <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
+    <directive>Include</directive> 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
+    <program>httpd</program> 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>When a wildcard is specified for a <strong>file</strong> component of
+    the path, and no file matches the wildcard, the
+    <directive module="core">Include</directive>
+    directive will be <strong>silently ignored</strong>. When a wildcard is
+    specified for a <strong>directory</strong> component of the path, and
+    no directory matches the wildcard, the
+    <directive module="core">Include</directive> directive will
+    <strong>fail with an error</strong> saying the directory cannot be found.
+    </p>
+
+    <p>For further control over the behaviour of the server when no files or
+    directories match, prefix the path with the modifiers <var>optional</var>
+    or <var>strict</var>. If <var>optional</var> is specified, any wildcard
+    file or directory that does not match will be silently ignored. If
+    <var>strict</var> is specified, any wildcard file or directory that does
+    not match at least one file will cause server startup to fail.</p>
+
+    <p>When a directory or file component of the path is
+    specified exactly, and that directory or file does not exist,
+    <directive module="core">Include</directive> directive will fail with an
+    error saying the file or directory cannot be found.</p>
+
+    <p>The file path specified may be an absolute path, or may be relative 
+    to the <directive module="core">ServerRoot</directive> directory.</p>
+
+    <p>Examples:</p>
+
+    <example>
+      Include /usr/local/apache2/conf/ssl.conf<br />
+      Include /usr/local/apache2/conf/vhosts/*.conf
+    </example>
+
+    <p>Or, providing paths relative to your <directive
+    module="core">ServerRoot</directive> directory:</p>
+
+    <example>
+      Include conf/ssl.conf<br />
+      Include conf/vhosts/*.conf
+    </example>
+
+    <p>Wildcards may be included in the directory or file portion of the
+    path. In the following example, the server will fail to load if no
+    directories match conf/vhosts/*, but will load successfully if no
+    files match *.conf.</p>
+  
+    <example>
+      Include conf/vhosts/*/vhost.conf<br />
+      Include conf/vhosts/*/*.conf
+    </example>
+
+    <p>In this example, the server will fail to load if either
+    conf/vhosts/* matches no directories, or if *.conf matches no files:</p>
+
+    <example>
+      Include strict conf/vhosts/*/*.conf
+    </example>
+  
+    <p>In this example, the server load successfully if either conf/vhosts/*
+    matches no directories, or if *.conf matches no files:</p>
+
+    <example>
+      Include optional conf/vhosts/*/*.conf
+    </example>
+
+</usage>
+
+<seealso><program>apachectl</program></seealso>
+</directivesynopsis>
+  
+<directivesynopsis>
+<name>KeepAlive</name>
+<description>Enables HTTP persistent connections</description>
+<syntax>KeepAlive On|Off</syntax>
+<default>KeepAlive On</default>
+<contextlist><context>server config</context><context>virtual host</context>
+</contextlist>
+
+<usage>
+    <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 <directive module="mpm_common"
+    >MaxConnectionsPerChild</directive> directive, regardless
+    of how many requests are sent using the connection.</p>
+</usage>
+
+<seealso><directive module="core">MaxKeepAliveRequests</directive></seealso>
+</directivesynopsis>
+
+<directivesynopsis>
+<name>KeepAliveTimeout</name>
+<description>Amount of time the server will wait for subsequent
+requests on a persistent connection</description>
+<syntax>KeepAliveTimeout <var>num</var>[ms]</syntax>
+<default>KeepAliveTimeout 5</default>
+<contextlist><context>server config</context><context>virtual host</context>
+</contextlist>
+<compatibility>Specifying a value in milliseconds is available in 
+Apache httpd 2.3.2 and later</compatibility>
+
+<usage>
+    <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
+    <directive module="core">Timeout</directive> directive applies.</p>
+
+    <p>Setting <directive>KeepAliveTimeout</directive> 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>In a name-based virtual host context, the value of the first
+    defined virtual host (the default host) in a set of <directive
+    module="core">NameVirtualHost</directive> will be used.
+    The other values will be ignored.</p>
+</usage>
+</directivesynopsis>
+
+<directivesynopsis type="section">
+<name>Limit</name>
+<description>Restrict enclosed access controls to only certain HTTP
+methods</description>
+<syntax>&lt;Limit <var>method</var> [<var>method</var>] ... &gt; ...
+    &lt;/Limit&gt;</syntax>
+<contextlist><context>directory</context><context>.htaccess</context>
+</contextlist>
+<override>AuthConfig, Limit</override>
+
+<usage>
+    <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
+    <directive type="section">Limit</directive> section.</strong></p>
+
+    <p>The purpose of the <directive type="section">Limit</directive>
+    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 <directive
+    type="section">Limit</directive> 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>
+
+    <example>
+      &lt;Limit POST PUT DELETE&gt;<br />
+      <indent>
+        Require valid-user<br />
+      </indent>
+      &lt;/Limit&gt;
+    </example>
+
+    <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 <directive module="core"
+    >TraceEnable</directive>).</p>
+
+    <note type="warning">A <directive type="section"
+    module="core">LimitExcept</directive> section should always be
+    used in preference to a <directive type="section">Limit</directive>
+    section when restricting access, since a <directive type="section"
+    module="core">LimitExcept</directive> section provides protection
+    against arbitrary methods.</note>
+
+    <p>The <directive type="section">Limit</directive> and
+    <directive type="section" module="core">LimitExcept</directive>
+    directives may be nested.  In this case, each successive level of
+    <directive type="section">Limit</directive> or <directive
+    type="section" module="core">LimitExcept</directive> directives must
+    further restrict the set of methods to which access controls apply.</p>
+
+    <note type="warning">When using
+    <directive type="section">Limit</directive> or
+    <directive type="section">LimitExcept</directive> directives with
+    the <directive module="mod_authz_core">Require</directive> directive,
+    note that the first <directive module="mod_authz_core">Require</directive>
+    to succeed authorizes the request, regardless of the presence of other
+    <directive module="mod_authz_core">Require</directive> directives.</note>
+
+    <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>
+
+    <example>
+      &lt;LimitExcept GET&gt;
+      <indent>
+        Require valid-user
+      </indent> 
+      &lt;/LimitExcept&gt;<br />
+      &lt;Limit POST&gt;
+      <indent>
+        Require group editors
+      </indent> 
+      &lt;/Limit&gt;
+    </example>
+</usage>
+</directivesynopsis>
+
+<directivesynopsis type="section">
+<name>LimitExcept</name>
+<description>Restrict access controls to all HTTP methods
+except the named ones</description>
+<syntax>&lt;LimitExcept <var>method</var> [<var>method</var>] ... &gt; ...
+    &lt;/LimitExcept&gt;</syntax>
+<contextlist><context>directory</context><context>.htaccess</context>
+</contextlist>
+<override>AuthConfig, Limit</override>
+
+<usage>
+    <p><directive type="section">LimitExcept</directive> 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 <directive type="section"
+    module="core">Limit</directive> section and can be used to control
+    both standard and nonstandard/unrecognized methods. See the
+    documentation for <directive module="core"
+    type="section">Limit</directive> for more details.</p>
+
+    <p>For example:</p>
+
+    <example>
+      &lt;LimitExcept POST GET&gt;<br />
+      <indent>
+        Require valid-user<br />
+      </indent>
+      &lt;/LimitExcept&gt;
+    </example>
+
+</usage>
+</directivesynopsis>
+
+<directivesynopsis>
+<name>LimitInternalRecursion</name>
+<description>Determine maximum number of internal redirects and nested
+subrequests</description>
+<syntax>LimitInternalRecursion <var>number</var> [<var>number</var>]</syntax>
+<default>LimitInternalRecursion 10</default>
+<contextlist><context>server config</context><context>virtual host</context>
+</contextlist>
+<compatibility>Available in Apache httpd 2.0.47 and later</compatibility>
+
+<usage>
+    <p>An internal redirect happens, for example, when using the <directive
+    module="mod_actions">Action</directive> 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, <module>mod_dir</module> uses subrequests to look for the
+    files listed in the <directive module="mod_dir">DirectoryIndex</directive>
+    directive.</p>
+
+    <p><directive>LimitInternalRecursion</directive> 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 deep subrequests may be nested. If you specify only one
+    <var>number</var>, it will be assigned to both limits.</p>
+
+    <example><title>Example</title>
+      LimitInternalRecursion 5
+    </example>
+</usage>
+</directivesynopsis>
+
+<directivesynopsis>
+<name>LimitRequestBody</name>
+<description>Restricts the total size of the HTTP request body sent
+from the client</description>
+<syntax>LimitRequestBody <var>bytes</var></syntax>
+<default>LimitRequestBody 0</default>
+<contextlist><context>server config</context><context>virtual host</context>

[... 2003 lines stripped ...]


Mime
View raw message