The directory sections typically occur in
the access.conf file, but they may appear in any configuration
file. <Directory> directives
- cannot nest, and cannot appear in a <Limit> or <LimitExcept> section.
+ cannot nest, and cannot appear in a <Limit> or <LimitExcept> section.
See also
Description: | Enclose a group of directives that apply only to
+ request is received
Description: | Enclose a group of directives that apply only to
file-system directories that match a regular expression and their
-subdirectories | Syntax: | <Directory regex>
-... </Directory> | Context: | server config, virtual host | Status: | Core | Module: | core |
|
+subdirectories | Syntax: | <Directory regex>
+... </Directory> | Context: | server config, virtual host | Status: | Core | Module: | core |
|
<DirectoryMatch> and
</DirectoryMatch> are used to enclose a group
of directives which will apply only to the named directory and
- sub-directories of that directory, the same as <Directory> . However, it
+ sub-directories of that directory, the same as <Directory> . However, it
takes as an argument a regular expression. For example:
<DirectoryMatch "^/www/.*/[0-9]{3}">
@@ -343,12 +343,12 @@ subdirectories | <Directory> for
+See also
Description: | Sets the directory that forms the main document tree visible
-from the web | Syntax: | DocumentRoot directory-path | Default: | DocumentRoot /usr/local/apache/htdocs | Context: | server config, virtual host | Status: | Core | Module: | core |
|
+combined when a request is received
Description: | Sets the directory that forms the main document tree visible
+from the web | Syntax: | DocumentRoot directory-path | Default: | DocumentRoot /usr/local/apache/htdocs | Context: | server config, virtual host | Status: | Core | Module: | 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
@@ -363,8 +363,35 @@ from the web |
The DocumentRoot should be specified without
a trailing slash.
See also
Description: | Specifies what the server will return to the client
-in case of an error | Syntax: | ErrorDocument error-code document | Context: | server config, virtual host, directory, .htaccess | Override: | FileInfo | Status: | Core | Module: | core | Compatibility: | Quoting syntax for text messages is different in Apache
+Location
Description: | Controls whether the httpd uses memory-mapping to read files
+during delivery | Syntax: | EnableMMAP on|off | Default: | EnableMMAP on | Context: | server config, virtual host, directory, .htaccess | Status: | Core | Module: | 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 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:
+
+
+ - On some multiprocessor systems, memory-mapping can reduce the
+ performance of the httpd.
+ - With an NFS-mounted
DocumentRoot ,
+ the httpd may crash due tof a segmentation fault if a file is deleted
+ or truncated while the httpd has it memory-mapped.
+
+
+ For server configurations that are vulnerable to these problems,
+ you should disable memory-mapping of delivered files by specifying:
+
+
+
Description: | Specifies what the server will return to the client
+in case of an error | Syntax: | ErrorDocument error-code document | Context: | server config, virtual host, directory, .htaccess | Override: | FileInfo | Status: | Core | Module: | core | Compatibility: | Quoting syntax for text messages is different in Apache
2.0 |
|
In the event of a problem or error, Apache can be configured
to do one of four things,
@@ -393,9 +420,9 @@ in case of an error |
ErrorDocument 500
- http://foo.example.com/cgi-bin/tester
- ErrorDocument 404 /cgi-bin/bad_urls.pl
- ErrorDocument 401 /subscription_info.html
+ 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"
| |
@@ -419,13 +446,13 @@ in case of an error | documentation of
- customizable responses
Description: | Sets the name of the file to which the server
-will log errors | Syntax: | ErrorLog file-path|syslog[:facility] | Default: | ErrorLog logs/error_log (Unix)
-ErrorLog logs/error.log (Windows and OS/2) | Context: | server config, virtual host | Status: | Core | Module: | core |
|
+ customizable responses
Description: | Sets the name of the file to which the server
+will log errors | Syntax: | ErrorLog file-path|syslog[:facility] | Default: | ErrorLog logs/error_log (Unix)
+ErrorLog logs/error.log (Windows and OS/2) | Context: | server config, virtual host | Status: | Core | Module: | core |
|
The ErrorLog directive sets the name of
the file to which the server will log any errors it encounters. If
the file-path does not begin with a slash (/) then it is
- assumed to be relative to the ServerRoot . If the file-path
+ assumed to be relative to the ServerRoot . If the file-path
begins with a pipe (|) then it is assumed to be a command to spawn
to handle the error log.
@@ -440,8 +467,8 @@ ErrorLog logs/error.log (Windows and OS/2) | LogLevel Apache Log Files
Description: | Configures the file attributes used to create the ETag
-HTTP response header | Syntax: | FileETag component ... | Context: | server config, virtual host, directory, .htaccess | Override: | FileInfo | Status: | Core | Module: | core |
|
+See also
Description: | Configures the file attributes used to create the ETag
+HTTP response header | Syntax: | FileETag component ... | Context: | server config, virtual host, directory, .htaccess | Override: | FileInfo | Status: | Core | Module: | core |
|
The FileETag directive configures the file
attributes that are used to create the ETag (entity tag) response
@@ -481,21 +508,21 @@ HTTP response header | <Files> DirectiveDescription: | Contains that directives that apply to matched
-filenames | Syntax: | <Files filename> ... </Files> | Context: | server config, virtual host, directory, .htaccess | Status: | Core | Module: | core |
|
+
Description: | Contains that directives that apply to matched
+filenames | Syntax: | <Files filename> ... </Files> | Context: | server config, virtual host, directory, .htaccess | Status: | Core | Module: | core |
|
The <Files> directive
provides for access control by filename. It is comparable to the
- Directory
- directive and Location directives. It should be
+ Directory
+ directive 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
+ 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
+ inside <Directory> sections to restrict the
portion of the filesystem they apply to.
The filename argument should include a filename, or
@@ -507,19 +534,19 @@ filenames | Syn
<Files ~ "\.(gif|jpe?g|png)$">
|
would match most common Internet graphics formats. In Apache 1.3
- and later, <FilesMatch> is preferred, however.
+ and later, <FilesMatch> is preferred, however.
- Note that unlike <Directory> and <Location> sections, <Files> sections can be used inside
+ 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.
See also
Description: | Contains that directives that apply to regular-expression matched
-filenames | Syntax: | <FilesMatch regex> ... </FilesMatch> | Context: | server config, virtual host, directory, .htaccess | Status: | Core | Module: | core |
|
+ request is received
Description: | Contains that directives that apply to regular-expression matched
+filenames | Syntax: | <FilesMatch regex> ... </FilesMatch> | Context: | server config, virtual host, directory, .htaccess | Status: | Core | Module: | core |
|
The <FilesMatch> directive
- provides for access control by filename, just as the <Files> directive
+ provides for access control by filename, just as the <Files> directive
does. However, it accepts a regular expression. For example:
<FilesMatch "\.(gif|jpe?g|png)$">
@@ -529,12 +556,12 @@ filenames | Syn
See also
+ request is received
When placed into an .htaccess file or a
- <Directory> , or
- <Location> or
- <Files>
+ <Directory> , or
+ <Location> or
+ <Files>
section, this directive forces all matching files to be served
with the content type identification given by
mime-type. For example, if you had a directory full of
@@ -544,10 +571,10 @@ MIME content-type | DefaultType ,
+ Note that unlike DefaultType ,
this directive overrides all mime-type associations, including
filename extensions, that might identify the media type.
-
Description: | Enables DNS lookups on client IP addresses | Syntax: | HostnameLookups on|off|double | Default: | HostnameLookups off | Context: | server config, virtual host, directory | Status: | Core | Module: | core |
|
+
Description: | Enables DNS lookups on client IP addresses | Syntax: | HostnameLookups on|off|double | Default: | HostnameLookups off | Context: | server config, virtual host, directory | Status: | Core | Module: | 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
@@ -576,8 +603,8 @@ MIME content-type | logresolve, provided in
the /support directory, can be used to look up host
names from logged IP addresses offline.
-
+
This directive enables RFC1413-compliant logging of the
remote user name for each connection, where the client machine
runs identd or something similar. This information is logged in
@@ -592,9 +619,9 @@ user | Syntax:<
possibly fail and add 30 seconds of latency to each hit. So in
general this is not very useful on public servers accessible
from the Internet.
-
Description: | Encloses directives that will be processed only
-if a test is true at startup | Syntax: | <IfDefine [!]parameter-name> ...
- </IfDefine> | Context: | server config, virtual host, directory, .htaccess | Status: | Core | Module: | core |
|
+
Description: | Encloses directives that will be processed only
+if a test is true at startup | Syntax: | <IfDefine [!]parameter-name> ...
+ </IfDefine> | Context: | server config, virtual host, directory, .htaccess | Status: | Core | Module: | core |
|
The <IfDefine
test>...</IfDefine> section is used to
mark directives that are conditional. The directives within an
@@ -635,9 +662,9 @@ if a test is true at startup | <IfModule> DirectiveDescription: | Encloses directives that are processed conditional on the
-presence of absence of a specific module | Syntax: | <IfModule [!]module-name> ...
- </IfModule> | Context: | server config, virtual host, directory, .htaccess | Status: | Core | Module: | core |
|
+
Description: | Encloses directives that are processed conditional on the
+presence of absence of a specific module | Syntax: | <IfModule [!]module-name> ...
+ </IfModule> | Context: | server config, virtual host, directory, .htaccess | Status: | Core | Module: | core |
|
The <IfModule
test>...</IfModule> section is used to
mark directives that are conditional. The directives within an
@@ -657,7 +684,7 @@ presence of absence of a specific module | LoadModule . The second format
+ dynamically loaded using LoadModule . The second format
reverses the test, and only processes the directives if module
name is not included.
@@ -668,8 +695,8 @@ presence of absence of a specific module | <IfModule> sections are
nest-able, which can be used to implement simple multiple-module
tests.
-
Description: | Includes other configuration files from within
-the server configuration files | Syntax: | Include file-path|directory-path | Context: | server config | Status: | Core | Module: | core |
|
+
Description: | Includes other configuration files from within
+the server configuration files | Syntax: | Include file-path|directory-path | Context: | server config | Status: | Core | Module: | core |
|
This directive allows inclusion of other configuration files
from within the server configuration files.
@@ -679,12 +706,12 @@ the server configuration files | ServerRoot directory.
+ ServerRoot directory.
Examples:
- Include /usr/local/apache/conf/ssl.conf
+ Include /usr/local/apache/conf/ssl.conf
Include /usr/local/apache/conf/vhosts/
|
@@ -692,7 +719,7 @@ the server configuration files |
- Include conf/ssl.conf
+ Include conf/ssl.conf
Include conf/vhosts/
| |
@@ -714,7 +741,7 @@ the server configuration files | apachectl
+See also
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
@@ -734,20 +761,20 @@ the server configuration files | MaxKeepAliveRequests
Description: | Sets the amount of time the server will wait for subsequent
-requests on a persistent connection | Syntax: | KeepAliveTimeout seconds | Default: | KeepAliveTimeout 15 | Context: | server config | Status: | Core | Module: | core |
|
+See also
Description: | Sets the amount of time the server will wait for subsequent
+requests on a persistent connection | Syntax: | KeepAliveTimeout seconds | Default: | KeepAliveTimeout 15 | Context: | server config | Status: | Core | Module: | core |
|
The number of seconds Apache will wait for a subsequent
request before closing the connection. Once a request has been
received, the timeout value specified by the
- Timeout directive applies.
+ 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.
-
Description: | Restrict access controls to only certain HTTP
-methods | Syntax: | <Limit method [method] ... > ...
- </Limit> | Context: | server config, virtual host, directory, .htaccess | Status: | Core | Module: | core |
|
+
Description: | Restrict access controls to only certain HTTP
+methods | Syntax: | <Limit method [method] ... > ...
+ </Limit> | Context: | server config, virtual host, directory, .htaccess | Status: | Core | Module: | core |
|
Access controls are normally effective for
all access methods, and this is the usual
desired behavior. In the general case, access control
@@ -763,8 +790,8 @@ methods | Synta
and DELETE, leaving all other methods unprotected:
- <Limit POST PUT DELETE>
- Require valid-user
+ <Limit POST PUT DELETE>
+ Require valid-user
</Limit>
|
The method names listed can be one or more of: GET, POST, PUT,
@@ -772,27 +799,27 @@ methods | Synta
MKCOL, COPY, MOVE, LOCK, and UNLOCK. The method name is
case-sensitive. If GET is used it will also restrict
HEAD requests.
-
Description: | Restrict access controls to all HTTP methods
-except the named ones | Syntax: | <LimitExcept method [method] ... > ...
- </LimitExcept> | Context: | server config, virtual host, directory, .htaccess | Status: | Core | Module: | core |
|
+
Description: | Restrict access controls to all HTTP methods
+except the named ones | Syntax: | <LimitExcept method [method] ... > ...
+ </LimitExcept> | Context: | server config, virtual host, directory, .htaccess | Status: | Core | Module: | 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
+ 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.
+ documentation for <Limit> for more details.
For example:
- <LimitExcept POST GET>
- Require valid-user
+ <LimitExcept POST GET>
+ Require valid-user
<LimitExcept>
|
-
Description: | Restricts the total size of the HTTP request body sent
-from the client | Syntax: | LimitRequestBody bytes | Default: | LimitRequestBody 0 | Context: | server config, virtual host, directory, .htaccess | Status: | Core | Module: | core |
|
+
Description: | Restricts the total size of the HTTP request body sent
+from the client | Syntax: | LimitRequestBody bytes | Default: | LimitRequestBody 0 | Context: | server config, virtual host, directory, .htaccess | Status: | Core | Module: | core |
|
This directive specifies the number of bytes from 0
(meaning unlimited) to 2147483647 (2GB) that are allowed in a
request body. The default value is defined by the compile-time
@@ -825,39 +852,8 @@ from the client | LimitRequestFieldSize DirectiveDescription: | Limits the size of the HTTP request header allowed from the
-client | Syntax: | LimitRequestFieldsize bytes | Default: | LimitRequestFieldsize 8190 | Context: | server config | Status: | Core | Module: | core |
|
- This directive specifies the number of bytes from 0
- to the value of the compile-time constant
- DEFAULT_LIMIT_REQUEST_FIELDSIZE (8190 as
- distributed) that will be allowed in an HTTP request
- header.
-
- The LimitRequestFieldsize directive
- allows the server administrator to reduce the limit on the allowed
- size of an HTTP request header field below the normal input buffer
- size compiled with the server. A server needs this value to be
- large enough to hold any one header field from a normal client
- request. The size of a normal request header field will vary
- greatly among different client implementations, often depending
- upon the extent to which a user has configured their browser to
- support detailed content negotiation.
-
- 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 16380
- |
-
- Under normal conditions, the value should not be changed from
- the default. |
-
-
Description: | Limits the number of HTTP request header fields that
-will be accepted from the client | Syntax: | LimitRequestFields number | Default: | LimitRequestFields 100 | Context: | server config | Status: | Core | Module: | core |
|
+
Description: | Limits the number of HTTP request header fields that
+will be accepted from the client | Syntax: | LimitRequestFields number | Default: | LimitRequestFields 100 | Context: | server config | Status: | Core | Module: | 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
@@ -887,8 +883,39 @@ will be accepted from the client | LimitRequestLine DirectiveDescription: | Limit the size of the HTTP request line that will be accepted
-from the client | Syntax: | LimitRequestLine bytes | Default: | LimitRequestLine 8190 | Context: | server config | Status: | Core | Module: | core |
|
+
Description: | Limits the size of the HTTP request header allowed from the
+client | Syntax: | LimitRequestFieldsize bytes | Default: | LimitRequestFieldsize 8190 | Context: | server config | Status: | Core | Module: | core |
|
+ This directive specifies the number of bytes from 0
+ to the value of the compile-time constant
+ DEFAULT_LIMIT_REQUEST_FIELDSIZE (8190 as
+ distributed) that will be allowed in an HTTP request
+ header.
+
+ The LimitRequestFieldsize directive
+ allows the server administrator to reduce the limit on the allowed
+ size of an HTTP request header field below the normal input buffer
+ size compiled with the server. A server needs this value to be
+ large enough to hold any one header field from a normal client
+ request. The size of a normal request header field will vary
+ greatly among different client implementations, often depending
+ upon the extent to which a user has configured their browser to
+ support detailed content negotiation.
+
+ 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 16380
+ |
+
+ Under normal conditions, the value should not be changed from
+ the default. |
+
+
Description: | Limit the size of the HTTP request line that will be accepted
+from the client | Syntax: | LimitRequestLine bytes | Default: | LimitRequestLine 8190 | Context: | server config | Status: | Core | Module: | core |
|
This directive sets the number of bytes from 0 to
the value of the compile-time constant
DEFAULT_LIMIT_REQUEST_LINE (8190 as distributed)
@@ -917,7 +944,7 @@ from the client | Under normal conditions, the value should not be changed from
the default. |
-
+
Limit (in bytes) on maximum size of an XML-based request
body. A value of 0 will disable any checking.
@@ -927,16 +954,16 @@ from the client |