From: Joshua Slive Date: Tue, 19 Feb 2002 18:15:15 +0000 (+0000) Subject: XML version of core directives. X-Git-Tag: 2.0.33~195 X-Git-Url: https://granicus.if.org/sourcecode?a=commitdiff_plain;h=d139a6f2a248b468fe4b213c7e48f3e6ffaa687b;p=apache XML version of core directives. git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@93496 13f79535-47bb-0310-9956-ffa450edef68 --- diff --git a/docs/manual/mod/core.xml b/docs/manual/mod/core.xml new file mode 100644 index 0000000000..2eb6527b2d --- /dev/null +++ b/docs/manual/mod/core.xml @@ -0,0 +1,2480 @@ + + ]> + + + +core +Core +Core Apache HTTP Server features that are always +available + + +AcceptPathInfo +Controls whether requests can contain trailing pathname information +AcceptPathInfo On|Off|Default +AcceptPathInfo Default +server config +virtual hostdirectory +.htaccess +Available in Apache 2.0.30 and later + + + +

This directive controls whether requests that contain trailing + pathname information that follows an actual filename (or + non-existent file in an existing directory) will be accepted or + rejected. The trailing pathname information can be made + available to scripts in the PATH_INFO environment variable.

+ +

For example, assume the location /test/ points to + a directory that contains only the single file + here.html. Then requests for + /test/here.html/more and + /test/nothere.html/more both collect + /more as PATH_INFO.

+ +

The three possible arguments for the + AcceptPathInfo directive are:

+
+
off
A request will only be accepted if it + maps to a literal path that exists. Therefore a request with + trailing pathname information after the true filename such as + /test/here.html/more in the above example will return + a 404 NOT FOUND error.
+ +
on
A request will be accepted if a + leading path component maps to a file that exists. The above + example /test/here.html/more will be accepted if + /test/here.html maps to a valid file.
+ +
default
The treatment of requests with + trailing pathname information is determined by the handler responsible for the request. + The core handler for normal files defaults to rejecting PATH_INFO. + Handlers that serve scripts, such as cgi-script and isapi-isa, generally accept PATH_INFO by + default.
+
+ +

The primary purpose of the AcceptPathInfo + directive is to allow you to override the handler's choice of + accepting or rejecting 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> + + + + + +AccessFileName +Sets the name of the .htaccess file +AccessFileName filename [filename] ... +AccessFileName .htaccess +server configvirtual host + + + +

When returning a document to the client the server looks for + the first existing access control file from this list of names + in every directory of the path to the document, if access + control 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> + + +AllowOverride +Configuration Files + + + +AddDefaultCharset +Specifies the default character set to be added for a +response without an explicit character set +AddDefaultCharset On|Off|charset +server config +virtual hostdirectory +.htaccess +AddDefaultCharset Off + + + +

This directive specifies the name of the character set that + will be added to any response that does not have any parameter on + the content type in the HTTP headers. This will override any + character set specified in the body of the document via a + META tag. A setting of AddDefaultCharset + Off disables this + functionality. AddDefaultCharset On enables + Apache's internal default charset of iso-8859-1 as + required by the directive. You can also specify an alternate + charset to be used. For example:

+ + + AddDefaultCharset utf-8 + + + + + +AddModule +AddModule module [module] ... +server config + + +

The server can have modules compiled in which are not + actively in use. This directive can be used to enable the use + of those modules. The server comes with a pre-loaded list of + active modules; this list can be cleared with the ClearModuleList directive.

+ +

For example:

+ +AddDefaultCharset utf-8 + + + + + +AllowOverride +Sets the types of directives that are allowed in +.htaccess files +AllowOverride All|None|directive-type [directive-type] ... +AllowOverride All +directory + + +

When the server finds an .htaccess file (as specified by AccessFileName) it needs to know + which directives declared in that file can override earlier + access information.

+ +

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.

+ +
+
AuthConfig
+ +
+ + Allow use of the authorization directives (AuthDBMGroupFile, + AuthDBMUserFile, + AuthGroupFile, + AuthName, + AuthType, AuthUserFile, Require, etc.).
+ +
FileInfo
+ +
+ Allow use of the directives controlling document types (DefaultType, ErrorDocument, ForceType, LanguagePriority, + SetHandler, SetInputFilter, SetOutputFilter, and + mod_mime Add* and Remove* + directives, etc.).
+ +
Indexes
+ +
+ Allow use of the directives controlling directory indexing + (AddDescription, + AddIcon, AddIconByEncoding, + AddIconByType, + DefaultIcon, DirectoryIndex, FancyIndexing, HeaderName, IndexIgnore, IndexOptions, ReadmeName, + etc.).
+ +
Limit
+ +
+ Allow use of the directives controlling host access (Allow, Deny and Order).
+ +
Options
+ +
+ Allow use of the directives controlling specific directory + features (Options and + XBitHack).
+
+ +

Example:

+ + AllowOverride AuthConfig Indexes + + +AccessFileName +Configuration Files + + + +AuthName +Sets the authorization realm for use in HTTP +authentication +AuthName auth-domain +directory.htaccess + +AuthConfig + + +

This directive sets the name of the authorization realm for a + directory. This realm is given to the client so that the user + knows which username and password to send. + AuthName takes a single argument; if the + realm name contains spaces, it must be enclosed in quotation + marks. It must be accompanied by AuthType and Require directives, and directives such + as AuthUserFile and + AuthGroupFile to + work.

+ +

For example:

+ + AuthName "Top Secret" + +

The string provided for the AuthRealm is what will + appear in the password dialog provided by most browsers.

+ +Authentication, Authorization, and + Access Control + + + +AuthType +Selects the type of user authentication +AuthType Basic|Digest +directory.htaccess +AuthConfig + + +

This directive selects the type of user authentication for a + directory. Only Basic and Digest are + currently implemented. + + It must be accompanied by AuthName and Require directives, and directives such + as AuthUserFile and + AuthGroupFile to + work.

+ +Authentication, Authorization, +and Access Control + + + +ContentDigest +Enables the generation of Content-MD5 HTTP Response +headers +ContentDigest on|off +ContentDigest off +server configvirtual host +directory.htaccess + +Options +Experimental +Available in Apache 1.1 and later + + +

This directive enables the generation of + Content-MD5 headers as defined in RFC1864 + respectively RFC2068.

+ +

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.

+ + + + +DefaultType +Sets the MIME content-type that will be sent if the +server cannot determine a type in any other way +DefaultType MIME-type +DefaultType text/html +server configvirtual host +directory.htaccess + +FileInfo + + +

There will be times when the server is asked to provide a + document whose type cannot be determined by its MIME types + mappings.

+ +

The server must inform the client of the content-type of the + document, so in the event of an unknown type it uses the + DefaultType. For example:

+ + + DefaultType image/gif + + would be appropriate for a directory which contained many gif + images with filenames missing the .gif extension. + +

Note that unlike ForceType, this directive is only + provides the default mime-type. All other mime-type definitions, + including filename extensions, that might identify the media type + will override this default.

+ + + + +Directory +Enclose a group of directives that apply only to the +named file-system directory and sub-directories +<Directory directory-path> +... </Directory> +server configvirtual host + + + +

Directory and + </Directory> are used to enclose a group of + directives which will apply only to the named directory and + sub-directories of that directory. Any directive which is allowed + in a directory context may be used. Directory-path is + either the full path to a directory, or a wild-card string. In a + wild-card string, `?' matches any single character, and `*' + matches any sequences of characters. You may + also use `[]' character ranges like in the shell. Also as of + Apache 1.3 none of the wildcards match a `/' character, which more + closely mimics the behavior of Unix shells. Example:

+ + <Directory /usr/local/httpd/htdocs>
+  Options Indexes FollowSymLinks
+ </Directory>
+ + +

Extended 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 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:

+ +
    +
  • Apply directive AllowOverride None + (disabling .htaccess files).
    • + +
  • Apply directive AllowOverride FileInfo (for + directory /home/web).
    • + +
  • Apply any FileInfo directives in + /home/web/.htaccess
    • +
+ +

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 be applied.

+ +

Note that the default Apache access for + <Directory /> is Allow from All. This means + that Apache 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 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.

+ +How + Directory, Location and Files sections work for an + explanation of how these different sections are combined when a + request is received + + + +DirectoryMatch +Enclose a group of directives that apply only to +file-system directories that match a regular expression and their +subdirectories +<Directory regex> +... </Directory> +server configvirtual host + + + +

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 + 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 for +a description of how regular expressions are mixed in with normal +<Directory>s +How Directory, Location and Files sections +work for an explanation of how these different sections are +combined when a request is received + + + +DocumentRoot +Sets the directory that forms the main document tree visible +from the web +DocumentRoot directory-path +DocumentRoot /usr/local/apache/htdocs +server configvirtual host + + + +

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.

+ +

The DocumentRoot should be specified without + a trailing slash.

+ +Mapping URLs to Filesystem +Location + + + +ErrorDocument +Specifies what the server will return to the client +in case of an error +ErrorDocument error-code document +server configvirtual host +directory.htaccess + +FileInfo +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,

+ +
    +
  1. output a simple hardcoded error message
    2. + +
  2. output a customized message
    3. + +
  3. redirect to a local URL-path to handle the + problem/error
    4. + +
  4. redirect to an external URL to handle the + problem/error
    5. +
+ +

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 will sometimes offer additional information + regarding the problem/error.

+ +

URLs can begin with a slash (/) for local URLs, 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" + + +

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 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.

+ +

Prior to version 2.0, messages were indicated by prefixing + them with a single unmatched double quote character.

+ + +documentation of + customizable responses + + + +ErrorLog +Sets the name of the file to which the server +will log errors + ErrorLog file-path|syslog[:facility] +ErrorLog logs/error_log (Unix) +ErrorLog logs/error.log (Windows and OS/2) +server configvirtual host + + + +

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 + begins with a pipe (|) then it is assumed to be a command to spawn + to handle the error log.

+ +

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).

+ +

SECURITY: See the security tips + document for details on why your security could be compromised + if the directory where logfiles are stored is writable by + anyone other than the user that starts the server.

+ +LogLevel +Apache Log Files + + + +FileETag +Configures the file attributes used to create the ETag +HTTP response header +FileETag component ... +server configvirtual host +directory.htaccess + +FileInfo + + +

+ 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 file. (The ETag + value is used in cache management to save network bandwidth.) In + Apache 1.3.22 and earlier, the ETag value was always formed + from the file's inode, size, and last-modified time (mtime). The + FileETag directive allows you to choose which of these -- if any + -- should be used. The recognized keywords are: +

+
+
INode
+
The file's i-node number will be included in the calculation
+
MTime
+
The date and time the file was last modified will be included
+
Size
+
The number of bytes in the file will be included
+
All
+
All available fields will be used (equivalent to + 'FileETag INode MTime Size')
+
None
+
If a document is file-based, no ETag field will be included in the + response
+
+

+ The 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'. +

+ + + + +Files +Contains that directives that apply to matched +filenames +<Files filename> ... </Files> +server configvirtual host +directory.htaccess + + + +

The Files directive + provides for access control by filename. It is comparable to the + 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 + 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. Extended 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. In Apache 1.3 + and later, 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.

+ + +How + Directory, Location and Files sections work for an + explanation of how these different sections are combined when a + request is received + + + +FilesMatch +Contains that directives that apply to regular-expression matched +filenames +<FilesMatch regex> ... </FilesMatch> +server configvirtual host +directory.htaccess + + + +

The FilesMatch 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)$"> + + +

would match most common Internet graphics formats.

+ + +How + Directory, Location and Files sections work for an + explanation of how these different sections are combined when a + request is received + + + +ForceType +Forces all matching files to be served with the specified +MIME content-type +ForceType mime-type +directory.htaccess + +Moved to the core in Apache 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 + mime-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 unlike DefaultType, + this directive overrides all mime-type associations, including + filename extensions, that might identify the media type.

+ + + + +HostnameLookups +Enables DNS lookups on client IP addresses +HostnameLookups on|off|double +HostnameLookups off +server configvirtual host +directory + + +

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. 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_access 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, provided in + the /support directory, can be used to look up host + names from logged IP addresses offline.

+ + + + +IdentityCheck +Enables logging of the RFC1413 identity of the remote +user +IdentityCheck on|off +IdentityCheck off + + +

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 + the access log.

+ +

The information should not be trusted in any way except for + rudimentary usage tracking.

+ +

Note that this can cause serious latency problems accessing + your server since every request requires one of these lookups + to be performed. When firewalls are involved each lookup might + 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.

+ + + + +IfDefine +Encloses directives that will be processed only +if a test is true at startup +<IfDefine [!]parameter-name> ... + </IfDefine> +server configvirtual host +directory.htaccess + + + +

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-name
    • + +
  • !parameter-name
    • +
+ +

In 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.

+ +

IfDefine sections are + nest-able, which can be used to implement simple + multiple-parameter tests. Example:

+
+  $ httpd -DReverseProxy ...
+
+  # httpd.conf
+  <IfDefine ReverseProxy>
+  LoadModule rewrite_module modules/mod_rewrite.so
+  LoadModule proxy_module   modules/libproxy.so
+  </IfDefine>
+
 + + + + + +IfModule +Encloses directives that are processed conditional on the +presence of absence of a specific module +<IfModule [!]module-name> ... + </IfModule> +server configvirtual host +directory.htaccess + + + +

The <IfModule + test>...</IfModule> section is used to + mark directives that are conditional. 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:

+ +
    +
  • module name
    • + +
  • !module name
    • +
+ +

In the former case, the directives between the start and end + markers are only processed if the module named module + name is included in Apache -- either compiled in or + dynamically loaded using LoadModule. The second format + reverses the test, and only processes the directives if module + name is not included.

+ +

The module name argument is the file name of the + module, at the time it was compiled. + For example, mod_rewrite.c.

+ +

IfModule sections are + nest-able, which can be used to implement simple multiple-module + tests.

+ + + + +Include +Includes other configuration files from within +the server configuration files +Include file-path|directory-path +server config + + +

This directive allows inclusion of other configuration files + from within the server configuration files.

+ +

If Include points to a directory, rather than a + file, Apache will read all files in that directory, and any + subdirectory, and parse those as configuration files.

+ +

The file path specified may be a fully qualified path (i.e. + starting with a slash), or may be relative to the + ServerRoot directory.

+ +

Examples:

+ + + Include /usr/local/apache/conf/ssl.conf
+ Include /usr/local/apache/conf/vhosts/ + + +

Or, providing paths relative to your ServerRoot + directory:

+ + + Include conf/ssl.conf
+ Include conf/vhosts/ + + +

Make sure that an included directory does not contain any stray + files, such as editor temporary files, for example, as Apache will + attempt to read them in and use the contents as configuration + directives, which may cause the server to fail on start up. + Running apachectl configtest will give you a list of + the files that are being processed during the configuration + check:

+ +
+ root@host# apachectl configtest
+  Processing config directory: /usr/local/apache/conf/vhosts
+  Processing config file: /usr/local/apache/conf/vhosts/vhost1
+  Processing config file: /usr/local/apache/conf/vhosts/vhost2
+ Syntax OK
+
 + +

This will help in verifying that you are getting only the files + that you intended as part of your configuration.

+ + +apachectl + + + +KeepAlive +Turns on or off HTTP persistent connections. +KeepAlive on|off +KeepAlive On +server config + + +

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 in Apache 1.2 and + later, 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.

+ + +MaxKeepAliveRequests + + + +KeepAliveTimeout +Sets the amount of time the server will wait for subsequent +requests on a persistent connection +KeepAliveTimeout seconds +KeepAliveTimeout 15 +server config + + +

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.

+ +

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.

+ + + + +Limit +Restrict access controls to only certain HTTP +methods +<Limit method [method] ... > ... + </Limit> +server configvirtual host +directory.htaccess + + + +

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, TRACE, 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.

+ + + + +LimitExcept +Restrict access controls to all HTTP methods +except the named ones +<LimitExcept method [method] ... > ... + </LimitExcept> +server configvirtual host +directory.htaccess + + + +

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.

+ + + + +LimitRequestBody +Restricts the total size of the HTTP request body sent +from the client +LimitRequestBody bytes +LimitRequestBody 0 +server configvirtual host +directory.htaccess + + + +

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 + constant DEFAULT_LIMIT_REQUEST_BODY (0 as + distributed).

+ +

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 passing form information to the + server. 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.

+ + + + +LimitRequestFields +Limits the number of HTTP request header fields that +will be accepted from the client +LimitRequestFields number +LimitRequestFields 100 +server config + + +

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.

+ + + + +LimitRequestFieldSize +Limits the size of the HTTP request header allowed from the +client +LimitRequestFieldsize bytes +LimitRequestFieldsize 8190 +server config + + +

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. + Under normal conditions, the value should not be changed from + the default.

+ + + + +LimitRequestLine +Limit the size of the HTTP request line that will be accepted +from the client +LimitRequestLine bytes +LimitRequestLine 8190 +server config + + +

This directive sets the number of bytes from 0 to + the value of the compile-time constant + DEFAULT_LIMIT_REQUEST_LINE (8190 as distributed) + that will be allowed on the HTTP request-line.

+ +

The LimitRequestLine directive allows + the server administrator to reduce the limit on the allowed size + of a client's HTTP request-line below the normal input buffer size + compiled with the server. 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. + Under normal conditions, the value should not be changed from + the default.

+ + + + +LimitXMLRequestBody +Limits the size of an XML-based request body +LimitXMLRequestBody number +LimitXMLRequestBody 1000000 +server config + + +

Limit (in bytes) on maximum size of an XML-based request + body. A value of 0 will disable any checking.

+ + + + +Location +Applies the enclosed directives only to matching +URLs +<Location + URL-path|URL> ... </Location> +server configvirtual host + + + +

The Location directive + provides for access control 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.

+ +

Note that URLs do not have to line up with the filesystem at + all, it should be emphasized that <Location> operates + completely outside the filesystem.

+ +

For all origin (non-proxy) requests, the URL to be matched + is of the form /path/, and you should not include + any http://servername prefix. 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.

+ +

Extended 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". In Apache 1.3 and above, a new directive + LocationMatch + exists which behaves identical to the regex version of + Location.

+ +

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 foo.com, you might use:

+ + <Location /status>
+ SetHandler server-status
+ Order Deny,Allow
+ Deny from all
+ Allow from .foo.com
+ </Location> + + +Note about / (slash)

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.

+ + +How + Directory, Location and Files sections work for an + explanation of how these different sections are combined when a + request is received + + + +LocationMatch +Applies the enclosed directives only to regular-expression +matching URLs +<LocationMatch + regex> ... </Location> +server configvirtual host + + + +

The LocationMatch directive + provides for access control 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".

+ + +How + Directory, Location and Files sections work for an + explanation of how these different sections are combined when a + request is received + + + +LogLevel +Controls the verbosity of the ErrorLog +LogLevel level +LogLevel warn +server configvirtual host + + + +

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 ..."
+ +

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.

+ + + + +MaxKeepAliveRequests +Sets the number of requests allowed on a persistent +connection +MaxKeepAliveRequests number +MaxKeepAliveRequests 100 +server config + + +

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.

+ + + + +NameVirtualHost +Configures an IP address for name-virtual +hosting +NameVirtualHost addr[:port] +server config + + +

The NameVirtualHost directive is a + required directive if you want to configure name-based virtual hosts.

+ +

Although addr can be hostname it is recommended + that you always use an IP address, e.g.

+ +NameVirtualHost 111.22.33.44 + +

With the NameVirtualHost directive you + specify the IP address on which the server will receive requests + for the name-based virtual hosts. This will usually be the address + to which your name-based virtual host names resolve. 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. If you have multiple name-based hosts on + multiple addresses, repeat the directive for each address.

+ +

Note: the "main server" and any _default_ servers will + never be served for a request to a + NameVirtualHost IP Address (unless for some + reason you specify NameVirtualHost but then + don't define any VirtualHosts for that address).

+ +

Optionally you can specify a port number on which the + name-based virtual hosts should be used, e.g.

+ +NameVirtualHost 111.22.33.44:8080 + +

IPv6 addresses must be enclosed in square brackets, as shown + in the following example:

+ +NameVirtualHost [fe80::a00:20ff:fea7:ccea]:8080 + + + + + +Options +Configures what features are available in a particular +directory +Options + [+|-]option [[+|-]option] ... +Options All +server configvirtual host +directory.htaccess + +Options + + +

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:

+ +
+
All
+ +
All options except for MultiViews. This is the default + setting.
+ +
ExecCGI
+ +
+ Execution of CGI scripts is permitted.
+ +
FollowSymLinks
+ +
+ + The server will follow symbolic links in this directory.
+ Note: even though the server follows the + symlink it does not change the pathname used to match + against Directory sections.
+ Note: this option gets ignored if set inside a + Location + section.
+ +
Includes
+ +
+ Server-side includes are permitted.
+ +
IncludesNOEXEC
+ +
+ + Server-side includes are permitted, but the #exec command and + #exec CGI are disabled. It is still possible to #include + virtual CGI scripts from ScriptAliase'd directories.
+ +
Indexes
+ +
+ If a URL which maps to a directory is requested, and the + there is no DirectoryIndex (e.g., index.html) in + that directory, then the server will return a formatted + listing of the directory.
+ +
MultiViews
+ +
+ Content negotiated + MultiViews are allowed.
+ +
SymLinksIfOwnerMatch
+ +
+ + The server will only follow symbolic links for which the target + file or directory is owned by the same user id as the link.
Note: this option gets ignored if set inside + a Location + section.
+
+

Normally, if multiple Options could apply to a + directory, then the most specific one is taken complete; the + options are not 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.

+ +

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.

+ + +

Note: 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.

+ + + + +Require +Selects which authenticated users can access +a resource +Require entity-name [entity-name] ... +directory.htaccess + +AuthConfig + + +

This directive selects which authenticated users can access + a directory. The allowed syntaxes are:

+ +
    +
  • + Require user userid [userid] ... + +

    Only the named users can access the directory.

    +
    • + +
  • + Require group group-name [group-name] ... + + +

    Only users in the named groups can access the + directory.

    +
    • + +
  • + Require valid-user + +

    All valid users can access the directory.

    +
    • +
+ +

Require must be accompanied by + AuthName and AuthType directives, and directives such + as AuthUserFile + and AuthGroupFile (to + define users and groups) in order to work correctly. Example:

+ + + AuthType Basic
+ AuthName "Restricted Directory"
+ AuthUserFile /web/users
+ AuthGroupFile /web/groups
+ Require group admin
+ + +

Access controls which are applied in this way are effective for + all methods. This is what is normally + desired. If you wish to apply access controls only to + specific methods, while leaving other methods unprotected, then + place the Require statement into a + Limit + section.

+ +Satisfy +mod_access + + + +RLimitCPU +Limits the CPU consumption of processes launched +by Apache children +RLimitCPU number|max [number|max] +Unset; uses operating system defaults +>server configvirtual host + +Moved in version 2.0 to + the MPMs + + +

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 children + servicing requests, not the Apache children themselves. This + includes CGI scripts and SSI exec commands, but not any + processes forked off from the Apache parent such as piped + logs.

+ +

CPU resource limits are expressed in seconds per + process.

+ +RLimitMEM +RLimitNPROC + + + +RLimitMEM +Limits the memory consumption of processes launched +by Apache children +RLimitMEM number|max [number|max] +Unset; uses operating system defaults +server configvirtual host + +Moved in version 2.0 to the MPMs. + + +

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 children + servicing requests, not the Apache children themselves. This + includes CGI scripts and SSI exec commands, but not any + processes forked off from the Apache parent such as piped + logs.

+ +

Memory resource limits are expressed in bytes per + process.

+ +RLimitCPU +RLimitNPROC + + + +RLimitNPROC +Limits the number of processes that can be launched by +processes launched by Apache children +RLimitNPROC number|max [number|max] +Unset; uses operating system defaults +server configvirtual host + +Moved in version 2.0 to the MPMs. + + +

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 children + servicing requests, not the Apache children themselves. This + includes CGI scripts and SSI exec commands, but not any + processes forked off from the Apache parent such as piped + logs.

+ +

Process limits control the number of processes per user.

+ +

Note: If CGI processes are not running + under userids other than the web server userid, 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.

+ +RLimitMEM +RLimitCPU + + + +Satisfy +Configures how host-level access control and user authentication +interact +Satisfy any|all +Satisfy all +directory.htaccess + + + +

Access policy if both Allow and Require used. The parameter can be + either 'all' or 'any'. This directive is only + useful if access to a particular area is being restricted by both + username/password and client host address. In this case + the default behavior ("all") is to require that the client passes + the address access restriction and enters a valid + username and password. With the "any" option the client will be + granted access if they either pass the host restriction or enter a + valid username and password. This can be used to password restrict + an area, but to let clients from particular addresses in without + prompting for a password.

+ + + + +ScriptInterpreterSource +Controls how the interpreter for CGI scripts is +located +ScriptInterpreterSource registry|script +ScriptInterpreterSource script +directory.htaccess + +Win32 only + + +

This directive is used to control how Apache finds the + interpreter used to run CGI scripts. The default technique is to + use the interpreter pointed to by the #! line in the + script. Setting ScriptInterpreterSource registry will + cause the Windows Registry to be searched using the script file + extension (e.g., .pl) as a search key.

+ + + + +ServerAdmin +Sets the email address that the server includes in error +messages sent to the client +ServerAdmin email-address +server configvirtual host + + + +

The ServerAdmin sets the e-mail address + that the server includes in any error messages it returns to the + client.

+ +

It may be worth setting up a dedicated address for this, + e.g.

+ServerAdmin www-admin@foo.bar.com +

as users do not always mention that they are talking about the + server!

+ + + + +ServerAlias +Sets alternate names for a host used when matching requests +to name-virtual hosts +ServerAlias hostname [hostname] ... +virtual host + + +

The ServerAlias directive sets the + alternate names for a host, for use with name-based virtual hosts.

+ + + <VirtualHost *>
+ ServerName server.domain.com
+ ServerAlias server server2.domain.com server2
+ ...
+ </VirtualHost> + + +Apache Virtual Host documentation + + + +ServerName +Sets the hostname and port that the server uses to identify +itself +ServerName fully-qualified-domain-name[:port] +server configvirtual host + +In version 2.0, this + directive supersedes the functionality of the Port + directive from version 1.3. + + +

The ServerName directive sets the hostname and + port that the server uses to identify itself. This is used when + creating redirection URLs. For example, if the name of the + machine hosting the webserver is simple.example.com, + but the machine also has the DNS alias www.example.com + and you wish the webserver to be so identified, the following + directive should be used:

+ +ServerName www.example.com:80 + +

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.

+ +

See the description of the + UseCanonicalName directive for + settings which determine whether self-referential URL's (e.g., by the + mod_dir module) will refer to the + specified port, or to the port number given in the client's request. +

+ + +DNS Issues +Apache virtual host + documentation +UseCanonicalName +NameVirtualHost +ServerAlias + + + +ServerPath +Sets the legacy URL pathname for a name-virtual host that +is accessed by an incompatible browser +ServerPath directory-path +virtual host + + +

The ServerPath directive sets the legacy + URL pathname for a host, for use with name-based virtual hosts.

+ +Apache Virtual Host documentation + + + +ServerRoot +Sets the base directory for the server installation +ServerRoot directory-path +ServerRoot /usr/local/apache +server config + + +

The ServerRoot directive sets the + directory in which the server lives. Typically it will contain the + subdirectories conf/ and logs/. Relative + paths for other configuration files are taken as relative to this + directory.

+ +the -d + option to httpd +the + security tips for information on how to properly set + permissions on the ServerRoot + + + +ServerSignature +Configures the footer on server-generated documents +ServerSignature On|Off|EMail +ServerSignature Off +server configvirtual host +directory.htaccess + + + +

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 error 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.

+ + + + +ServerTokens +Configures the Server HTTP response header +ServerTokens Minimal|ProductOnly|OS|Full +ServerTokens Full +server config + + +

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 Prod[uctOnly]
+ +
Server sends (e.g.): Server: + Apache
+ +
ServerTokens Min[imal]
+ +
Server sends (e.g.): Server: + Apache/1.3.0
+ +
ServerTokens OS
+ +
Server sends (e.g.): Server: Apache/1.3.0 + (Unix)
+ +
ServerTokens Full (or not specified)
+ +
Server sends (e.g.): Server: Apache/1.3.0 + (Unix) PHP/3.0 MyMod/1.2
+
+ +

This setting applies to the entire server, and cannot be + enabled or disabled on a virtualhost-by-virtualhost basis.

+ + + + +SetHandler +Forces all matching files to be processed by a +handler +SetHandler handler-name +server configvirtual host +directory.htaccess + +Moved into the core in Apache 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> + + + + + +SetInputFilter +Sets the filters that will process client requests and POST +input +SetInputFilter filter[;filter...] +server configvirtual host +directory.htaccess + + + +

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.

+ +Filters documentation + + + +SetOutputFilter +Sets the filters that will process responses from the +server +SetOutputFilter filter [filter] ... +server configvirtual host +directory.htaccess + + + +

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.

+ +Filters documentation + + + +TimeOut +Defines the amount of time the server will wait for +certain events before failing a request +TimeOut number +TimeOut 300 +server config + + +

The TimeOut directive currently defines + the amount of time Apache will wait for three things:

+ +
    +
  1. The total amount of time it takes to receive a GET + request.
    2. + +
  2. The amount of time between receipt of TCP packets on a + POST or PUT request.
    3. + +
  3. The amount of time between ACKs on transmissions of TCP + packets in responses.
    4. +
+ +

We plan on making these separately configurable at some point + down the road. The timer used to default to 1200 before 1.2, + but has been lowered to 300 which is still far more than + necessary in most situations. It is not set any lower by + default because there may still be odd places in the code where + the timer is not reset when a packet is sent.

+ + + + +UseCanonicalName +Configures how the server determines its own name and +port +UseCanonicalName on|off|dns +UseCanonicalName on +server configvirtual host +directory.htaccess +Options + + +

In many situations Apache has to construct a + self-referential URL. That is, a URL which refers back to + the same server. With UseCanonicalName on Apache will + use the hostname and port specified in the ServerName directive to construct a 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 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). 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 will redirect them to + http://www.domain.com/splat/. If you have + authentication enabled, this will cause the user to have to + reauthenticate twice (once for www and once again + for www.domain.com). But if + UseCanonicalName is set off, then Apache 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 does a + reverse DNS lookup on the server IP address that the client + connected to in order to work out self-referential URLs.

+ +

Warning: 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.

+ +ServerName +Listen + + + +VirtualHost +Contains directives that apply only to a specific +hostname or IP address +<VirtualHost + addr[:port] [addr[:port]] + ...> ... </VirtualHost> +server config + + +

VirtualHost and + </VirtualHost> are used to enclose a group of + directives which will apply only to a particular virtual host. Any + directive which 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

+ +
    +
  • The IP address of the virtual host
    • + +
  • A fully qualified domain name for the IP address of the + virtual host.
    • +
+ Example: + +<VirtualHost 10.1.2.3>
+ ServerAdmin webmaster@host.foo.com
+ DocumentRoot /www/docs/host.foo.com
+ ServerName host.foo.com
+ ErrorLog logs/host.foo.com-error_log
+ TransferLog logs/host.foo.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 [fe80::a00:20ff:fea7:ccea]>
+ ServerAdmin webmaster@host.foo.com
+ DocumentRoot /www/docs/host.foo.com
+ ServerName host.foo.com
+ ErrorLog logs/host.foo.com-error_log
+ TransferLog logs/host.foo.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), or with kernel patches like VIF (for SunOS(TM) 4.1.x)).

+ +

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 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_.)

+ +

SECURITY: See the security tips document + for details on why your security could be compromised if the + directory where logfiles are stored is writable by anyone other + than the user that starts the server.

+ +

NOTE: The use of VirtualHost does not + affect what addresses Apache listens on. You may need to ensure + that Apache is listening on the correct addresses using Listen.

+ +Apache Virtual Host documentation +Warnings about DNS and + Apache +Setting + which addresses and ports Apache uses +How + Directory, Location and Files sections work for an + explanation of how these different sections are combined when a + request is received + + + \ No newline at end of file