You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cvs@httpd.apache.org by rb...@apache.org on 2010/12/01 14:21:15 UTC
svn commit: r1040999 [2/2] - /httpd/httpd/trunk/docs/manual/mod/core.xml.es
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&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&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&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>
+ <Files "mypaths.shtml"><br />
+ <indent>
+ Options +Includes<br />
+ SetOutputFilter INCLUDES<br />
+ AcceptPathInfo On<br />
+ </indent>
+ </Files>
+ </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>
+ <Directory /><br />
+ <indent>
+ AllowOverride None<br />
+ </indent>
+ </Directory>
+ </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 <Directory> 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><Directory /></code> block. Instead, find (or
+ create) the <code><Directory></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><Directory <var>directory-path</var>>
+... </Directory></syntax>
+<contextlist><context>server config</context><context>virtual host</context>
+</contextlist>
+
+<usage>
+ <p><directive type="section">Directory</directive> and
+ <code></Directory></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><Directory
+ /*/public_html></code> will not match
+ <code>/home/user/public_html</code>, but <code><Directory
+ /home/*/public_html></code> will match. Example:</p>
+
+ <example>
+ <Directory /usr/local/httpd/htdocs><br />
+ <indent>
+ Options Indexes FollowSymLinks<br />
+ </indent>
+ </Directory>
+ </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><Directory></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>
+ <Directory ~ "^/www/.*/[0-9]{3}">
+ </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>
+ <Directory /><br />
+ <indent>
+ AllowOverride None<br />
+ </indent>
+ </Directory><br />
+ <br />
+ <Directory /home/><br />
+ <indent>
+ AllowOverride FileInfo<br />
+ </indent>
+ </Directory>
+ </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>
+ <Directory ~ abc$><br />
+ <indent>
+ # ... directives here ...<br />
+ </indent>
+ </Directory>
+ </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><Directory /></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>
+ <Directory /><br />
+ <indent>
+ Order Deny,Allow<br />
+ Deny from All<br />
+ </indent>
+ </Directory>
+ </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 <Directory>,
+ <Location> and <Files> 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><DirectoryMatch <var>regex</var>>
+... </DirectoryMatch></syntax>
+<contextlist><context>server config</context><context>virtual host</context>
+</contextlist>
+
+<usage>
+ <p><directive type="section">DirectoryMatch</directive> and
+ <code></DirectoryMatch></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>
+ <DirectoryMatch "^/www/(.+/)?[0-9]{3}">
+ </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 <Directory>, <Location> and
+<Files> 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>
+ <Directory "/path-to-nfs-files">
+ <indent>
+ EnableMMAP Off
+ </indent>
+ </Directory>
+ </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>
+ <Directory "/path-to-nfs-files">
+ <indent>
+ EnableSendfile Off
+ </indent>
+ </Directory>
+ </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 />
+ <IfModule !include_module><br />
+ Error mod_include is required by mod_foo. Load it with LoadModule.<br />
+ </IfModule><br />
+ <br />
+ # ensure that exactly one of SSL,NOSSL is defined<br />
+ <IfDefine SSL><br />
+ <IfDefine NOSSL><br />
+ Error Both SSL and NOSSL are defined. Define only one of them.<br />
+ </IfDefine><br />
+ </IfDefine><br />
+ <IfDefine !SSL><br />
+ <IfDefine !NOSSL><br />
+ Error Either SSL or NOSSL must be defined.<br />
+ </IfDefine><br />
+ </IfDefine><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 />
+ <Directory /web/docs><br />
+ <indent>
+ ErrorDocument 404 default<br />
+ </indent>
+ </Directory>
+ </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 </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 '% '
+ (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 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>\ </code> (backslash space)</td>
+ <td>Non-field delimiting space</td></tr>
+
+ <tr><td><code>% </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% ,\ referer\ %{Referer}i"
+ </example>
+
+ <example><title>Example (similar to the 2.2.x format)</title>
+ ErrorLogFormat "[%t] [%l] %7F: %E: [client\ %a]
+ %M% ,\ referer\ %{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 INode MTime Size</code>, and a
+ subdirectory's includes <code>FileETag -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 MTime 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 MTime 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><Files <var>filename</var>> ... </Files></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></Files></code>
+ directive. The directives given within this section will be applied to
+ any object with a basename (last component of filename) matching the
+ specified filename. <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>
+ <Files ~ "\.(gif|jpe?g|png)$">
+ </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 <Directory>, <Location>
+ and <Files> 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><FilesMatch <var>regex</var>> ... </FilesMatch></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>
+ <FilesMatch "\.(gif|jpe?g|png)$">
+ </example>
+
+ <p>would match most common Internet graphics formats.</p>
+</usage>
+
+<seealso><a href="../sections.html">How <Directory>, <Location>
+ and <Files> sections work</a> for an explanation of how these
+ different sections are combined when a request is received</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 />
+ <Location /images><br />
+ <indent>
+ ForceType image/gif<br />
+ </indent>
+ </Location><br />
+ <br />
+ # but normal mime-type associations here:<br />
+ <Location /images/mixed><br />
+ <indent>
+ ForceType None<br />
+ </indent>
+ </Location>
+ </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><If <var>expression</var>> ... </If></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>
+ <If "$req{Host} = ''">
+ </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>
+ <If %{REQUEST_METHOD} IN GET,HEAD,OPTIONS>
+ </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 <Directory>, <Location>,
+ <Files> 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><IfDefine [!]<var>parameter-name</var>> ...
+ </IfDefine></syntax>
+<contextlist><context>server config</context><context>virtual host</context>
+<context>directory</context><context>.htaccess</context>
+</contextlist>
+<override>All</override>
+
+<usage>
+ <p>The <code><IfDefine <var>test</var>>...</IfDefine>
+ </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 />
+ <IfDefine ReverseProxy><br />
+ <indent>
+ LoadModule proxy_module modules/mod_proxy.so<br />
+ LoadModule proxy_http_module modules/mod_proxy_http.so<br />
+ <IfDefine UseCache><br />
+ <indent>
+ LoadModule cache_module modules/mod_cache.so<br />
+ <IfDefine MemCache><br />
+ <indent>
+ LoadModule mem_cache_module modules/mod_mem_cache.so<br />
+ </indent>
+ </IfDefine><br />
+ <IfDefine !MemCache><br />
+ <indent>
+ LoadModule cache_disk_module modules/mod_cache_disk.so<br />
+ </indent>
+ </IfDefine>
+ </indent>
+ </IfDefine>
+ </indent>
+ </IfDefine>
+ </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><IfModule [!]<var>module-file</var>|<var>module-identifier</var>> ...
+ </IfModule></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><IfModule <var>test</var>>...</IfModule></code>
+ section is used to mark directives that are conditional on the presence of
+ a specific module. The directives within an <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><Limit <var>method</var> [<var>method</var>] ... > ...
+ </Limit></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>
+ <Limit POST PUT DELETE><br />
+ <indent>
+ Require valid-user<br />
+ </indent>
+ </Limit>
+ </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>
+ <LimitExcept GET>
+ <indent>
+ Require valid-user
+ </indent>
+ </LimitExcept><br />
+ <Limit POST>
+ <indent>
+ Require group editors
+ </indent>
+ </Limit>
+ </example>
+</usage>
+</directivesynopsis>
+
+<directivesynopsis type="section">
+<name>LimitExcept</name>
+<description>Restrict access controls to all HTTP methods
+except the named ones</description>
+<syntax><LimitExcept <var>method</var> [<var>method</var>] ... > ...
+ </LimitExcept></syntax>
+<contextlist><context>directory</context><context>.htaccess</context>
+</contextlist>
+<override>AuthConfig, Limit</override>
+
+<usage>
+ <p><directive type="section">LimitExcept</directive> and
+ <code></LimitExcept></code> are used to enclose
+ a group of access control directives which will then apply to any
+ HTTP access method <strong>not</strong> listed in the arguments;
+ i.e., it is the opposite of a <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>
+ <LimitExcept POST GET><br />
+ <indent>
+ Require valid-user<br />
+ </indent>
+ </LimitExcept>
+ </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 ...]