Versión 2.3 del Servidor HTTP Apache
+
Versión 2.3 del Servidor HTTP Apache
+
| Descripción: | Funcionalides básicas del Servidor HTTP Apache que siempre están presentes. |
|---|---|
| Estado: | Core |
AcceptFilter AcceptPathInfo AccessFileName AddDefaultCharset AllowEncodedSlashes AllowOverride CGIMapExtension ContentDigest DefaultType Define <Directory> <DirectoryMatch> DocumentRoot EnableMMAP EnableSendfile Error ErrorDocument ErrorLog ErrorLogFormat ExtendedStatus FileETag <Files> <FilesMatch> ForceType GprofDir HostnameLookups <If> <IfDefine> <IfModule> Include KeepAlive KeepAliveTimeout <Limit> <LimitExcept> LimitInternalRecursion LimitRequestBody LimitRequestFields LimitRequestFieldSize LimitRequestLine LimitXMLRequestBody <Location> <LocationMatch> LogLevel MaxKeepAliveRequests Mutex NameVirtualHost Options Protocol RLimitCPU RLimitMEM RLimitNPROC ScriptInterpreterSource SeeRequestTail ServerAdmin ServerAlias ServerName ServerPath ServerRoot ServerSignature ServerTokens SetHandler SetInputFilter SetOutputFilter TimeOut TraceEnable UnDefine UseCanonicalName UseCanonicalPhysicalPort <VirtualHost>
| Descripción: | Configura mejoras para un Protocolo de Escucha de Sockets |
|---|---|
| Sintaxis: | AcceptFilter protocol accept_filter |
| Contexto: | server config |
| Estado: | Core |
| Módulo: | core |
| Compatibilidad: | Disponible en Apache httpd 2.1.5 y posteriores. +En Windows desde Apache httpd 2.3.3 y posteriores. |
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
+
+ Accept Filters sobre FreeBSD, TCP_DEFER_ACCEPT sobre Linux,
+ y AcceptEx() sobre Windows.
El uso de none 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 ftp: o nntp:
AcceptFilter nntp none
Los nombres de protocolo por defecto son https para el puerto 443
+ y http para todos los demás puertos. Para especificar que se está
+ utilizando otro protocolo con un puerto escuchando, añade el argumento protocol
+ a la directiva Listen.
Sobre FreeBDS los valores por defecto:
+
+ AcceptFilter http httpready
+ AcceptFilter https dataready
+
El filtro httpready 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
+
+ accf_http(9) para más detalles. Puesto que las peticiones HTTPS
+ están encriptadas, sólo se utiliza el filtro
+ accf_data(9).
Sobre Linux los valores por defecto son:
+
+ AcceptFilter http data
+ AcceptFilter https data
+
En Linux, TCP_DEFER_ACCEPT no soporta el buffering en peticiones http.
+ Cualquier valor además de none habilitará
+ TCP_DEFER_ACCEPT en ese socket. Para más detalles
+ ver la página man de Linux
+
+ tcp(7).
Sobre Windows los valores por defecto son:
+
+ AcceptFilter http data
+ AcceptFilter https data
+
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. data 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().
+ connect utiliza la API AcceptEx() API, y recupera también
+ las direccciones de red, pero a diferencia de none
+ la opción connect no espera a la transmisión inicial de los datos.
Sobre Windows, none 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.
Protocol| Descripción: | Los recursos aceptan información sobre su ruta |
|---|---|
| Sintaxis: | AcceptPathInfo On|Off|Default |
| Valor por defecto: | AcceptPathInfo Default |
| Contexto: | server config, virtual host, directory, .htaccess |
| Prevalece sobre: | FileInfo |
| Estado: | Core |
| Módulo: | core |
| Compatibilidad: | Disponible en Apache httpd 2.0.30 y posteriores |
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 PATH_INFO.
Por ejemplo, asumamos que la ubicación /test/ apunta a
+ un directorio que contiene únicamente el fichero
+ here.html. Entonces, las peticiones tanto para
+ /test/here.html/more como para
+ /test/nothere.html/more recogen
+ /more como PATH_INFO.
Los tres posibles argumentos para la directiva
+ AcceptPathInfo son los siguientes:
Off/test/here.html/more en el ejemplo anterior devolverá
+ un error 404 NOT FOUND.On/test/here.html/more será aceptado si
+ /test/here.html corresponde a un fichero válido.DefaultPATH_INFO. Los controladores que sirven scripts, tales como cgi-script e isapi-handler, normalmente aceptan
+ PATH_INFO por defecto.El objetivo principal de la directiva AcceptPathInfo
+ es permitirte sobreescribir la opción del controlador
+ de aceptar or rechazar PATH_INFO. This override is required,
+ for example, when you use a filter, such
+ as INCLUDES, to generate content
+ based on PATH_INFO. The core handler would usually reject
+ the request, so you can use the following configuration to enable
+ such a script:
+ <Files "mypaths.shtml">
+
+ Options +Includes
+ SetOutputFilter INCLUDES
+ AcceptPathInfo On
+
+ </Files>
+
| Descripción: | Name of the distributed configuration file |
|---|---|
| Sintaxis: | AccessFileName filename [filename] ... |
| Valor por defecto: | AccessFileName .htaccess |
| Contexto: | server config, virtual host |
| Estado: | Core |
| Módulo: | core |
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 enabled for that + directory. For example:
+ +
+ AccessFileName .acl
+
before returning the document
+ /usr/local/web/index.html, the server will read
+ /.acl, /usr/.acl,
+ /usr/local/.acl and /usr/local/web/.acl
+ for directives, unless they have been disabled with
+ <Directory />
+
+ AllowOverride None
+
+ </Directory>
+
| Descripción: | Default charset parameter to be added when a response
+content-type is text/plain or text/html |
|---|---|
| Sintaxis: | AddDefaultCharset On|Off|charset |
| Valor por defecto: | AddDefaultCharset Off |
| Contexto: | server config, virtual host, directory, .htaccess |
| Prevalece sobre: | FileInfo |
| Estado: | Core |
| Módulo: | core |
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
+ text/plain or text/html. This should override
+ any charset specified in the body of the response via a META
+ element, though the exact behavior is often dependent on the user's client
+ configuration. A setting of AddDefaultCharset Off
+ disables this functionality. AddDefaultCharset On enables
+ a default charset of iso-8859-1. Any other value is assumed
+ to be the charset to be used, which should be one of the
+ IANA registered
+ charset values for use in Internet media types (MIME types).
+ For example:
+ AddDefaultCharset utf-8
+
AddDefaultCharset 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.
AddCharset| Descripción: | Determines whether encoded path separators in URLs are allowed to +be passed through |
|---|---|
| Sintaxis: | AllowEncodedSlashes On|Off |
| Valor por defecto: | AllowEncodedSlashes Off |
| Contexto: | server config, virtual host |
| Estado: | Core |
| Módulo: | core |
| Compatibilidad: | Available in Apache httpd 2.0.46 and later |
The AllowEncodedSlashes directive allows URLs
+ which contain encoded path separators (%2F for /
+ and additionally %5C for \ on according systems)
+ to be used. Normally such URLs are refused with a 404 (Not found) error.
Turning AllowEncodedSlashes On is
+ mostly useful when used in conjunction with PATH_INFO.
Allowing encoded slashes does not imply decoding.
+ Occurrences of %2F or %5C (only on
+ according systems) will be left as such in the otherwise decoded URL
+ string.
| Descripción: | Types of directives that are allowed in
+.htaccess files |
|---|---|
| Sintaxis: | AllowOverride All|None|directive-type
+[directive-type] ... |
| Valor por defecto: | AllowOverride None (2.3.9 and later), AllowOverride All (2.3.8 and earlier) |
| Contexto: | directory |
| Estado: | Core |
| Módulo: | core |
When the server finds an .htaccess file (as
+ specified by AccessFileName)
+ it needs to know which directives declared in that file can override
+ earlier configuration directives.
AllowOverride is valid only in
+ <Directory>
+ sections specified without regular expressions, not in <Location>, <DirectoryMatch> or
+ <Files> sections.
+ When this directive is set to None, then
+ .htaccess files are completely ignored.
+ In this case, the server will not even attempt to read
+ .htaccess files in the filesystem.
When this directive is set to All, then any
+ directive which has the .htaccess Context is allowed in
+ .htaccess files.
The directive-type can be one of the following + groupings of directives.
+ +AuthDBMGroupFile,
+ AuthDBMUserFile,
+ AuthGroupFile,
+ AuthName,
+ AuthType, AuthUserFile, Require, etc.).ErrorDocument,
+ ForceType,
+ LanguagePriority,
+ SetHandler,
+ SetInputFilter,
+ SetOutputFilter, and
+ mod_mime Add* and Remove* directives),
+ document meta data (Header, RequestHeader, SetEnvIf, SetEnvIfNoCase, BrowserMatch, CookieExpires, CookieDomain, CookieStyle, CookieTracking, CookieName),
+ mod_rewrite directives RewriteEngine, RewriteOptions, RewriteBase, RewriteCond, RewriteRule) and
+ Action from
+ mod_actions.
+ AddDescription,
+ AddIcon, AddIconByEncoding,
+ AddIconByType,
+ DefaultIcon, DirectoryIndex, FancyIndexing, HeaderName, IndexIgnore, IndexOptions, ReadmeName,
+ etc.).Allow, Deny and Order).Options and
+ XBitHack).
+ An equal sign may be given followed by a comma (but no spaces)
+ separated lists of options that may be set using the Options command.Example:
+ +
+ AllowOverride AuthConfig Indexes
+
In the example above all directives that are neither in the group
+ AuthConfig nor Indexes cause an internal
+ server error.
For security and performance reasons, do not set
+ AllowOverride to anything other than None
+ in your <Directory /> block. Instead, find (or
+ create) the <Directory> block that refers to the
+ directory where you're actually planning to place a
+ .htaccess file.
| Descripción: | Technique for locating the interpreter for CGI +scripts |
|---|---|
| Sintaxis: | CGIMapExtension cgi-path .extension |
| Contexto: | directory, .htaccess |
| Prevalece sobre: | FileInfo |
| Estado: | Core |
| Módulo: | core |
| Compatibilidad: | NetWare only |
This directive is used to control how Apache httpd finds the
+ interpreter used to run CGI scripts. For example, setting
+ CGIMapExtension sys:\foo.nlm .foo will
+ cause all CGI script files with a .foo extension to
+ be passed to the FOO interpreter.
| Descripción: | Enables the generation of Content-MD5 HTTP Response
+headers |
|---|---|
| Sintaxis: | ContentDigest On|Off |
| Valor por defecto: | ContentDigest Off |
| Contexto: | server config, virtual host, directory, .htaccess |
| Prevalece sobre: | Options |
| Estado: | Core |
| Módulo: | core |
This directive enables the generation of
+ Content-MD5 headers as defined in RFC1864
+ respectively RFC2616.
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.
+ +The Content-MD5 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:
+ Content-MD5: AuLb7Dp1rqtRtxz2m9kRpA==
+
Note that this can cause performance problems on your server + since the message digest is computed on every request (the + values are not cached).
+ +Content-MD5 is only sent for documents served
+ by the core, and not by any module. For example,
+ SSI documents, output from CGI scripts, and byte range responses
+ do not have this header.
| Descripción: | This directive has no effect other than to emit warnings
+if the value is not none. 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.
+ |
|---|---|
| Sintaxis: | DefaultType media-type|none |
| Valor por defecto: | DefaultType none |
| Contexto: | server config, virtual host, directory, .htaccess |
| Prevalece sobre: | FileInfo |
| Estado: | Core |
| Módulo: | core |
| Compatibilidad: | The argument none is available in Apache httpd 2.2.7 and later. All other choices are DISABLED for 2.3.x and later. |
This directive has been disabled. For backwards compatibility
+ of configuration files, it may be specified with the value
+ none, meaning no default media type. For example:
+ DefaultType None
+
DefaultType None is only available in
+ httpd-2.2.7 and later.
Use the mime.types configuration file and the
+ AddType to configure media
+ type assignments via file extensions, or the
+ ForceType 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.
| Descripción: | Define the existence of a variable |
|---|---|
| Sintaxis: | Define parameter-name |
| Contexto: | server config |
| Estado: | Core |
| Módulo: | core |
Equivalent to passing the -D argument to httpd.
This directive can be used to toggle the use of <IfDefine> sections without needing to alter
+ -D arguments in any startup scripts.
| Descripción: | Enclose a group of directives that apply only to the +named file-system directory, sub-directories, and their contents. |
|---|---|
| Sintaxis: | <Directory directory-path>
+... </Directory> |
| Contexto: | server config, virtual host |
| Estado: | Core |
| Módulo: | core |
<Directory> and
+ </Directory> 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. Directory-path is
+ either the full path to a directory, or a wild-card string using
+ Unix shell-style matching. In a wild-card string, ? matches
+ any single character, and * matches any sequences of
+ characters. You may also use [] character ranges. None
+ of the wildcards match a `/' character, so <Directory
+ /*/public_html> will not match
+ /home/user/public_html, but <Directory
+ /home/*/public_html> will match. Example:
+ <Directory /usr/local/httpd/htdocs>
+
+ Options Indexes FollowSymLinks
+
+ </Directory>
+
Be careful with the directory-path arguments:
+ They have to literally match the filesystem path which Apache httpd uses
+ to access the files. Directives applied to a particular
+ <Directory> will not apply to files accessed from
+ that same directory via a different path, such as via different symbolic
+ links.
Regular
+ expressions can also be used, with the addition of the
+ ~ character. For example:
+ <Directory ~ "^/www/.*/[0-9]{3}">
+
would match directories in /www/ that consisted of
+ three numbers.
If multiple (non-regular expression) <Directory> 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 .htaccess files. For example,
+ with
+ <Directory />
+
+ AllowOverride None
+
+ </Directory>
+
+ <Directory /home/>
+
+ AllowOverride FileInfo
+
+ </Directory>
+
for access to the document /home/web/dir/doc.html
+ the steps are:
AllowOverride None
+ (disabling .htaccess files).AllowOverride FileInfo (for
+ directory /home).FileInfo directives in
+ /home/.htaccess, /home/web/.htaccess and
+ /home/web/dir/.htaccess in that order.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
+ +
+ <Directory ~ abc$>
+
+ # ... directives here ...
+
+ </Directory>
+
the regular expression section won't be considered until after
+ all normal <Directory>s and
+ .htaccess files have been applied. Then the regular
+ expression will match on /home/abc/public_html/abc and
+ the corresponding <Directory> will
+ be applied.
Note that the default access for
+ <Directory /> is Allow from All.
+ 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
+ <Directory />
+
+ Order Deny,Allow
+ Deny from All
+
+ </Directory>
+
and then override this for directories you + want accessible. See the Security Tips page for more + details.
+ +The directory sections occur in the httpd.conf file.
+ <Directory> directives
+ cannot nest, and cannot appear in a <Limit> or <LimitExcept> section.
| Descripción: | Enclose directives that apply to +the contents of file-system directories matching a regular expression. |
|---|---|
| Sintaxis: | <DirectoryMatch regex>
+... </DirectoryMatch> |
| Contexto: | server config, virtual host |
| Estado: | Core |
| Módulo: | core |
<DirectoryMatch> and
+ </DirectoryMatch> are used to enclose a group
+ of directives which will apply only to the named directory (and the files within),
+ the same as <Directory>.
+ However, it takes as an argument a
+ regular expression. For example:
+ <DirectoryMatch "^/www/(.+/)?[0-9]{3}">
+
would match directories in /www/ that consisted of three
+ numbers.
<Directory>) 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.
+ <Directory> for
+a description of how regular expressions are mixed in with normal
+<Directory>s| Descripción: | Directory that forms the main document tree visible +from the web |
|---|---|
| Sintaxis: | DocumentRoot directory-path |
| Valor por defecto: | DocumentRoot /usr/local/apache/htdocs |
| Contexto: | server config, virtual host |
| Estado: | Core |
| Módulo: | core |
This directive sets the directory from which httpd
+ will serve files. Unless matched by a directive like Alias, the server appends the
+ path from the requested URL to the document root to make the
+ path to the document. Example:
+ DocumentRoot /usr/web
+
then an access to
+ http://www.my.host.com/index.html refers to
+ /usr/web/index.html. If the directory-path is
+ not absolute then it is assumed to be relative to the ServerRoot.
The DocumentRoot should be specified without
+ a trailing slash.
| Descripción: | Use memory-mapping to read files during delivery |
|---|---|
| Sintaxis: | EnableMMAP On|Off |
| Valor por defecto: | EnableMMAP On |
| Contexto: | server config, virtual host, directory, .htaccess |
| Prevalece sobre: | FileInfo |
| Estado: | Core |
| Módulo: | core |
This directive controls whether the httpd may use
+ memory-mapping if it needs to read the contents of a file during
+ delivery. By default, when the handling of a request requires
+ access to the data within a file -- for example, when delivering a
+ server-parsed file using mod_include -- Apache httpd
+ memory-maps the file if the OS supports it.
This memory-mapping sometimes yields a performance improvement. + But in some environments, it is better to disable the memory-mapping + to prevent operational problems:
+ +httpd.httpd
+ has it memory-mapped can cause httpd to
+ crash with a segmentation fault.
+ For server configurations that are vulnerable to these problems, + you should disable memory-mapping of delivered files by specifying:
+ +
+ EnableMMAP Off
+
For NFS mounted files, this feature may be disabled explicitly for + the offending files by specifying:
+ +
+ <Directory "/path-to-nfs-files">
+
+ EnableMMAP Off
+
+ </Directory>
+
| Descripción: | Use the kernel sendfile support to deliver files to the client |
|---|---|
| Sintaxis: | EnableSendfile On|Off |
| Valor por defecto: | EnableSendfile Off |
| Contexto: | server config, virtual host, directory, .htaccess |
| Prevalece sobre: | FileInfo |
| Estado: | Core |
| Módulo: | core |
| Compatibilidad: | Available in version 2.0.44 and later. Default changed to Off in +version 2.3.9. |
This directive controls whether httpd may use the
+ sendfile support from the kernel to transmit file contents to the client.
+ By default, when the handling of a request requires no access
+ to the data within a file -- for example, when delivering a
+ static file -- Apache httpd uses sendfile to deliver the file contents
+ without ever reading the file if the OS supports it.
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:
+ +DocumentRoot (e.g., NFS, SMB, CIFS, FUSE),
+ the kernel may be unable to serve the network file through
+ its own cache.For server configurations that are not vulnerable to these problems, + you may enable this feature by specifying:
+ +
+ EnableSendfile On
+
For network mounted files, this feature may be disabled explicitly + for the offending files by specifying:
+ +
+ <Directory "/path-to-nfs-files">
+
+ EnableSendfile Off
+
+ </Directory>
+
Please note that the per-directory and .htaccess configuration
+ of EnableSendfile is not supported by
+ mod_cache_disk.
+ Only global definition of EnableSendfile
+ is taken into account by the module.
+
| Descripción: | Abort configuration parsing with a custom error message |
|---|---|
| Sintaxis: | Error message |
| Contexto: | server config, virtual host, directory, .htaccess |
| Estado: | Core |
| Módulo: | core |
| Compatibilidad: | 2.3.9 and later |
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.
+ +
+ # ensure that mod_include is loaded
+ <IfModule !include_module>
+ Error mod_include is required by mod_foo. Load it with LoadModule.
+ </IfModule>
+
+ # ensure that exactly one of SSL,NOSSL is defined
+ <IfDefine SSL>
+ <IfDefine NOSSL>
+ Error Both SSL and NOSSL are defined. Define only one of them.
+ </IfDefine>
+ </IfDefine>
+ <IfDefine !SSL>
+ <IfDefine !NOSSL>
+ Error Either SSL or NOSSL must be defined.
+ </IfDefine>
+ </IfDefine>
+
| Descripción: | What the server will return to the client +in case of an error |
|---|---|
| Sintaxis: | ErrorDocument error-code document |
| Contexto: | server config, virtual host, directory, .htaccess |
| Prevalece sobre: | FileInfo |
| Estado: | Core |
| Módulo: | core |
In the event of a problem or error, Apache httpd can be configured + to do one of four things,
+ +The first option is the default, while options 2-4 are
+ configured using the ErrorDocument
+ 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.
URLs can begin with a slash (/) for local web-paths (relative
+ to the DocumentRoot), or be a
+ full URL which the client can resolve. Alternatively, a message
+ can be provided to be displayed by the browser. Examples:
+ ErrorDocument 500 http://foo.example.com/cgi-bin/tester
+ ErrorDocument 404 /cgi-bin/bad_urls.pl
+ ErrorDocument 401 /subscription_info.html
+ ErrorDocument 403 "Sorry can't allow you access today"
+
Additionally, the special value default can be used
+ to specify Apache httpd's simple hardcoded message. While not required
+ under normal circumstances, default will restore
+ Apache httpd's simple hardcoded message for configurations that would
+ otherwise inherit an existing ErrorDocument.
+ ErrorDocument 404 /cgi-bin/bad_urls.pl
+ <Directory /web/docs>
+
+ ErrorDocument 404 default
+
+ </Directory>
+
Note that when you specify an ErrorDocument
+ that points to a remote URL (ie. anything with a method such as
+ http 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 ErrorDocument 401, the client will not
+ know to prompt the user for a password since it will not
+ receive the 401 status code. Therefore, if you use an
+ ErrorDocument 401 directive then it must refer to a local
+ document.
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 Q294807.
+ +Although most error messages can be overriden, there are certain
+ circumstances where the internal messages are used regardless of the
+ setting of ErrorDocument. 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.
If you are using mod_proxy, you may wish to enable
+ ProxyErrorOverride 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.
| Descripción: | Location where the server will log errors |
|---|---|
| Sintaxis: | ErrorLog file-path|syslog[:facility] |
| Valor por defecto: | ErrorLog logs/error_log (Unix) ErrorLog logs/error.log (Windows and OS/2) |
| Contexto: | server config, virtual host |
| Estado: | Core |
| Módulo: | core |
The ErrorLog directive sets the name of
+ the file to which the server will log any errors it encounters. If
+ the file-path is not absolute then it is assumed to be
+ relative to the ServerRoot.
+ ErrorLog /var/log/httpd/error_log
+
If the file-path
+ begins with a pipe character "|" then it is assumed to be a
+ command to spawn to handle the error log.
+ ErrorLog "|/usr/local/bin/httpd_errors"
+
See the notes on piped logs for + more information.
+ +Using syslog instead of a filename enables logging
+ via syslogd(8) if the system supports it. The default is to use
+ syslog facility local7, but you can override this by
+ using the syslog:facility syntax where
+ facility 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.
+ ErrorLog syslog:user
+
SECURITY: See the security tips + 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.
+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.
+| Descripción: | Format specification for error log entries |
|---|---|
| Sintaxis: | ErrorLog [connection|request] format |
| Contexto: | server config, virtual host |
| Estado: | Core |
| Módulo: | core |
| Compatibilidad: | Available in Apache httpd 2.3.9 and later |
ErrorLogFormat allows to specify what
+ supplementary information is logged in the error log in addition to the
+ actual log message.
+ ErrorLogFormat "[%t] [%l] [pid %P] %F: %E: [client %a] %M"
+
Specifying connection or request 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.
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 %a in the log
+ format [%t] [%l] [%a] %M 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.
The above behaviour can be changed by adding modifiers to the format
+ string item. A - (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 + (plus) modifier. If an
+ item with the plus modifier does not produce any output, the whole line is
+ ommitted.
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).
+ +Some format string items accept additional parameters in braces.
+ +| Format String | Description |
|---|---|
%% |
+ The percent sign |
%...a |
+ Remote IP-address and port |
%...A |
+ Local IP-address and port |
%...{name}e |
+ Request environment variable name |
%...E |
+ APR/OS error status code and string |
%...F |
+ Source file name and line number of the log call |
%...{name}i |
+ Request header name |
%...k |
+ Number of keep-alive requests on this connection |
%...l |
+ Loglevel of the message |
%...L |
+ Log ID of the request |
%...{c}L |
+ Log ID of the connection |
%...{C}L |
+ Log ID of the connection if used in connection scope, empty otherwise |
%...m |
+ Name of the module logging the message |
%M |
+ The actual log message |
%...{name}n |
+ Request note name |
%...P |
+ Process ID of current process |
%...T |
+ Thread ID of current thread |
%...t |
+ The current time |
%...{u}t |
+ The current time including micro-seconds |
%...{cu}t |
+ The current time in compact ISO 8601 format, including + micro-seconds |
%...v |
+ The canonical ServerName
+ of the current server. |
%...V |
+ The server name of the server serving the request according to the
+ UseCanonicalName
+ setting. |
\ (backslash space) |
+ Non-field delimiting space |
% (percent space) |
+ Field delimiter (no output) |
The log ID format %L 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 %L format string is also available in
+ mod_log_config, to allow to correlate access log entries
+ with error log lines. If mod_unique_id is loaded, its
+ unique id will be used as log ID for requests.
+ ErrorLogFormat "[%{u}t] [%-m:%l] [pid %P] %7F: %E: [client\ %a]
+ %M% ,\ referer\ %{Referer}i"
+
+ ErrorLogFormat "[%t] [%l] %7F: %E: [client\ %a]
+ %M% ,\ referer\ %{Referer}i"
+
+ ErrorLogFormat "[%{uc}t] [%-m:%-l] [R:%L] [C:%{C}L] %7F: %E: %M"
+ ErrorLogFormat request "[%{uc}t] [R:%L] Request %k on C:%{c}L pid:%P tid:%T"
+ ErrorLogFormat request "[%{uc}t] [R:%L] UA:'%+{User-Agent}i'"
+ ErrorLogFormat request "[%{uc}t] [R:%L] Referer:'%+{Referer}i'"
+ ErrorLogFormat connection "[%{uc}t] [C:%{c}L] local\ %a remote\ %A"
+
| Descripción: | Keep track of extended status information for each +request |
|---|---|
| Sintaxis: | ExtendedStatus On|Off |
| Valor por defecto: | ExtendedStatus Off[*] |
| Contexto: | server config |
| Estado: | Core |
| Módulo: | core |
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
+ mod_status. Note that other modules may
+ rely on this scoreboard.
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.
+ +Note that loading mod_status 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 mod_status beginning
+ with version 2.3.6; the previous default was always Off.
| Descripción: | File attributes used to create the ETag +HTTP response header for static files |
|---|---|
| Sintaxis: | FileETag component ... |
| Valor por defecto: | FileETag INode MTime Size |
| Contexto: | server config, virtual host, directory, .htaccess |
| Prevalece sobre: | FileInfo |
| Estado: | Core |
| Módulo: | core |
+ The FileETag directive configures the file
+ attributes that are used to create the ETag (entity
+ tag) response header field when the document is based on a static file.
+ (The ETag value is used in cache management to save
+ network bandwidth.) The
+ FileETag directive allows you to choose
+ which of these -- if any -- should be used. The recognized keywords are:
+
FileETag INode MTime Size
ETag field will be
+ included in the responseThe INode, MTime, and Size
+ keywords may be prefixed with either + or -,
+ 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.
If a directory's configuration includes
+ FileETag INode MTime Size, and a
+ subdirectory's includes FileETag -INode,
+ the setting for that subdirectory (which will be inherited by
+ any sub-subdirectories that don't override it) will be equivalent to
+ FileETag MTime Size.
mod_dav_fs as a storage provider.
+ mod_dav_fs uses INode MTime Size
+ as a fixed format for ETag comparisons on conditional requests.
+ These conditional requests will break if the ETag format is
+ changed via FileETag.
+ mod_include,
+ since the response entity can change without a change of the INode, MTime, or Size
+ of the static file with embedded SSI directives.
+ | Descripción: | Contains directives that apply to matched +filenames |
|---|---|
| Sintaxis: | <Files filename> ... </Files> |
| Contexto: | server config, virtual host, directory, .htaccess |
| Prevalece sobre: | All |
| Estado: | Core |
| Módulo: | core |
The <Files> directive
+ limits the scope of the enclosed directives by filename. It is comparable
+ to the <Directory>
+ and <Location>
+ directives. It should be matched with a </Files>
+ directive. The directives given within this section will be applied to
+ any object with a basename (last component of filename) matching the
+ specified filename. <Files>
+ sections are processed in the order they appear in the
+ configuration file, after the <Directory> sections and
+ .htaccess files are read, but before <Location> sections. Note
+ that <Files> can be nested
+ inside <Directory> sections to restrict the
+ portion of the filesystem they apply to.
The filename argument should include a filename, or
+ a wild-card string, where ? matches any single character,
+ and * matches any sequences of characters.
+ Regular expressions
+ can also be used, with the addition of the
+ ~ character. For example:
+ <Files ~ "\.(gif|jpe?g|png)$">
+
would match most common Internet graphics formats. <FilesMatch> is preferred,
+ however.
Note that unlike <Directory> and <Location> sections, <Files> sections can be used inside
+ .htaccess files. This allows users to control access to
+ their own files, at a file-by-file level.
| Descripción: | Contains directives that apply to regular-expression matched +filenames |
|---|---|
| Sintaxis: | <FilesMatch regex> ... </FilesMatch> |
| Contexto: | server config, virtual host, directory, .htaccess |
| Prevalece sobre: | All |
| Estado: | Core |
| Módulo: | core |
The <FilesMatch> directive
+ limits the scope of the enclosed directives by filename, just as the
+ <Files> directive
+ does. However, it accepts a regular
+ expression. For example:
+ <FilesMatch "\.(gif|jpe?g|png)$">
+
would match most common Internet graphics formats.
+ +| Descripción: | Forces all matching files to be served with the specified +media type in the HTTP Content-Type header field |
|---|---|
| Sintaxis: | ForceType media-type|None |
| Contexto: | directory, .htaccess |
| Prevalece sobre: | FileInfo |
| Estado: | Core |
| Módulo: | core |
| Compatibilidad: | Moved to the core in Apache httpd 2.0 |
When placed into an .htaccess file or a
+ <Directory>, or
+ <Location> or
+ <Files>
+ section, this directive forces all matching files to be served
+ with the content type identification given by
+ media-type. For example, if you had a directory full of
+ GIF files, but did not want to label them all with .gif,
+ you might want to use:
+ ForceType image/gif
+
Note that this directive overrides other indirect media type
+ associations defined in mime.types or via the
+ AddType.
You can also override more general
+ ForceType settings
+ by using the value of None:
+ # force all files to be image/gif:
+ <Location /images>
+
+ ForceType image/gif
+
+ </Location>
+
+ # but normal mime-type associations here:
+ <Location /images/mixed>
+
+ ForceType None
+
+ </Location>
+
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.
+ + +| Descripción: | Directory to write gmon.out profiling data to. |
|---|---|
| Sintaxis: | GprofDir /tmp/gprof/|/tmp/gprof/% |
| Contexto: | server config, virtual host |
| Estado: | Core |
| Módulo: | core |
When the server has been compiled with gprof profiling suppport,
+ GprofDir causes gmon.out 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.
This directive currently only works with the prefork
+ MPM.
| Descripción: | Enables DNS lookups on client IP addresses |
|---|---|
| Sintaxis: | HostnameLookups On|Off|Double |
| Valor por defecto: | HostnameLookups Off |
| Contexto: | server config, virtual host, directory |
| Estado: | Core |
| Módulo: | core |
This directive enables DNS lookups so that host names can be
+ logged (and passed to CGIs/SSIs in REMOTE_HOST).
+ The value Double 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
+ PARANOID.)
Regardless of the setting, when mod_authz_host 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 HostnameLookups Double. For example, if only
+ HostnameLookups On 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 REMOTE_HOST.
The default is Off in order to save the network
+ traffic for those sites that don't truly need the reverse
+ lookups done. It is also better for the end users because they
+ don't have to suffer the extra latency that a lookup entails.
+ Heavily loaded sites should leave this directive
+ Off, since DNS lookups can take considerable
+ amounts of time. The utility logresolve, compiled by
+ default to the bin subdirectory of your installation
+ directory, can be used to look up host names from logged IP addresses
+ offline.
| Descripción: | Contains directives that apply only if a condition is +satisfied by a request at runtime |
|---|---|
| Sintaxis: | <If expression> ... </If> |
| Contexto: | server config, virtual host, directory, .htaccess |
| Prevalece sobre: | All |
| Estado: | Core |
| Módulo: | core |
The <If> directive
+ evaluates an expression at runtime, and applies the enclosed
+ directives if and only if the expression evaluates to true.
+ For example:
+ <If "$req{Host} = ''">
+
would match HTTP/1.0 requests without a Host: header.
+ +You may compare the value of any variable in the request headers + ($req), response headers ($resp) or environment ($env) in your + expression.
+ +Apart from =, If can use the IN
+ operator to compare if the expression is in a given range:
+ <If %{REQUEST_METHOD} IN GET,HEAD,OPTIONS>
+
<If> has the same precedence
+ and usage as <Files>| Descripción: | Encloses directives that will be processed only +if a test is true at startup |
|---|---|
| Sintaxis: | <IfDefine [!]parameter-name> ...
+ </IfDefine> |
| Contexto: | server config, virtual host, directory, .htaccess |
| Prevalece sobre: | All |
| Estado: | Core |
| Módulo: | core |
The <IfDefine test>...</IfDefine>
+ section is used to mark directives that are conditional. The
+ directives within an <IfDefine>
+ section are only processed if the test is true. If
+ test is false, everything between the start and end markers is
+ ignored.
The test in the <IfDefine> section directive can be one of two forms:
!parameter-nameIn the former case, the directives between the start and end + markers are only processed if the parameter named + parameter-name is defined. The second format reverses + the test, and only processes the directives if + parameter-name is not defined.
+ +The parameter-name argument is a define as given on the
+ httpd command line via -Dparameter
+ at the time the server was started or by the Define directive.
<IfDefine> sections are
+ nest-able, which can be used to implement simple
+ multiple-parameter tests. Example:
+ httpd -DReverseProxy -DUseCache -DMemCache ...
+
+ # httpd.conf
+ <IfDefine ReverseProxy>
+
+ LoadModule proxy_module modules/mod_proxy.so
+ LoadModule proxy_http_module modules/mod_proxy_http.so
+ <IfDefine UseCache>
+
+ LoadModule cache_module modules/mod_cache.so
+ <IfDefine MemCache>
+
+ LoadModule mem_cache_module modules/mod_mem_cache.so
+
+ </IfDefine>
+ <IfDefine !MemCache>
+
+ LoadModule cache_disk_module modules/mod_cache_disk.so
+
+ </IfDefine>
+
+ </IfDefine>
+
+ </IfDefine>
+
| Descripción: | Encloses directives that are processed conditional on the +presence or absence of a specific module |
|---|---|
| Sintaxis: | <IfModule [!]module-file|module-identifier> ...
+ </IfModule> |
| Contexto: | server config, virtual host, directory, .htaccess |
| Prevalece sobre: | All |
| Estado: | Core |
| Módulo: | core |
| Compatibilidad: | Module identifiers are available in version 2.1 and +later. |
The <IfModule test>...</IfModule>
+ section is used to mark directives that are conditional on the presence of
+ a specific module. The directives within an <IfModule> section are only processed if the test
+ is true. If test is false, everything between the start and
+ end markers is ignored.
The test in the <IfModule> section directive can be one of two forms:
In the former case, the directives between the start and end
+ markers are only processed if the module named module
+ is included in Apache httpd -- either compiled in or
+ dynamically loaded using LoadModule. The second format reverses the test,
+ and only processes the directives if module is
+ not included.
The module argument can be either the module identifier or
+ the file name of the module, at the time it was compiled. For example,
+ rewrite_module is the identifier and
+ mod_rewrite.c is the file name. If a module consists of
+ several source files, use the name of the file containing the string
+ STANDARD20_MODULE_STUFF.
<IfModule> sections are
+ nest-able, which can be used to implement simple multiple-module
+ tests.
<IfModule>
+ sections.| Descripción: | Includes other configuration files from within +the server configuration files |
|---|---|
| Sintaxis: | Include [optional|strict] file-path|directory-path|wildcard |
| Contexto: | server config, virtual host, directory |
| Estado: | Core |
| Módulo: | core |
| Compatibilidad: | Wildcard matching available in 2.0.41 and later, directory +wildcard matching available in 2.3.6 and later |
This directive allows inclusion of other configuration files + from within the server configuration files.
+ +Shell-style (fnmatch()) 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
+ Include 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
+ httpd 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.
When a wildcard is specified for a file component of
+ the path, and no file matches the wildcard, the
+ Include
+ directive will be silently ignored. When a wildcard is
+ specified for a directory component of the path, and
+ no directory matches the wildcard, the
+ Include directive will
+ fail with an error saying the directory cannot be found.
+
For further control over the behaviour of the server when no files or + directories match, prefix the path with the modifiers optional + or strict. If optional is specified, any wildcard + file or directory that does not match will be silently ignored. If + strict is specified, any wildcard file or directory that does + not match at least one file will cause server startup to fail.
+ +When a directory or file component of the path is
+ specified exactly, and that directory or file does not exist,
+ Include directive will fail with an
+ error saying the file or directory cannot be found.
The file path specified may be an absolute path, or may be relative
+ to the ServerRoot directory.
Examples:
+ +
+ Include /usr/local/apache2/conf/ssl.conf
+ Include /usr/local/apache2/conf/vhosts/*.conf
+
Or, providing paths relative to your ServerRoot directory:
+ Include conf/ssl.conf
+ Include conf/vhosts/*.conf
+
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.
+ +
+ Include conf/vhosts/*/vhost.conf
+ Include conf/vhosts/*/*.conf
+
In this example, the server will fail to load if either + conf/vhosts/* matches no directories, or if *.conf matches no files:
+ +
+ Include strict conf/vhosts/*/*.conf
+
In this example, the server load successfully if either conf/vhosts/* + matches no directories, or if *.conf matches no files:
+ +
+ Include optional conf/vhosts/*/*.conf
+
apachectl| Descripción: | Enables HTTP persistent connections |
|---|---|
| Sintaxis: | KeepAlive On|Off |
| Valor por defecto: | KeepAlive On |
| Contexto: | server config, virtual host |
| Estado: | Core |
| Módulo: | core |
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
+ KeepAlive On.
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.
+ +When a client uses a Keep-Alive connection it will be counted
+ as a single "request" for the MaxConnectionsPerChild directive, regardless
+ of how many requests are sent using the connection.
| Descripción: | Amount of time the server will wait for subsequent +requests on a persistent connection |
|---|---|
| Sintaxis: | KeepAliveTimeout num[ms] |
| Valor por defecto: | KeepAliveTimeout 5 |
| Contexto: | server config, virtual host |
| Estado: | Core |
| Módulo: | core |
| Compatibilidad: | Specifying a value in milliseconds is available in +Apache httpd 2.3.2 and later |
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
+ Timeout directive applies.
Setting KeepAliveTimeout 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.
In a name-based virtual host context, the value of the first
+ defined virtual host (the default host) in a set of NameVirtualHost will be used.
+ The other values will be ignored.
| Descripción: | Restrict enclosed access controls to only certain HTTP +methods |
|---|---|
| Sintaxis: | <Limit method [method] ... > ...
+ </Limit> |
| Contexto: | directory, .htaccess |
| Prevalece sobre: | AuthConfig, Limit |
| Estado: | Core |
| Módulo: | core |
Access controls are normally effective for
+ all access methods, and this is the usual
+ desired behavior. In the general case, access control
+ directives should not be placed within a
+ <Limit> section.
The purpose of the <Limit>
+ directive is to restrict the effect of the access controls to the
+ nominated HTTP methods. For all other methods, the access
+ restrictions that are enclosed in the <Limit> bracket will have no
+ effect. The following example applies the access control
+ only to the methods POST, PUT, and
+ DELETE, leaving all other methods unprotected:
+ <Limit POST PUT DELETE>
+
+ Require valid-user
+
+ </Limit>
+
The method names listed can be one or more of: GET,
+ POST, PUT, DELETE,
+ CONNECT, OPTIONS,
+ PATCH, PROPFIND, PROPPATCH,
+ MKCOL, COPY, MOVE,
+ LOCK, and UNLOCK. The method name is
+ case-sensitive. If GET is used it will also
+ restrict HEAD requests. The TRACE method
+ cannot be limited (see TraceEnable).
<LimitExcept> section should always be
+ used in preference to a <Limit>
+ section when restricting access, since a <LimitExcept> section provides protection
+ against arbitrary methods.The <Limit> and
+ <LimitExcept>
+ directives may be nested. In this case, each successive level of
+ <Limit> or <LimitExcept> directives must
+ further restrict the set of methods to which access controls apply.
<Limit> or
+ <LimitExcept> directives with
+ the Require directive,
+ note that the first Require
+ to succeed authorizes the request, regardless of the presence of other
+ Require directives.For example, given the following configuration, all users will
+ be authorized for POST requests, and the
+ Require group editors directive will be ignored
+ in all cases:
+ <LimitExcept GET>
+
+ Require valid-user
+
+ </LimitExcept>
+ <Limit POST>
+
+ Require group editors
+
+ </Limit>
+
| Descripción: | Restrict access controls to all HTTP methods +except the named ones |
|---|---|
| Sintaxis: | <LimitExcept method [method] ... > ...
+ </LimitExcept> |
| Contexto: | directory, .htaccess |
| Prevalece sobre: | AuthConfig, Limit |
| Estado: | Core |
| Módulo: | core |
<LimitExcept> and
+ </LimitExcept> are used to enclose
+ a group of access control directives which will then apply to any
+ HTTP access method not listed in the arguments;
+ i.e., it is the opposite of a <Limit> section and can be used to control
+ both standard and nonstandard/unrecognized methods. See the
+ documentation for <Limit> for more details.
For example:
+ +
+ <LimitExcept POST GET>
+
+ Require valid-user
+
+ </LimitExcept>
+
| Descripción: | Determine maximum number of internal redirects and nested +subrequests |
|---|---|
| Sintaxis: | LimitInternalRecursion number [number] |
| Valor por defecto: | LimitInternalRecursion 10 |
| Contexto: | server config, virtual host |
| Estado: | Core |
| Módulo: | core |
| Compatibilidad: | Available in Apache httpd 2.0.47 and later |
An internal redirect happens, for example, when using the Action 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, mod_dir uses subrequests to look for the
+ files listed in the DirectoryIndex
+ directive.
LimitInternalRecursion prevents the server
+ from crashing when entering an infinite loop of internal redirects or
+ subrequests. Such loops are usually caused by misconfigurations.
The directive stores two different limits, which are evaluated on + per-request basis. The first number is the maximum number of + internal redirects, that may follow each other. The second number + determines, how deep subrequests may be nested. If you specify only one + number, it will be assigned to both limits.
+ +
+ LimitInternalRecursion 5
+
| Descripción: | Restricts the total size of the HTTP request body sent +from the client |
|---|---|
| Sintaxis: | LimitRequestBody bytes |
| Valor por defecto: | LimitRequestBody 0 |
| Contexto: | server config, virtual host, directory, .htaccess |
| Prevalece sobre: | All |
| Estado: | Core |
| Módulo: | core |
This directive specifies the number of bytes from 0 + (meaning unlimited) to 2147483647 (2GB) that are allowed in a + request body. See the note below for the limited applicability + to proxy requests.
+ +The LimitRequestBody directive allows
+ the user to set a limit on the allowed size of an HTTP request
+ message body within the context in which the directive is given
+ (server, per-directory, per-file or per-location). If the client
+ request exceeds that limit, the server will return an error
+ response instead of servicing the request. The size of a normal
+ request message body will vary greatly depending on the nature of
+ the resource and the methods allowed on that resource. CGI scripts
+ typically use the message body for retrieving form information.
+ Implementations of the PUT method will require
+ a value at least as large as any representation that the server
+ wishes to accept for that resource.
This directive gives the server administrator greater + control over abnormal client request behavior, which may be + useful for avoiding some forms of denial-of-service + attacks.
+ +If, for example, you are permitting file upload to a particular + location, and wish to limit the size of the uploaded file to 100K, + you might use the following directive:
+ +
+ LimitRequestBody 102400
+
For a full description of how this directive is interpreted by
+ proxy requests, see the mod_proxy documentation.
| Descripción: | Limits the number of HTTP request header fields that +will be accepted from the client |
|---|---|
| Sintaxis: | LimitRequestFields number |
| Valor por defecto: | LimitRequestFields 100 |
| Contexto: | server config, virtual host |
| Estado: | Core |
| Módulo: | core |
Number is an integer from 0 (meaning unlimited) to
+ 32767. The default value is defined by the compile-time
+ constant DEFAULT_LIMIT_REQUEST_FIELDS (100 as
+ distributed).
The LimitRequestFields directive allows
+ the server administrator to modify the limit on the number of
+ request header fields allowed in an HTTP request. A server needs
+ this value to be larger than the number of fields that a normal
+ client request might include. The number of request header fields
+ used by a client rarely exceeds 20, but this may vary among
+ different client implementations, often depending upon the extent
+ to which a user has configured their browser to support detailed
+ content negotiation. Optional HTTP extensions are often expressed
+ using request header fields.
This directive gives the server administrator greater + control over abnormal client request behavior, which may be + useful for avoiding some forms of denial-of-service attacks. + The value should be increased if normal clients see an error + response from the server that indicates too many fields were + sent in the request.
+ +For example:
+ +
+ LimitRequestFields 50
+
When name-based virtual hosting is used, the value for this
+ directive is taken from the default (first-listed) virtual host for the
+ NameVirtualHost the connection was mapped to.
| Descripción: | Limits the size of the HTTP request header allowed from the +client |
|---|---|
| Sintaxis: | LimitRequestFieldSize bytes |
| Valor por defecto: | LimitRequestFieldSize 8190 |
| Contexto: | server config, virtual host |
| Estado: | Core |
| Módulo: | core |
This directive specifies the number of bytes + that will be allowed in an HTTP request header.
+ +The LimitRequestFieldSize directive
+ allows the server administrator to reduce or increase the limit
+ on the allowed size of an HTTP request header field. A server
+ needs this value to be large enough to hold any one header field
+ from a normal client request. The size of a normal request header
+ field will vary greatly among different client implementations,
+ often depending upon the extent to which a user has configured
+ their browser to support detailed content negotiation. SPNEGO
+ authentication headers can be up to 12392 bytes.
This directive gives the server administrator greater + control over abnormal client request behavior, which may be + useful for avoiding some forms of denial-of-service attacks.
+ +For example:
+ +
+ LimitRequestFieldSize 4094
+
When name-based virtual hosting is used, the value for this
+ directive is taken from the default (first-listed) virtual host for the
+ NameVirtualHost the connection was mapped to.
| Descripción: | Limit the size of the HTTP request line that will be accepted +from the client |
|---|---|
| Sintaxis: | LimitRequestLine bytes |
| Valor por defecto: | LimitRequestLine 8190 |
| Contexto: | server config, virtual host |
| Estado: | Core |
| Módulo: | core |
This directive sets the number of bytes that will be + allowed on the HTTP request-line.
+ +The LimitRequestLine directive allows
+ the server administrator to reduce or increase the limit on the allowed size
+ of a client's HTTP request-line. Since the request-line consists of the
+ HTTP method, URI, and protocol version, the
+ LimitRequestLine directive places a
+ restriction on the length of a request-URI allowed for a request
+ on the server. A server needs this value to be large enough to
+ hold any of its resource names, including any information that
+ might be passed in the query part of a GET request.
This directive gives the server administrator greater + control over abnormal client request behavior, which may be + useful for avoiding some forms of denial-of-service attacks.
+ +For example:
+ +
+ LimitRequestLine 4094
+
When name-based virtual hosting is used, the value for this
+ directive is taken from the default (first-listed) virtual host for the
+ NameVirtualHost the connection was mapped to.
| Descripción: | Limits the size of an XML-based request body |
|---|---|
| Sintaxis: | LimitXMLRequestBody bytes |
| Valor por defecto: | LimitXMLRequestBody 1000000 |
| Contexto: | server config, virtual host, directory, .htaccess |
| Prevalece sobre: | All |
| Estado: | Core |
| Módulo: | core |
Limit (in bytes) on maximum size of an XML-based request
+ body. A value of 0 will disable any checking.
Example:
+ +
+ LimitXMLRequestBody 0
+
| Descripción: | Applies the enclosed directives only to matching +URLs |
|---|---|
| Sintaxis: | <Location
+ URL-path|URL> ... </Location> |
| Contexto: | server config, virtual host |
| Estado: | Core |
| Módulo: | core |
The <Location> directive
+ limits the scope of the enclosed directives by URL. It is similar to the
+ <Directory>
+ directive, and starts a subsection which is terminated with a
+ </Location> directive. <Location> sections are processed in the
+ order they appear in the configuration file, after the <Directory> sections and
+ .htaccess files are read, and after the <Files> sections.
<Location> sections operate
+ completely outside the filesystem. This has several consequences.
+ Most importantly, <Location>
+ directives should not be used to control access to filesystem
+ locations. Since several different URLs may map to the same
+ filesystem location, such access controls may by circumvented.
The enclosed directives will be applied to the request if the path component + of the URL meets any of the following criteria: +
++ In the example below, where no trailing slash is used, requests to + /private1, /private1/ and /private1/file.txt will have the enclosed + directives applied, but /private1other would not. +
+
+ <Location /private1>
+ ...
+
+ In the example below, where a trailing slash is used, requests to + /private2/ and /private2/file.txt will have the enclosed + directives applied, but /private2 and /private2other would not. +
+
+ <Location /private2/>
+ ...
+
<Location>Use <Location> to apply
+ directives to content that lives outside the filesystem. For
+ content that lives in the filesystem, use <Directory> and <Files>. An exception is
+ <Location />, which is an easy way to
+ apply a configuration to the entire server.
For all origin (non-proxy) requests, the URL to be matched is a
+ URL-path of the form /path/. No scheme, hostname,
+ port, or query string may be included. For proxy requests, the
+ URL to be matched is of the form
+ scheme://servername/path, and you must include the
+ prefix.
The URL may use wildcards. In a wild-card string, ? matches
+ any single character, and * matches any sequences of
+ characters. Neither wildcard character matches a / in the URL-path.
Regular expressions
+ can also be used, with the addition of the ~
+ character. For example:
+ <Location ~ "/(extra|special)/data">
+
would match URLs that contained the substring /extra/data
+ or /special/data. The directive <LocationMatch> behaves
+ identical to the regex version of <Location>, and is preferred, for the
+ simple reason that ~ is hard to distinguish from
+ - in many fonts.
The <Location>
+ functionality is especially useful when combined with the
+ SetHandler
+ directive. For example, to enable status requests, but allow them
+ only from browsers at example.com, you might use:
+ <Location /status>
+
+ SetHandler server-status
+ Require host example.com
+
+ </Location>
+
The slash character has special meaning depending on where in a
+ URL it appears. People may be used to its behavior in the filesystem
+ where multiple adjacent slashes are frequently collapsed to a single
+ slash (i.e., /home///foo is the same as
+ /home/foo). In URL-space this is not necessarily true.
+ The <LocationMatch>
+ directive and the regex version of <Location> require you to explicitly specify multiple
+ slashes if that is your intention.
For example, <LocationMatch ^/abc> would match
+ the request URL /abc but not the request URL
+ //abc. The (non-regex) <Location> directive behaves similarly when used for
+ proxy requests. But when (non-regex) <Location> is used for non-proxy requests it will
+ implicitly match multiple slashes with a single slash. For example,
+ if you specify <Location /abc/def> and the
+ request is to /abc//def then it will match.
LocationMatch| Descripción: | Applies the enclosed directives only to regular-expression +matching URLs |
|---|---|
| Sintaxis: | <LocationMatch
+ regex> ... </LocationMatch> |
| Contexto: | server config, virtual host |
| Estado: | Core |
| Módulo: | core |
The <LocationMatch> directive
+ limits the scope of the enclosed directives by URL, in an identical manner
+ to <Location>. However,
+ it takes a regular expression
+ as an argument instead of a simple string. For example:
+ <LocationMatch "/(extra|special)/data">
+
would match URLs that contained the substring /extra/data
+ or /special/data.
| Descripción: | Controls the verbosity of the ErrorLog |
|---|---|
| Sintaxis: | LogLevel [module:]level
+ [module:level] ...
+ |
| Valor por defecto: | LogLevel warn |
| Contexto: | server config, virtual host, directory |
| Estado: | Core |
| Módulo: | core |
| Compatibilidad: | Per-module and per-directory configuration is available in + Apache HTTP Server 2.3.6 and later |
LogLevel adjusts the verbosity of the
+ messages recorded in the error logs (see ErrorLog directive). The following
+ levels are available, in order of decreasing
+ significance:
| Level | + +Description | + +Example | +
|---|---|---|
emerg |
+
+ Emergencies - system is unusable. | + +"Child cannot open lock file. Exiting" | +
alert |
+
+ Action must be taken immediately. | + +"getpwuid: couldn't determine user name from uid" | +
crit |
+
+ Critical Conditions. | + +"socket: Failed to get a socket, exiting child" | +
error |
+
+ Error conditions. | + +"Premature end of script headers" | +
warn |
+
+ Warning conditions. | + +"child process 1234 did not exit, sending another + SIGHUP" | +
notice |
+
+ Normal but significant condition. | + +"httpd: caught SIGBUS, attempting to dump core in + ..." | +
info |
+
+ Informational. | + +"Server seems busy, (you may need to increase + StartServers, or Min/MaxSpareServers)..." | +
debug |
+
+ Debug-level messages | + +"Opening config file ..." | +
trace1 |
+
+ Trace messages | + +"proxy: FTP: control connection complete" | +
trace2 |
+
+ Trace messages | + +"proxy: CONNECT: sending the CONNECT request to the remote proxy" | +
trace3 |
+
+ Trace messages | + +"openssl: Handshake: start" | +
trace4 |
+
+ Trace messages | + +"read from buffered SSL brigade, mode 0, 17 bytes" | +
trace5 |
+
+ Trace messages | + +"map lookup FAILED: map=rewritemap key=keyname" | +
trace6 |
+
+ Trace messages | + +"cache lookup FAILED, forcing new map lookup" | +
trace7 |
+
+ Trace messages, dumping large amounts of data | + +"| 0000: 02 23 44 30 13 40 ac 34 df 3d bf 9a 19 49 39 15 |" | +
trace8 |
+
+ Trace messages, dumping large amounts of data | + +"| 0000: 02 23 44 30 13 40 ac 34 df 3d bf 9a 19 49 39 15 |" | +
When a particular level is specified, messages from all
+ other levels of higher significance will be reported as well.
+ E.g., when LogLevel info is specified,
+ then messages with log levels of notice and
+ warn will also be posted.
Using a level of at least crit is
+ recommended.
For example:
+ +
+ LogLevel notice
+
When logging to a regular file messages of the level
+ notice cannot be suppressed and thus are always
+ logged. However, this doesn't apply when logging is done
+ using syslog.
Specifying a level without a module name will reset the level
+ for all modules to that level. Specifying a level with a module
+ name will set the level for that module only. It is possible to
+ use the module source file name, the module identifier, or the
+ module identifier with the trailing _module omitted
+ as module specification. This means the following three specifications
+ are equivalent:
+ LogLevel info ssl:warn
+ LogLevel info mod_ssl.c:warn
+ LogLevel info ssl_module:warn
+
It is also possible to change the level per directory:
+ +
+ LogLevel info
+ <Directory /usr/local/apache/htdocs/app>
+ LogLevel debug
+ </Files>
+
| Descripción: | Number of requests allowed on a persistent +connection |
|---|---|
| Sintaxis: | MaxKeepAliveRequests number |
| Valor por defecto: | MaxKeepAliveRequests 100 |
| Contexto: | server config, virtual host |
| Estado: | Core |
| Módulo: | core |
The MaxKeepAliveRequests directive
+ limits the number of requests allowed per connection when
+ KeepAlive is on. If it is
+ set to 0, unlimited requests will be allowed. We
+ recommend that this setting be kept to a high value for maximum
+ server performance.
For example:
+ +
+ MaxKeepAliveRequests 500
+
| Descripción: | Configures mutex mechanism and lock file directory for all +or specified mutexes |
|---|---|
| Sintaxis: | Mutex mechanism [default|mutex-name] ... [OmitPID] |
| Valor por defecto: | Mutex default |
| Contexto: | server config |
| Estado: | Core |
| Módulo: | core |
| Compatibilidad: | Available in Apache HTTP Server 2.3.4 and later |
The Mutex directive sets the mechanism,
+ and optionally the lock file location, that httpd and modules use
+ to serialize access to resources. Specify default as
+ the first argument to change the settings for all mutexes; specify
+ a mutex name (see table below) as the first argument to override
+ defaults only for that mutex.
The Mutex directive is typically used in
+ the following exceptional situations:
This directive only configures mutexes which have been registered
+ with the core server using the ap_mutex_register() API.
+ All modules bundled with httpd support the Mutex
+ directive, but third-party modules may not. Consult the documentation
+ of the third-party module, which must indicate the mutex name(s) which
+ can be configured if this directive is supported.
The following mutex mechanisms are available:
+default | yes
+ This selects the default locking implementation, as determined by
+ APR. The default locking implementation can
+ be displayed by running httpd with the
+ -V option.
none | no
+ This effectively disables the mutex, and is only allowed for a + mutex if the module indicates that it is a valid choice. Consult the + module documentation for more information.
posixsem
+ This is a mutex variant based on a Posix semaphore.
+ +The semaphore ownership is not recovered if a thread in the process + holding the mutex segfaults, resulting in a hang of the web server.
+sysvsem
+ This is a mutex variant based on a SystemV IPC semaphore.
+ +It is possible to "leak" SysV semaphores if processes crash + before the semaphore is removed.
+The semaphore API allows for a denial of service attack by any
+ CGIs running under the same uid as the webserver (i.e.,
+ all CGIs, unless you use something like suexec
+ or cgiwrapper).
sem
+ This selects the "best" available semaphore implementation, choosing + between Posix and SystemV IPC semaphores, in that order.
pthread
+ This is a mutex variant based on cross-process Posix thread + mutexes.
+ +On most systems, if a child process terminates abnormally while + holding a mutex that uses this implementation, the server will deadlock + and stop responding to requests. When this occurs, the server will + require a manual restart to recover.
+Solaris is a notable exception as it provides a mechanism which + usually allows the mutex to be recovered after a child process + terminates abnormally while holding a mutex.
+If your system implements the
+ pthread_mutexattr_setrobust_np() function, you may be able
+ to use the pthread option safely.
fcntl:/path/to/mutex
+ This is a mutex variant where a physical (lock-)file and the
+ fcntl() function are used as the mutex.
When multiple mutexes based on this mechanism are used within
+ multi-threaded, multi-process environments, deadlock errors (EDEADLK)
+ can be reported for valid mutex operations if fcntl()
+ is not thread-aware, such as on Solaris.
flock:/path/to/mutex
+ This is similar to the fcntl:/path/to/mutex method
+ with the exception that the flock() function is used to
+ provide file locking.
file:/path/to/mutex
+ This selects the "best" available file locking implementation,
+ choosing between fcntl and flock, in that
+ order.
Most mechanisms are only available on selected platforms, where the + underlying platform and APR support it. Mechanisms + which aren't available on all platforms are posixsem, + sysvsem, sem, pthread, fcntl, + flock, and file.
+ +With the file-based mechanisms fcntl and flock,
+ the path, if provided, is a directory where the lock file will be created.
+ The default directory is httpd's run-time file directory relative to
+ ServerRoot. Always use a local disk
+ filesystem for /path/to/mutex and never a directory residing
+ on a NFS- or AFS-filesystem. The basename of the file will be the mutex
+ type, an optional instance string provided by the module, and unless the
+ OmitPID keyword is specified, the process id of the httpd
+ parent process will be appended to to make the file name unique, avoiding
+ conflicts when multiple httpd instances share a lock file directory. For
+ example, if the mutex name is mpm-accept and the lock file
+ directory is /var/httpd/locks, the lock file name for the
+ httpd instance with parent process id 12345 would be
+ /var/httpd/locks/mpm-accept.12345.
It is best to avoid putting mutex files in a world-writable
+ directory such as /var/tmp because someone could create
+ a denial of service attack and prevent the server from starting by
+ creating a lockfile with the same name as the one the server will try
+ to create.
The following table documents the names of mutexes used by httpd + and bundled modules.
+ +| Mutex name | +Module(s) | +Protected resource | +
|---|---|---|
mpm-accept |
+ prefork and worker MPMs |
+ incoming connections, to avoid the thundering herd problem; + for more information, refer to the + performance tuning + documentation | +
authdigest-client |
+ mod_auth_digest |
+ client list in shared memory | +
authdigest-opaque |
+ mod_auth_digest |
+ counter in shared memory | +
ldap-cache |
+ mod_ldap |
+ LDAP result cache | +
rewrite-map |
+ mod_rewrite |
+ communication with external mapping programs, to avoid + intermixed I/O from multiple requests | +
ssl-cache |
+ mod_ssl |
+ SSL session cache | +
ssl-stapling |
+ mod_ssl |
+ OCSP stapling response cache | +
watchdog-callback |
+ mod_watchdog |
+ callback function of a particular client module | +
The OmitPID keyword suppresses the addition of the httpd
+ parent process id from the lock file name.
In the following example, the mutex mechanism for the MPM accept
+ mutex will be changed from the compiled-in default to fcntl,
+ with the associated lock file created in directory
+ /var/httpd/locks. The mutex mechanism for all other mutexes
+ will be changed from the compiled-in default to sysvsem.
+ Mutex default sysvsem
+ Mutex mpm-accept fcntl:/var/httpd/locks
+
| Descripción: | Designates an IP address for name-virtual +hosting |
|---|---|
| Sintaxis: | NameVirtualHost addr[:port] |
| Contexto: | server config |
| Estado: | Core |
| Módulo: | core |
A single NameVirtualHost directive
+identifies a set of identical virtual hosts on which the server will
+further select from on the basis of the hostname
+requested by the client. The NameVirtualHost
+directive is a required directive if you want to configure
+name-based virtual hosts.
This directive, and the corresponding VirtualHost,
+must be qualified with a port number if the server supports both HTTP
+and HTTPS connections.
Although addr can be a hostname, it is recommended +that you always use an IP address or a wildcard. A wildcard +NameVirtualHost matches only virtualhosts that also have a literal wildcard +as their argument.
+ +In cases where a firewall or other proxy receives the requests and +forwards them on a different IP address to the server, you must specify the +IP address of the physical interface on the machine which will be +servicing the requests.
+ +In the example below, requests received on interface 192.0.2.1 and port 80 +will only select among the first two virtual hosts. Requests received on +port 80 on any other interface will only select among the third and fourth +virtual hosts. In the common case where the interface isn't important +to the mapping, only the "*:80" NameVirtualHost and VirtualHost directives +are necessary.
+ +
+ NameVirtualHost 192.0.2.1:80
+ NameVirtualHost *:80
+
+ <VirtualHost 192.0.2.1:80>
+ ServerName namebased-a.example.com
+ </VirtualHost>
+
+ <VirtualHost 192.0.2.1:80>
+ Servername namebased-b.example.com
+ </VirtualHost>
+
+ <VirtualHost *:80>
+ ServerName namebased-c.example.com
+ </VirtualHost>
+
+ <VirtualHost *:80>
+ ServerName namebased-d.example.com
+ </VirtualHost>
+
+
+
If no matching virtual host is found, then the first listed + virtual host that matches the IP address and port will be used.
+ + +IPv6 addresses must be enclosed in square brackets, as shown + in the following example:
+ +
+ NameVirtualHost [2001:db8::a00:20ff:fea7:ccea]:8080
+
<VirtualHost>
+ directiveNote that the argument to the <VirtualHost> directive must
+ exactly match the argument to the NameVirtualHost directive.
+ NameVirtualHost 192.0.2.2:80
+ <VirtualHost 192.0.2.2:80>
+ # ...
+ </VirtualHost>
+
| Descripción: | Configures what features are available in a particular +directory |
|---|---|
| Sintaxis: | Options
+ [+|-]option [[+|-]option] ... |
| Valor por defecto: | Options All |
| Contexto: | server config, virtual host, directory, .htaccess |
| Prevalece sobre: | Options |
| Estado: | Core |
| Módulo: | core |
The Options directive controls which
+ server features are available in a particular directory.
option can be set to None, in which
+ case none of the extra features are enabled, or one or more of
+ the following:
AllMultiViews. This is the default
+ setting.ExecCGImod_cgi
+ is permitted.FollowSymLinksEven though the server follows the symlink it does not
+ change the pathname used to match against <Directory> sections.
Note also, that this option gets ignored if set
+ inside a <Location>
+ section.
Omitting this option should not be considered a security restriction, + since symlink testing is subject to race conditions that make it + circumventable.
+Includesmod_include
+ are permitted.IncludesNOEXEC#exec
+ cmd and #exec cgi are disabled. It is still
+ possible to #include virtual CGI scripts from
+ ScriptAliased
+ directories.IndexesDirectoryIndex
+ (e.g., index.html) in that directory, then
+ mod_autoindex will return a formatted listing
+ of the directory.MultiViewsmod_negotiation.
+ This option gets ignored if set
+ anywhere other than <Directory>, as mod_negotiation
+ needs real resources to compare against and evaluate from.
SymLinksIfOwnerMatchThis option gets ignored if
+ set inside a <Location> section.
This option should not be considered a security restriction, + since symlink testing is subject to race conditions that make it + circumventable.
Normally, if multiple Options could
+ apply to a directory, then the most specific one is used and
+ others are ignored; the options are not merged. (See how sections are merged.)
+ However if all the options on the
+ Options directive are preceded by a
+ + or - symbol, the options are
+ merged. Any options preceded by a + are added to the
+ options currently in force, and any options preceded by a
+ - are removed from the options currently in
+ force.
Mixing Options with a + or
+ - with those without is not valid syntax, and is likely
+ to cause unexpected results.
For example, without any + and - symbols:
+ <Directory /web/docs>
+
+ Options Indexes FollowSymLinks
+
+ </Directory>
+
+ <Directory /web/docs/spec>
+
+ Options Includes
+
+ </Directory>
+
then only Includes will be set for the
+ /web/docs/spec directory. However if the second
+ Options directive uses the + and
+ - symbols:
+ <Directory /web/docs>
+
+ Options Indexes FollowSymLinks
+
+ </Directory>
+
+ <Directory /web/docs/spec>
+
+ Options +Includes -Indexes
+
+ </Directory>
+
then the options FollowSymLinks and
+ Includes are set for the /web/docs/spec
+ directory.
Using -IncludesNOEXEC or
+ -Includes disables server-side includes completely
+ regardless of the previous setting.
The default in the absence of any other settings is
+ All.
| Descripción: | Protocol for a listening socket |
|---|---|
| Sintaxis: | Protocol protocol |
| Contexto: | server config, virtual host |
| Estado: | Core |
| Módulo: | core |
| Compatibilidad: | Available in Apache 2.1.5 and later. +On Windows from Apache 2.3.3 and later. |
This directive specifies the protocol used for a specific listening socket.
+ The protocol is used to determine which module should handle a request, and
+ to apply protocol specific optimizations with the AcceptFilter
+ directive.
You only need to set the protocol if you are running on non-standard ports, otherwise http is assumed for port 80 and https for port 443.
For example, if you are running https on a non-standard port, specify the protocol explicitly:
+ Protocol https
+
You can also specify the protocol using the Listen directive.
AcceptFilterListen| Descripción: | Limits the CPU consumption of processes launched +by Apache httpd children |
|---|---|
| Sintaxis: | RLimitCPU seconds|max [seconds|max] |
| Valor por defecto: | Unset; uses operating system defaults |
| Contexto: | server config, virtual host, directory, .htaccess |
| Prevalece sobre: | All |
| Estado: | Core |
| Módulo: | core |
Takes 1 or 2 parameters. The first parameter sets the soft
+ resource limit for all processes and the second parameter sets
+ the maximum resource limit. Either parameter can be a number,
+ or max to indicate to the server that the limit should
+ be set to the maximum allowed by the operating system
+ configuration. Raising the maximum resource limit requires that
+ the server is running as root, or in the initial startup
+ phase.
This applies to processes forked off from Apache httpd children + servicing requests, not the Apache httpd children themselves. This + includes CGI scripts and SSI exec commands, but not any + processes forked off from the Apache httpd parent such as piped + logs.
+ +CPU resource limits are expressed in seconds per + process.
+ +RLimitMEMRLimitNPROC| Descripción: | Limits the memory consumption of processes launched +by Apache httpd children |
|---|---|
| Sintaxis: | RLimitMEM bytes|max [bytes|max] |
| Valor por defecto: | Unset; uses operating system defaults |
| Contexto: | server config, virtual host, directory, .htaccess |
| Prevalece sobre: | All |
| Estado: | Core |
| Módulo: | core |
Takes 1 or 2 parameters. The first parameter sets the soft
+ resource limit for all processes and the second parameter sets
+ the maximum resource limit. Either parameter can be a number,
+ or max to indicate to the server that the limit should
+ be set to the maximum allowed by the operating system
+ configuration. Raising the maximum resource limit requires that
+ the server is running as root, or in the initial startup
+ phase.
This applies to processes forked off from Apache httpd children + servicing requests, not the Apache httpd children themselves. This + includes CGI scripts and SSI exec commands, but not any + processes forked off from the Apache httpd parent such as piped + logs.
+ +Memory resource limits are expressed in bytes per + process.
+ +RLimitCPURLimitNPROC| Descripción: | Limits the number of processes that can be launched by +processes launched by Apache httpd children |
|---|---|
| Sintaxis: | RLimitNPROC number|max [number|max] |
| Valor por defecto: | Unset; uses operating system defaults |
| Contexto: | server config, virtual host, directory, .htaccess |
| Prevalece sobre: | All |
| Estado: | Core |
| Módulo: | core |
Takes 1 or 2 parameters. The first parameter sets the soft
+ resource limit for all processes and the second parameter sets
+ the maximum resource limit. Either parameter can be a number,
+ or max to indicate to the server that the limit
+ should be set to the maximum allowed by the operating system
+ configuration. Raising the maximum resource limit requires that
+ the server is running as root, or in the initial startup
+ phase.
This applies to processes forked off from Apache httpd children + servicing requests, not the Apache httpd children themselves. This + includes CGI scripts and SSI exec commands, but not any + processes forked off from the Apache httpd parent such as piped + logs.
+ +Process limits control the number of processes per user.
+ +If CGI processes are not running
+ under user ids other than the web server user id, this directive
+ will limit the number of processes that the server itself can
+ create. Evidence of this situation will be indicated by
+ cannot fork messages in the
+ error_log.
| Descripción: | Technique for locating the interpreter for CGI +scripts |
|---|---|
| Sintaxis: | ScriptInterpreterSource Registry|Registry-Strict|Script |
| Valor por defecto: | ScriptInterpreterSource Script |
| Contexto: | server config, virtual host, directory, .htaccess |
| Prevalece sobre: | FileInfo |
| Estado: | Core |
| Módulo: | core |
| Compatibilidad: | Win32 only;
+option Registry-Strict is available in Apache HTTP Server 2.0 and
+later |
This directive is used to control how Apache httpd finds the
+ interpreter used to run CGI scripts. The default setting is
+ Script. This causes Apache httpd to use the interpreter pointed to
+ by the shebang line (first line, starting with #!) in the
+ script. On Win32 systems this line usually looks like:
+ #!C:/Perl/bin/perl.exe
+
or, if perl is in the PATH, simply:
+ #!perl
+
Setting ScriptInterpreterSource Registry will
+ cause the Windows Registry tree HKEY_CLASSES_ROOT to be
+ searched using the script file extension (e.g., .pl) as a
+ search key. The command defined by the registry subkey
+ Shell\ExecCGI\Command or, if it does not exist, by the subkey
+ Shell\Open\Command is used to open the script file. If the
+ registry keys cannot be found, Apache httpd falls back to the behavior of the
+ Script option.
Be careful when using ScriptInterpreterSource
+ Registry with ScriptAlias'ed directories, because
+ Apache httpd will try to execute every file within this
+ directory. The Registry setting may cause undesired
+ program calls on files which are typically not executed. For
+ example, the default open command on .htm files on
+ most Windows systems will execute Microsoft Internet Explorer, so
+ any HTTP request for an .htm file existing within the
+ script directory would start the browser in the background on the
+ server. This is a good way to crash your system within a minute or
+ so.
The option Registry-Strict which is new in Apache HTTP Server
+ 2.0 does the same thing as Registry but uses only the
+ subkey Shell\ExecCGI\Command. The
+ ExecCGI key is not a common one. It must be
+ configured manually in the windows registry and hence prevents
+ accidental program calls on your system.
| Descripción: | Determine if mod_status displays the first 63 characters +of a request or the last 63, assuming the request itself is greater than +63 chars. |
|---|---|
| Sintaxis: | SeeRequestTail On|Off |
| Valor por defecto: | SeeRequestTail Off |
| Contexto: | server config |
| Estado: | Core |
| Módulo: | core |
| Compatibilidad: | Available in Apache httpd 2.2.7 and later. |
mod_status with ExtendedStatus On
+ displays the actual request being handled.
+ For historical purposes, only 63 characters of the request
+ are actually stored for display purposes. This directive
+ controls whether the 1st 63 characters are stored (the previous
+ behavior and the default) or if the last 63 characters are. This
+ is only applicable, of course, if the length of the request is
+ 64 characters or greater.
If Apache httpd is handling GET /disk1/storage/apache/htdocs/images/imagestore1/food/apples.jpg HTTP/1.1 mod_status displays as follows:
+
| Off (default) | +GET /disk1/storage/apache/htdocs/images/imagestore1/food/apples | +
|---|---|
| On | +orage/apache/htdocs/images/imagestore1/food/apples.jpg HTTP/1.1 | +
| Descripción: | Email address that the server includes in error +messages sent to the client |
|---|---|
| Sintaxis: | ServerAdmin email-address|URL |
| Contexto: | server config, virtual host |
| Estado: | Core |
| Módulo: | core |
The ServerAdmin sets the contact address
+ that the server includes in any error messages it returns to the
+ client. If the httpd doesn't recognize the supplied argument
+ as an URL, it
+ assumes, that it's an email-address and prepends it with
+ mailto: in hyperlink targets. However, it's recommended to
+ actually use an email address, since there are a lot of CGI scripts that
+ make that assumption. If you want to use an URL, it should point to another
+ server under your control. Otherwise users may not be able to contact you in
+ case of errors.
It may be worth setting up a dedicated address for this, e.g.
+ +
+ ServerAdmin www-admin@foo.example.com
+
as users do not always mention that they are talking about the + server!
+ +| Descripción: | Alternate names for a host used when matching requests +to name-virtual hosts |
|---|---|
| Sintaxis: | ServerAlias hostname [hostname] ... |
| Contexto: | virtual host |
| Estado: | Core |
| Módulo: | core |
The ServerAlias directive sets the
+ alternate names for a host, for use with name-based virtual hosts. The
+ ServerAlias may include wildcards, if appropriate.
+ <VirtualHost *:80>
+ ServerName server.domain.com
+ ServerAlias server server2.domain.com server2
+ ServerAlias *.example.com
+ UseCanonicalName Off
+ # ...
+ </VirtualHost>
+
| Descripción: | Hostname and port that the server uses to identify +itself |
|---|---|
| Sintaxis: | ServerName [scheme://]fully-qualified-domain-name[:port] |
| Contexto: | server config, virtual host |
| Estado: | Core |
| Módulo: | core |
The ServerName directive sets the
+ request scheme, hostname and
+ port that the server uses to identify itself. This is used when
+ creating redirection URLs.
Additionally, ServerName is used (possibly
+ in conjunction with ServerAlias) to uniquely
+ identify a virtual host, when using name-based virtual hosts.
For example, if the name of the
+ machine hosting the web server is simple.example.com,
+ but the machine also has the DNS alias www.example.com
+ and you wish the web server to be so identified, the following
+ directive should be used:
+ ServerName www.example.com:80
+
The ServerName directive
+ may appear anywhere within the definition of a server. However,
+ each appearance overrides the previous appearance (within that
+ server).
If no ServerName is specified, then the
+ server attempts to deduce the hostname by performing a reverse
+ lookup on the IP address. If no port is specified in the
+ ServerName, then the server will use the
+ port from the incoming request. For optimal reliability and
+ predictability, you should specify an explicit hostname and port
+ using the ServerName directive.
If you are using name-based virtual hosts,
+ the ServerName inside a
+ <VirtualHost>
+ section specifies what hostname must appear in the request's
+ Host: header to match this virtual host.
Sometimes, the server runs behind a device that processes SSL,
+ such as a reverse proxy, load balancer or SSL offload
+ appliance. When this is the case, specify the
+ https:// scheme and the port number to which the
+ clients connect in the ServerName directive
+ to make sure that the server generates the correct
+ self-referential URLs.
+
See the description of the
+ UseCanonicalName and
+ UseCanonicalPhysicalPort directives for
+ settings which determine whether self-referential URLs (e.g., by the
+ mod_dir module) will refer to the
+ specified port, or to the port number given in the client's request.
+
Failure to set ServerName to a name that
+ your server can resolve to an IP address will result in a startup
+ warning. httpd will then use whatever hostname it can
+ determine, using the system's hostname command. This
+ will almost never be the hostname you actually want.
+ httpd: Could not reliably determine the server's fully qualified domain name, using rocinante.local for ServerName
+
| Descripción: | Legacy URL pathname for a name-based virtual host that +is accessed by an incompatible browser |
|---|---|
| Sintaxis: | ServerPath URL-path |
| Contexto: | virtual host |
| Estado: | Core |
| Módulo: | core |
The ServerPath directive sets the legacy
+ URL pathname for a host, for use with name-based virtual hosts.
| Descripción: | Base directory for the server installation |
|---|---|
| Sintaxis: | ServerRoot directory-path |
| Valor por defecto: | ServerRoot /usr/local/apache |
| Contexto: | server config |
| Estado: | Core |
| Módulo: | core |
The ServerRoot directive sets the
+ directory in which the server lives. Typically it will contain the
+ subdirectories conf/ and logs/. Relative
+ paths in other configuration directives (such as Include or LoadModule, for example) are taken as
+ relative to this directory.
+ ServerRoot /home/httpd
+
-d
+ option to httpdServerRoot| Descripción: | Configures the footer on server-generated documents |
|---|---|
| Sintaxis: | ServerSignature On|Off|EMail |
| Valor por defecto: | ServerSignature Off |
| Contexto: | server config, virtual host, directory, .htaccess |
| Prevalece sobre: | All |
| Estado: | Core |
| Módulo: | core |
The ServerSignature directive allows the
+ configuration of a trailing footer line under server-generated
+ documents (error messages, mod_proxy ftp directory
+ listings, mod_info output, ...). The reason why you
+ would want to enable such a footer line is that in a chain of proxies,
+ the user often has no possibility to tell which of the chained servers
+ actually produced a returned error message.
The Off
+ setting, which is the default, suppresses the footer line (and is
+ therefore compatible with the behavior of Apache-1.2 and
+ below). The On setting simply adds a line with the
+ server version number and ServerName of the serving virtual host,
+ and the EMail setting additionally creates a
+ "mailto:" reference to the ServerAdmin of the referenced
+ document.
After version 2.0.44, the details of the server version number
+ presented are controlled by the ServerTokens directive.
ServerTokens| Descripción: | Configures the Server HTTP response
+header |
|---|---|
| Sintaxis: | ServerTokens Major|Minor|Min[imal]|Prod[uctOnly]|OS|Full |
| Valor por defecto: | ServerTokens Full |
| Contexto: | server config |
| Estado: | Core |
| Módulo: | core |
This directive controls whether Server response
+ header field which is sent back to clients includes a
+ description of the generic OS-type of the server as well as
+ information about compiled-in modules.
ServerTokens Full (or not specified)Server: Apache/2.4.1
+ (Unix) PHP/4.2.2 MyMod/1.2ServerTokens Prod[uctOnly]Server:
+ ApacheServerTokens MajorServer:
+ Apache/2ServerTokens MinorServer:
+ Apache/2.4ServerTokens Min[imal]Server:
+ Apache/2.4.1ServerTokens OSServer: Apache/2.4.1
+ (Unix)This setting applies to the entire server, and cannot be + enabled or disabled on a virtualhost-by-virtualhost basis.
+ +After version 2.0.44, this directive also controls the
+ information presented by the ServerSignature directive.
ServerTokens to less than
+ minimal is not recommended because it makes it more
+ difficult to debug interoperational problems. Also note that
+ disabling the Server: header does nothing at all to make your
+ server more secure; the idea of "security through obscurity"
+ is a myth and leads to a false sense of safety.| Descripción: | Forces all matching files to be processed by a +handler |
|---|---|
| Sintaxis: | SetHandler handler-name|None |
| Contexto: | server config, virtual host, directory, .htaccess |
| Prevalece sobre: | FileInfo |
| Estado: | Core |
| Módulo: | core |
| Compatibilidad: | Moved into the core in Apache httpd 2.0 |
When placed into an .htaccess file or a
+ <Directory> or
+ <Location>
+ section, this directive forces all matching files to be parsed
+ through the handler given by
+ handler-name. For example, if you had a directory you
+ wanted to be parsed entirely as imagemap rule files, regardless
+ of extension, you might put the following into an
+ .htaccess file in that directory:
+ SetHandler imap-file
+
Another example: if you wanted to have the server display a
+ status report whenever a URL of
+ http://servername/status was called, you might put
+ the following into httpd.conf:
+ <Location /status>
+
+ SetHandler server-status
+
+ </Location>
+
You can override an earlier defined SetHandler
+ directive by using the value None.
Note: because SetHandler overrides default handlers, + normal behaviour such as handling of URLs ending in a slash (/) as + directories or index files is suppressed.
+ +AddHandler| Descripción: | Sets the filters that will process client requests and POST +input |
|---|---|
| Sintaxis: | SetInputFilter filter[;filter...] |
| Contexto: | server config, virtual host, directory, .htaccess |
| Prevalece sobre: | FileInfo |
| Estado: | Core |
| Módulo: | core |
The SetInputFilter directive sets the
+ filter or filters which will process client requests and POST
+ input when they are received by the server. This is in addition to
+ any filters defined elsewhere, including the
+ AddInputFilter
+ directive.
If more than one filter is specified, they must be separated + by semicolons in the order in which they should process the + content.
+ +| Descripción: | Sets the filters that will process responses from the +server |
|---|---|
| Sintaxis: | SetOutputFilter filter[;filter...] |
| Contexto: | server config, virtual host, directory, .htaccess |
| Prevalece sobre: | FileInfo |
| Estado: | Core |
| Módulo: | core |
The SetOutputFilter directive sets the filters
+ which will process responses from the server before they are
+ sent to the client. This is in addition to any filters defined
+ elsewhere, including the
+ AddOutputFilter
+ directive.
For example, the following configuration will process all files
+ in the /www/data/ directory for server-side
+ includes.
+ <Directory /www/data/>
+
+ SetOutputFilter INCLUDES
+
+ </Directory>
+
If more than one filter is specified, they must be separated + by semicolons in the order in which they should process the + content.
+ +| Descripción: | Amount of time the server will wait for +certain events before failing a request |
|---|---|
| Sintaxis: | TimeOut seconds |
| Valor por defecto: | TimeOut 300 |
| Contexto: | server config, virtual host |
| Estado: | Core |
| Módulo: | core |
The TimeOut directive defines the length
+ of time Apache httpd will wait for I/O in various circumstances:
mod_cgi, the length of time to wait for
+ output from a CGI script.mod_ext_filter, the length of time to
+ wait for output from a filtering process.mod_proxy, the default timeout value if
+ ProxyTimeout is not
+ configured.| Descripción: | Determines the behaviour on TRACE requests |
|---|---|
| Sintaxis: | TraceEnable [on|off|extended] |
| Valor por defecto: | TraceEnable on |
| Contexto: | server config |
| Estado: | Core |
| Módulo: | core |
| Compatibilidad: | Available in Apache HTTP Server 1.3.34, 2.0.55 and later |
This directive overrides the behavior of TRACE for both
+ the core server and mod_proxy. The default
+ TraceEnable on permits TRACE requests per
+ RFC 2616, which disallows any request body to accompany the request.
+ TraceEnable off causes the core server and
+ mod_proxy to return a 405 (Method not
+ allowed) error to the client.
Finally, for testing and diagnostic purposes only, request
+ bodies may be allowed using the non-compliant TraceEnable
+ extended directive. The core (as an origin server) will
+ restrict the request body to 64k (plus 8k for chunk headers if
+ Transfer-Encoding: chunked is used). The core will
+ reflect the full headers and all chunk headers with the response
+ body. As a proxy server, the request body is not restricted to 64k.
| Descripción: | Undefine the existence of a variable |
|---|---|
| Sintaxis: | UnDefine parameter-name |
| Contexto: | server config |
| Estado: | Core |
| Módulo: | core |
Undoes the effect of a Define or
+ of passing a -D argument to httpd.
This directive can be used to toggle the use of <IfDefine> sections without needing to alter
+ -D arguments in any startup scripts.
| Descripción: | Configures how the server determines its own name and +port |
|---|---|
| Sintaxis: | UseCanonicalName On|Off|DNS |
| Valor por defecto: | UseCanonicalName Off |
| Contexto: | server config, virtual host, directory |
| Estado: | Core |
| Módulo: | core |
In many situations Apache httpd must construct a self-referential
+ URL -- that is, a URL that refers back to the same server. With
+ UseCanonicalName On Apache httpd will use the hostname and port
+ specified in the ServerName
+ directive to construct the canonical name for the server. This name
+ is used in all self-referential URLs, and for the values of
+ SERVER_NAME and SERVER_PORT in CGIs.
With UseCanonicalName Off Apache httpd will form
+ self-referential URLs using the hostname and port supplied by
+ the client if any are supplied (otherwise it will use the
+ canonical name, as defined above). These values are the same
+ that are used to implement name-based virtual hosts,
+ and are available with the same clients. The CGI variables
+ SERVER_NAME and SERVER_PORT will be
+ constructed from the client supplied values as well.
An example where this may be useful is on an intranet server
+ where you have users connecting to the machine using short
+ names such as www. You'll notice that if the users
+ type a shortname, and a URL which is a directory, such as
+ http://www/splat, without the trailing
+ slash then Apache httpd will redirect them to
+ http://www.domain.com/splat/. If you have
+ authentication enabled, this will cause the user to have to
+ authenticate twice (once for www and once again
+ for www.domain.com -- see the
+ FAQ on this subject for more information). But if
+ UseCanonicalName is set Off, then
+ Apache httpd will redirect to http://www/splat/.
There is a third option, UseCanonicalName DNS,
+ which is intended for use with mass IP-based virtual hosting to
+ support ancient clients that do not provide a
+ Host: header. With this option Apache httpd does a
+ reverse DNS lookup on the server IP address that the client
+ connected to in order to work out self-referential URLs.
If CGIs make assumptions about the values of SERVER_NAME
+ they may be broken by this option. The client is essentially free
+ to give whatever value they want as a hostname. But if the CGI is
+ only using SERVER_NAME to construct self-referential URLs
+ then it should be just fine.
| Descripción: | Configures how the server determines its own name and +port |
|---|---|
| Sintaxis: | UseCanonicalPhysicalPort On|Off |
| Valor por defecto: | UseCanonicalPhysicalPort Off |
| Contexto: | server config, virtual host, directory |
| Estado: | Core |
| Módulo: | core |
In many situations Apache httpd must construct a self-referential
+ URL -- that is, a URL that refers back to the same server. With
+ UseCanonicalPhysicalPort On Apache httpd will, when
+ constructing the canonical port for the server to honor
+ the UseCanonicalName directive,
+ provide the actual physical port number being used by this request
+ as a potential port. With UseCanonicalPhysicalPort Off
+ Apache httpd will not ever use the actual physical port number, instead
+ relying on all configured information to construct a valid port number.
The ordering of when the physical port is used is as follows:
+ UseCanonicalName On
ServernameUseCanonicalName Off | DNS
+ Host: headerServernameWith UseCanonicalPhysicalPort Off, the
+ physical ports are removed from the ordering.
| Descripción: | Contains directives that apply only to a specific +hostname or IP address |
|---|---|
| Sintaxis: | <VirtualHost
+ addr[:port] [addr[:port]]
+ ...> ... </VirtualHost> |
| Contexto: | server config |
| Estado: | Core |
| Módulo: | core |
<VirtualHost> and
+ </VirtualHost> are used to enclose a group of
+ directives that will apply only to a particular virtual host. Any
+ directive that is allowed in a virtual host context may be
+ used. When the server receives a request for a document on a
+ particular virtual host, it uses the configuration directives
+ enclosed in the <VirtualHost>
+ section. Addr can be:
*, which is used only in combination with
+ NameVirtualHost * to match all IP addresses; or_default_, which is used only
+ with IP virtual hosting to catch unmatched IP addresses.
+ <VirtualHost 10.1.2.3>
+
+ ServerAdmin webmaster@host.example.com
+ DocumentRoot /www/docs/host.example.com
+ ServerName host.example.com
+ ErrorLog logs/host.example.com-error_log
+ TransferLog logs/host.example.com-access_log
+
+ </VirtualHost>
+
IPv6 addresses must be specified in square brackets because + the optional port number could not be determined otherwise. An + IPv6 example is shown below:
+ +
+ <VirtualHost [2001:db8::a00:20ff:fea7:ccea]>
+
+ ServerAdmin webmaster@host.example.com
+ DocumentRoot /www/docs/host.example.com
+ ServerName host.example.com
+ ErrorLog logs/host.example.com-error_log
+ TransferLog logs/host.example.com-access_log
+
+ </VirtualHost>
+
Each Virtual Host must correspond to a different IP address,
+ different port number or a different host name for the server,
+ in the former case the server machine must be configured to
+ accept IP packets for multiple addresses. (If the machine does
+ not have multiple network interfaces, then this can be
+ accomplished with the ifconfig alias command -- if
+ your OS supports it).
The use of <VirtualHost> does
+ not affect what addresses Apache httpd listens on. You
+ may need to ensure that Apache httpd is listening on the correct addresses
+ using Listen.
When using IP-based virtual hosting, the special name
+ _default_ can be specified in
+ which case this virtual host will match any IP address that is
+ not explicitly listed in another virtual host. In the absence
+ of any _default_ virtual host the "main" server config,
+ consisting of all those definitions outside any VirtualHost
+ section, is used when no IP-match occurs.
You can specify a :port to change the port that is
+ matched. If unspecified then it defaults to the same port as the
+ most recent Listen
+ statement of the main server. You may also specify :*
+ to match all ports on that address. (This is recommended when used
+ with _default_.)
A ServerName should be
+ specified inside each <VirtualHost> block. If it is absent, the
+ ServerName from the "main"
+ server configuration will be inherited.
If no matching virtual host is found, then the first listed + virtual host that matches the IP address will be used. As a + consequence, the first listed virtual host is the default virtual + host.
+ +See the security tips + 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.
+