From: Rich Bowen Date: Thu, 6 Sep 2001 03:48:59 +0000 (+0000) Subject: W3C tidy. Lowecased HTML tags. Various other indentation and X-Git-Tag: 2.0.26~317 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=4e1be58da35efb90d017226ddb2ad5cf02121096;p=thirdparty%2Fapache%2Fhttpd.git W3C tidy. Lowecased HTML tags. Various other indentation and prettification of the HTML. git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@90908 13f79535-47bb-0310-9956-ffa450edef68 --- diff --git a/docs/manual/mod/core.html b/docs/manual/mod/core.html index e0c240df39c..cb851c764c8 100644 --- a/docs/manual/mod/core.html +++ b/docs/manual/mod/core.html @@ -1,1058 +1,1021 @@ - - - -Apache Core Features - - - - - - -

Apache Core Features

-

-These configuration parameters control the core Apache features, and are -always available. -

-

Directives

- -
- -

AccessFileName directive

- -Syntax: AccessFileName filename -[filename] ...
-Default: AccessFileName .htaccess
-Context: server config, virtual host
-Status: core
-Compatibility: AccessFileName can accept more than -one filename only in Apache 1.3 and later

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

- -

See Also: -AllowOverride

-
- -

AddDefaultCharset directive

-Syntax: -AddDefaultCharset On|Off|charset
-Context: -all
-Status: -core
-Default: -AddDefaultCharset Off
-Compatibility: - AddDefaultCharset is only available in Apache 1.3.12 and -later

-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; -e.g. AddDefaultCharset utf-8. -

- -

AddModule directive

- -Syntax: AddModule module [module] ...
-Context: server config
-Status: core
-Compatibility: AddModule is only available in -Apache 1.2 and later

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

- -

AllowOverride directive

- -Syntax: AllowOverride All|None|directive-type -[directive-type] ...
-Default: AllowOverride All
-Context: directory
-Status: 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 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). -

- -

See Also: -AccessFileName

-
- -

AuthName directive

- -Syntax: AuthName auth-domain
-Context: directory, .htaccess
-Override: AuthConfig
-Status: core

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

- -

AuthType directive

- -Syntax: AuthType Basic|Digest
-Context: directory, .htaccess
-Override: AuthConfig
-Status: core

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

- -

ClearModuleList directive

- -Syntax: ClearModuleList
-Context: server config
-Status: core
-Compatibility: ClearModuleList is only available in -Apache 1.2 and later

- -The server comes with a built-in list of active modules. This -directive clears the list. It is assumed that the list will then be -re-populated using the AddModule directive.

- -

ContentDigest directive

- -Syntax: ContentDigest on|off
-Default: ContentDigest off
-Context: server config, virtual host, directory, -.htaccess
-Override: Options
-Status: experimental
-Compatibility: ContentDigest is only 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 directive

- -Syntax: DefaultType MIME-type
-Default: DefaultType text/html
-Context: server config, virtual host, directory, -.htaccess
-Override: FileInfo
-Status: core

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

- -Syntax: <Directory directory-path> - ... </Directory>
-Context: server config, virtual host
-Status: Core.

- -<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. As of Apache 1.3, 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 -behaviour of Unix shells. Example: 

+
+  
+   Apache Core Features
+  
+  
+
+  
+    
+
+    
Apache Core Features

+
+    
These configuration parameters control the core Apache
+    features, and are always available.

+
+    
Directives

+
+    
+    

+
+    
AccessFileName directive

+    
+    Syntax: AccessFileName
+    filename [filename] ...

+     Default: AccessFileName
+    .htaccess

+     Context: server config, virtual
+    host

+     Status: core

+     Compatibility: AccessFileName can
+    accept more than one filename only in Apache 1.3 and later 
+
+    
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>
+    

+
+    
See Also: AllowOverride

+    

+
+    
AddDefaultCharset
+    directive

+    Syntax: AddDefaultCharset
+    On|Off|charset

+     Context: all

+     Status: core

+     Default: AddDefaultCharset
+    Off

+     Compatibility: AddDefaultCharset is
+    only available in Apache 1.3.12 and later 
+
+    
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; e.g.
+    AddDefaultCharset utf-8.

+    

+
+    
AddModule directive

+    
+    Syntax: AddModule module
+    [module] ...

+     Context: server config 

+     Status: core

+     Compatibility: AddModule is only
+    available in Apache 1.2 and later 
+
+    
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.

+    

+
+    
AllowOverride directive

+    
+    Syntax: AllowOverride
+    All|None|directive-type [directive-type]
+    ...

+     Default: AllowOverride
+    All

+     Context: directory

+     Status: 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
+    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).

+    

+
+    
See Also: AccessFileName

+    

+
+    
AuthName directive

+    
+    Syntax: AuthName
+    auth-domain

+     Context: directory, .htaccess

+     Override: AuthConfig

+     Status: core 
+
+    
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.

+    

+
+    
AuthType directive

+    
+    Syntax: AuthType Basic|Digest

+     Context: directory, .htaccess

+     Override: AuthConfig

+     Status: core 
+
+    
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.

+    

+
+    
ClearModuleList
+    directive

+    
+    Syntax: ClearModuleList

+     Context: server config

+     Status: core

+     Compatibility: ClearModuleList is
+    only available in Apache 1.2 and later 
+
+    
The server comes with a built-in list of active modules.
+    This directive clears the list. It is assumed that the list
+    will then be re-populated using the AddModule directive.

+    

+
+    
ContentDigest directive

+    
+    Syntax: ContentDigest on|off

+     Default: ContentDigest
+    off

+     Context: server config, virtual
+    host, directory, .htaccess

+     Override: Options

+     Status: experimental

+     Compatibility: ContentDigest is
+    only 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 directive

+    
+    Syntax: DefaultType
+    MIME-type

+     Default: DefaultType
+    text/html

+     Context: server config, virtual
+    host, directory, .htaccess

+     Override: FileInfo

+     Status: core 
+
+    
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> directive

+    
+    Syntax: <Directory
+    directory-path> ... </Directory> 

+     Context: server config, virtual
+    host

+     Status: Core. 
+
+    
<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.
+    As of Apache 1.3, 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>
-

-
-
Apache 1.2 and above:
-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 expression directory sections are handled slightly differently
-by Apache 1.2 and 1.3.  In Apache 1.2 they are interspersed with the normal
-directory sections and applied in the order they appear in the configuration
-file.  They are applied only once, and apply when the shortest match
-possible occurs.  In Apache 1.3 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>
    
-
    
-Suppose that the filename being accessed is
-/home/abc/public_html/abc/index.html.  The server
-considers each of /, /home, /home/abc,
-/home/abc/public_html, and /home/abc/public_html/abc
-in that order.   In Apache 1.2, when
-/home/abc is considered, the regular expression will match
-and be applied.  In Apache 1.3 the regular expression isn't considered
-at all at that point in the tree.  It 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
-
-
    +
    
+
+    
    Apache 1.2 and above: 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: 
+
+    
+
+    
    Regular expression directory sections are handled slightly
+    differently by Apache 1.2 and 1.3. In Apache 1.2 they are
+    interspersed with the normal directory sections and applied in
+    the order they appear in the configuration file. They are
+    applied only once, and apply when the shortest match possible
+    occurs. In Apache 1.3 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>
    
+          
+    
    
+    Suppose that the filename being accessed is
+    /home/abc/public_html/abc/index.html. The server
+    considers each of /, /home,
+    /home/abc, /home/abc/public_html, and
+    /home/abc/public_html/abc in that order. In Apache
+    1.2, when /home/abc is considered, the regular
+    expression will match and be applied. In Apache 1.3 the regular
+    expression isn't considered at all at that point in the tree.
+    It 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.
-
    
-
-See also: How Directory,
-Location and Files sections work for an explanation of how these
-different sections are combined when a request is received
-
-
    
-
-
    <DirectoryMatch>
    
-Syntax: <DirectoryMatch regex>
- ... </DirectoryMatch> 
    
-Context: server config, virtual host
    
-Status: Core.
    
-Compatibility: Available in Apache 1.3 and later
-
-
    <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.
    
-
-
    See Also:
-<Directory> for a description of how
-regular expressions are mixed in with normal <Directory>s.
-
    
-See also: How Directory,
-Location and Files sections work for an explanation of how these
-different sections are combined when a request is received
-
-
    
-
-
    DocumentRoot directive
    
-
-Syntax: DocumentRoot directory-path
    
-Default: DocumentRoot
-/usr/local/apache/htdocs
    
-Context: server config, virtual host
    
-Status: 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.
-
-
    There appears to be a bug in mod_dir which causes problems when the
-DocumentRoot has a trailing slash (i.e., "DocumentRoot /usr/web/") so
-please avoid that.
-
-
    
-
-
    ErrorDocument directive
    
-
-Syntax: ErrorDocument error-code document
    
-Context: server config, virtual host, directory,
-.htaccess
    
-Status: core
    
-Override: FileInfo
    
-Compatibility: The directory and .htaccess contexts
-are only available in Apache 1.1 and later. The quoting syntax prior to
-Apache 2.0 was different.
    
-
-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. output a customized message
-
    3. redirect to a local URL-path to handle the problem/error
-
    4. redirect to an external URL to handle the problem/error
-
    
-
-
    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.
-
-
    See Also: documentation of customizable
-responses.
    
-
-
    ErrorLog directive
    
-
-Syntax: ErrorLog file-path|syslog[:facility]
-
    
-Default: ErrorLog logs/error_log (Unix)
    
-Default: ErrorLog logs/error.log 
- (Windows and OS/2)
    
-Context: server config, virtual host
    
-Status: core
    
-
-The error log 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.
-
-
    Apache 1.3 and above:
-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.
-
-
    See also: LogLevel and
-Apache Log Files
-
    
-
-
    <Files> directive
    
-Syntax: <Files filename>
-... </Files>
    
-Context: server config, virtual host, .htaccess
    
-Status: core
    
-Compatibility: only available in Apache
-1.2 and above.
    
-
-
    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.
-
-
    
-
-See also: How Directory,
-Location and Files sections work for an explanation of how these
-different sections are combined when a request is received
-
-
    
-
-
    <FilesMatch>
    
-Syntax: <FilesMatch regex>
-... </FilesMatch>
    
-Context: server config, virtual host, .htaccess
    
-Status: core
    
-Compatibility: only available in Apache
-1.3 and above.
    
-
-
    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.
    
-
-See also: How Directory,
-Location and Files sections work for an explanation of how these
-different sections are combined when a request is received
-
-
    
-
-
    ForceType directive
    
-
-Syntax: ForceType mime-type
    
-Context: directory, .htaccess
    
-Status: Base
    
-Module: core
    
-Compatibility: ForceType was introduced in mod_mime
-with Apache 1.1, and moved to the core in Apache 2.0.
    
-
-
    When placed into an .htaccess file or a
-<Directory>, or <Location> or
-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:
+
    + +

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

    See also: How + Directory, Location and Files sections work for an + explanation of how these different sections are combined when a + request is received

    +
    + +

    <DirectoryMatch>

    + Syntax: <DirectoryMatch + regex> ... </DirectoryMatch>
    + Context: server config, virtual + host
    + Status: Core.
    + Compatibility: Available in Apache + 1.3 and later + +

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

    + +

    See Also: <Directory> for a description of how + regular expressions are mixed in with normal + <Directory>s.
    + See also: How + Directory, Location and Files sections work for an + explanation of how these different sections are combined when a + request is received

    +
    + +

    DocumentRoot directive

    + + Syntax: DocumentRoot + directory-path
    + Default: DocumentRoot + /usr/local/apache/htdocs
    + Context: server config, virtual + host
    + Status: 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. + +

    There appears to be a bug in mod_dir which causes problems + when the DocumentRoot has a trailing slash (i.e., + "DocumentRoot /usr/web/") so please avoid that.

    +
    + +

    ErrorDocument directive

    + + Syntax: ErrorDocument + error-code document
    + Context: server config, virtual + host, directory, .htaccess
    + Status: core
    + Override: FileInfo
    + Compatibility: The directory and + .htaccess contexts are only available in Apache 1.1 and later. + The quoting syntax prior to Apache 2.0 was different. + +

    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.

    + +

    See Also: documentation of + customizable responses.

    +
    + +

    ErrorLog directive

    + + Syntax: ErrorLog + file-path|syslog[:facility]
    + Default: ErrorLog + logs/error_log (Unix)
    + Default: ErrorLog + logs/error.log (Windows and OS/2)
    + Context: server config, virtual + host
    + Status: core + +

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

    + +

    Apache 1.3 and above: 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.

    + +

    See also: LogLevel + and Apache Log Files

    +
    + +

    <Files> directive

    + Syntax: <Files + filename> ... </Files>
    + Context: server config, virtual + host, .htaccess
    + Status: core
    + Compatibility: only available in + Apache 1.2 and above. + +

    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.

    + +

    See also: How + Directory, Location and Files sections work for an + explanation of how these different sections are combined when a + request is received

    +
    + +

    <FilesMatch>

    + Syntax: <FilesMatch + regex> ... </FilesMatch>
    + Context: server config, virtual + host, .htaccess
    + Status: core
    + Compatibility: only available in + Apache 1.3 and above. + +

    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.

    + See also: How + Directory, Location and Files sections work for an + explanation of how these different sections are combined when a + request is received +
    + +

    ForceType directive

    + Syntax: ForceType + mime-type
    + Context: directory, .htaccess
    + Status: Base
    + Module: core
    + Compatibility: ForceType was + introduced in mod_mime with Apache 1.1, and moved to the core + in Apache 2.0. + +

    When placed into an .htaccess file or a + <Directory>, or + <Location> or 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 directive

    - -Syntax: HostNameLookups on|off|double
    -Default: HostNameLookups off
    -Context: server config, virtual host, directory
    -Status: core
    -Compatibility: double available only in -Apache -1.3 and above.
    -Compatibility: Default was on prior to -Apache 1.3.

    - -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 for this directive was previously on in -versions of Apache prior to 1.3. It was changed to 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 directive

    - -Syntax: IdentityCheck on|off
    -Default: IdentityCheck off
    -Context: server config, virtual host, directory
    -Status: core

    - -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. Boolean is either -on or off.

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

    -Syntax: <IfDefine [!]parameter-name> ... -</IfDefine>
    -Default: None
    -Context: all
    -Status: Core
    -Compatibility: <IfDefine> is only available in -1.3.1 and later.

    - -

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

    - -

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

    +
+    
    Note that unlike DefaultType,
+    this directive overrides all mime-type associations, including
+    filename extensions, that might identify the media type.
    
+    
    
+
+    
    HostNameLookups
+    directive
    
+    
+    Syntax: HostNameLookups
+    on|off|double
    
+     Default: HostNameLookups
+    off
    
+     Context: server config, virtual
+    host, directory
    
+     Status: core
    
+     Compatibility: double
+    available only in Apache 1.3 and above.
    
+     Compatibility: Default was
+    on prior to Apache 1.3. 
+
+    
    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 for this directive was previously
+    on in versions of Apache prior to 1.3. It was
+    changed to 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 directive
    
+    
+    Syntax: IdentityCheck on|off
    
+     Default: IdentityCheck
+    off
    
+     Context: server config, virtual
+    host, directory
    
+     Status: core 
+
+    
    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. Boolean is either on or
+    off.
    
+
+    
    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> directive
    
+    Syntax: <IfDefine
+    [!]parameter-name> ...
+    </IfDefine>
    
+     Default: None
    
+     Context: all
    
+     Status: Core
    
+     Compatibility: <IfDefine> is
+    only available in 1.3.1 and later. 
+
+    
    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:
    
+
+    
+
+    
    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
@@ -1060,1745 +1023,1665 @@ Example:
   LoadModule rewrite_module modules/mod_rewrite.so
   LoadModule proxy_module   modules/libproxy.so
   </IfDefine>
-
    
-
-
     
    
-
-
    <IfModule> directive
    
-Syntax: <IfModule [!]module-name>
- ...
-</IfModule>
    
-Default: None
    
-Context: all
    
-Status: Core
    
-Compatibility: IfModule is only available in 1.2 and
-later.
    
-
-
    
-
-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:
-
-
    
-
-
    In the former case, the directives between the start and end markers
-are only processed if the module named module name is compiled
-in to Apache. The second format reverses the test, and only processes
-the directives if module name is not compiled in.
-
-
    The module name argument is a module name as given as 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 directive
    
-Syntax: Include file-path|directory-path
    
-Context: server config
    
-Status: Core
    
-Compatibility: Include is only available in Apache 1.3
-and later.
-
    
-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.
-
-
     
    
-
-
    KeepAlive directive
    
-Syntax: KeepAlive on/off
    
-Default: KeepAlive On
    
-Context: server config
    
-Status: Core
    
-Compatibility: KeepAlive is only available in Apache
-1.1 and later.
    
-
-
    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.
    
-
-
    See also  MaxKeepAliveRequests.
    
-
-
    
-
-
    KeepAliveTimeout directive
    
-Syntax: KeepAliveTimeout seconds
    
-Default: KeepAliveTimeout 15
    
-Context: server config
    
-Status: Core
    
-Compatibility: KeepAliveTimeout is only available in
-Apache 1.1 and later.
    
-
-
    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> directive
    
-
-Syntax:
- <Limit method [method] ... > ... </Limit>
    
-Context: any
    
-Status: core
    
-
-Access controls are normally effective for all access
-methods, and this is the usual desired behaviour.  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> directive
    
-
-Syntax:
- <LimitExcept method [method] ... > ... </LimitExcept>
    
-Context: any
    
-Status: core
    
-Compatibility: Available in Apache 1.3.5 and later
    
-
-<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 directive
    
-
-Syntax: LimitRequestBody bytes
    
-Default: LimitRequestBody 0
    
-Context: server config, virtual host, directory,
-.htaccess
    
-Status: core
    
-Compatibility: LimitRequestBody is only available in
-Apache 1.3.2 and later.
-
    
-
-
    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 directive
    
-
-Syntax: LimitRequestFields number
    
-Default: LimitRequestFields 100
    
-Context: server config
    
-Status: core
    
-Compatibility: LimitRequestFields is only available in
-Apache 1.3.2 and later.
-
    
-
-
    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 directive
    
-
-Syntax: LimitRequestFieldsize bytes
    
-Default: LimitRequestFieldsize 8190
    
-Context: server config
    
-Status: core
    
-Compatibility: LimitRequestFieldsize is only available in
-Apache 1.3.2 and later.
-
    
-
-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 directive
    
-
-Syntax: LimitRequestLine bytes
    
-Default: LimitRequestLine 8190
    
-Context: server config
    
-Status: core
    
-Compatibility: LimitRequestLine is only available in
-Apache 1.3.2 and later.
-
    
-
-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 directive
    
-Syntax: LimitXMLRequestBody number
    
-Default: LimitXMLRequestBody 1000000
    
-Context: server config
    
-Status: core
    
-
-
    Limit (in bytes) on maximum size of an XML-based request body.
    
-
-
    
-
-
    <Location> directive
    
-
-Syntax: <Location URL-path|URL>
-... </Location>
    
-Context: server config, virtual host
    
-Status: core
    
-Compatibility: Location is only available in Apache
-1.1 and later.
    
-
-
    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.
-
-
    Apache 1.2 and above:
-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:
-
-
    +
    
+    
    
+
+    
    <IfModule> directive
    
+    Syntax: <IfModule
+    [!]module-name> ... </IfModule>
    
+     Default: None
    
+     Context: all
    
+     Status: Core
    
+     Compatibility: IfModule is only
+    available in 1.2 and later. 
+
+    
    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:
    
+
+    
+
+    
    In the former case, the directives between the start and end
+    markers are only processed if the module named module
+    name is compiled in to Apache. The second format reverses
+    the test, and only processes the directives if module
+    name is not compiled in.
    
+
+    
    The module name argument is a module name as given
+    as 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 directive
    
+    Syntax: Include
+    file-path|directory-path
    
+     Context: server config
    
+     Status: Core
    
+     Compatibility: Include is only
+    available in Apache 1.3 and later. 
+
+    
    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.
    
+    
    
+
+    
    KeepAlive directive
    
+    Syntax: KeepAlive on/off
    
+     Default: KeepAlive On
    
+     Context: server config
    
+     Status: Core
    
+     Compatibility: KeepAlive is only
+    available in Apache 1.1 and later. 
+
+    
    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.
    
+
+    
    See also MaxKeepAliveRequests.
    
+    
    
+
+    
    KeepAliveTimeout
+    directive
    
+    Syntax: KeepAliveTimeout
+    seconds
    
+     Default: KeepAliveTimeout
+    15
    
+     Context: server config
    
+     Status: Core
    
+     Compatibility: KeepAliveTimeout is
+    only available in Apache 1.1 and later. 
+
+    
    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> directive
    
+    
+    Syntax: <Limit method
+    [method] ... > ... </Limit>
    
+     Context: any
    
+     Status: 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, 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>
+    directive
    
+    
+    Syntax: <LimitExcept
+    method [method] ... > ...
+    </LimitExcept>
    
+     Context: any
    
+     Status: core
    
+     Compatibility: Available in Apache
+    1.3.5 and later 
+
+    
    <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
+    directive
    
+    
+    Syntax: LimitRequestBody
+    bytes
    
+     Default: LimitRequestBody
+    0
    
+     Context: server config, virtual
+    host, directory, .htaccess
    
+     Status: core
    
+     Compatibility: LimitRequestBody is
+    only available in Apache 1.3.2 and later. 
+
+    
    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
+    directive
    
+    
+    Syntax: LimitRequestFields
+    number
    
+     Default: LimitRequestFields
+    100
    
+     Context: server config
    
+     Status: core
    
+     Compatibility: LimitRequestFields
+    is only available in Apache 1.3.2 and later. 
+
+    
    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
+    directive
    
+    
+    Syntax: LimitRequestFieldsize
+    bytes
    
+     Default:
+    LimitRequestFieldsize 8190
    
+     Context: server config
    
+     Status: core
    
+     Compatibility:
+    LimitRequestFieldsize is only available in Apache 1.3.2 and
+    later. 
+
+    
    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
+    directive
    
+    
+    Syntax: LimitRequestLine
+    bytes
    
+     Default: LimitRequestLine
+    8190
    
+     Context: server config
    
+     Status: core
    
+     Compatibility: LimitRequestLine is
+    only available in Apache 1.3.2 and later. 
+
+    
    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
+    directive
    
+    Syntax: LimitXMLRequestBody
+    number
    
+     Default: LimitXMLRequestBody
+    1000000
    
+     Context: server config
    
+     Status: core
    
+     
+
+    
    Limit (in bytes) on maximum size of an XML-based request
+    body.
    
+    
    
+
+    
    <Location> directive
    
+    Syntax: <Location
+    URL-path|URL> ... </Location>
    
+     Context: server config, virtual
+    host
    
+     Status: core
    
+     Compatibility: Location is only
+    available in Apache 1.1 and later. 
+
+    
    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.
    
+
+    
    Apache 1.2 and above: 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>
-
    
-
-
    Apache 1.3 and above note about / (slash):  The slash
-character has special
-meaning depending on where in a URL it appears.  People may be used
-to its behaviour 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.
-
-
    
-See also: How Directory,
-Location and Files sections work for an explanation of how these
-different sections are combined when a request is received
-
-
    
-
-
    <LocationMatch>
    
-
-Syntax: <LocationMatch regex>
-... </LocationMatch>
    
-Context: server config, virtual host
    
-Status: core
    
-Compatibility: LocationMatch is only available in 
-Apache 1.3 and later.
    
-
-
    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".
    
-
-See also: How Directory,
-Location and Files sections work for an explanation of how these
-different sections are combined when a request is received
-
-
    
-
-
    LogLevel directive
    
-Syntax: LogLevel level
    
-Default: LogLevel warn
    
-Context: server config, virtual host
    
-Status: core
    
-Compatibility: LogLevel is only available in 1.3 or
-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 ..."
-
    
-
-
    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 directive
    
-Syntax: MaxKeepAliveRequests number
    
-Default: MaxKeepAliveRequests 100
    
-Context: server config
    
-Status: core
    
-Compatibility: Only available in Apache
-1.2 and later.
-
-
    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 directive
    
-
-Syntax: NameVirtualHost addr[:port]
    
-Context: server config
    
-Status: core
    
-Compatibility: NameVirtualHost is only available in
-Apache 1.3 and later
    
-
-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
    
-
-See also:
-Apache Virtual Host documentation
-
    
-
-
    Options directive
    
-
-Syntax: Options [+|-]option [[+|-]option] ...
    
-Context: server config, virtual host, directory,
-.htaccess
    
-Override: Options
    
-Status: 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:
-
    
-
    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.
    
-
    
-
-
-
-
    Port directive
    
-
-Syntax: Port number
    
-Default: Port 80
    
-Context: server config
    
-Status: core
    
-
-Number is a number from 0 to 65535; some port numbers
-(especially below
-1024) are reserved for particular protocols. See /etc/services
-for a list of some defined ports; the standard port for the http protocol
-is 80.
    
-
-The Port directive has two behaviors, the first of which is necessary for
-NCSA backwards compatibility (and which is confusing in the context of
-Apache).
    
-
-
    
-
-The primary behaviour of Port should be considered to be similar to that of
-the ServerName directive.  The ServerName
-and Port together specify what you consider to be the canonical
-address of the server.
-(See also UseCanonicalName.)
    
-
-Port 80 is one of Unix's special ports. All ports numbered below 1024
-are reserved for system use, i.e., regular (non-root) users
-cannot make use of them; instead they can only use higher port
-numbers.  To use port 80, you must start the server from the root
-account.  After binding to the port and before accepting requests,
-Apache will change to a low privileged user as set by the User directive.
    
-
-If you cannot use port 80, choose any other unused port. Non-root users
-will have to choose a port number higher than 1023, such as 8000.
    
-
-SECURITY: if you do start the server as root, be sure not to set User to root. If you run the server as
-root whilst handling connections, your site may be open to a major
-security attack.
    
-
-
    Require directive
    
-
-Syntax: Require entity-name [entity-name] ...
    
-Context: directory, .htaccess
    
-Override: AuthConfig
    
-Status: core
    
-
-This directive selects which authenticated users can access a directory.
-The allowed syntaxes are:
-
    
-
    
-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
    
-
    See also Satisfy and mod_access.
-
    
-
-
    RLimitCPU directive
    
-
-Syntax: RLimitCPU number|max
- [number|max]
-
    
-Default: Unset; uses operating system defaults
-
    
-Context: server config, virtual host
    
-Status: core
    
-Compatibility: RLimitCPU is only available in Apache 1.2
-and later. 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.
    
-
-See also RLimitMEM or
-RLimitNPROC.
    
-
-
    RLimitMEM directive
    
-
-Syntax: RLimitMEM number|max
-  [number|max]
    
-Default: Unset; uses operating system defaults
-
    
-Context: server config, virtual host
    
-Status: core
    
-Compatibility: RLimitMEM is only available in Apache 1.2
-and later. 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.
    
-
-See also RLimitCPU or
-RLimitNPROC.
    
-
-
    RLimitNPROC directive
    
-
-Syntax: RLimitNPROC number|max
- [number|max]
    
-Default: Unset; uses operating system defaults
-
    
-Context: server config, virtual host
    
-Status: core
    
-Compatibility: RLimitNPROC is only available in Apache
-1.2 and later. 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.
    
-
-See also RLimitMEM or
-RLimitCPU.
-
-
    
-
-
    Satisfy directive
    
-
-Syntax: Satisfy any|all
    
-Default: Satisfy all
    
-Context: directory, .htaccess
    
-Status: core
    
-Compatibility: Satisfy is only available in Apache 1.2
-and later
    
-
-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.
-
    
-See also Require and 
-mod_access.
-
-
    
-
-
    ScriptInterpreterSource directive
    
-
-Syntax: ScriptInterpreterSource registry|script
    
-Default: ScriptInterpreterSource script
-
    
-Context: directory, .htaccess
    
-Status: core (Windows only)
    
-
-This directive is used to control how Apache 1.3.5 and later 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 directive
    
-
-Syntax: ServerAdmin email-address
    
-Context: server config, virtual host
    
-Status: core
    
-
-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 directive
    
-
-Syntax: ServerAlias hostname [hostname] ...
    
-Context: virtual host
    
-Status: core
    
-Compatibility: ServerAlias is only available in Apache
-1.1 and later.
    
-
-The ServerAlias directive sets the alternate names for a host, for use
-with
-name-based virtual hosts.
-
-
    See also:
-Apache Virtual Host documentation
-
-
    
-
-
    ServerName directive
    
-
-Syntax: ServerName fully-qualified-domain-name
-
    
-Context: server config, virtual host
    
-Status: core
    
-
-The ServerName directive sets the hostname of the server; this is
-used when creating redirection URLs. If it is not specified, then the
-server attempts to deduce it from its own IP address; however this may
-not work reliably, or may not return the preferred hostname. For example:
-
    ServerName www.example.com
    
-would be used if the canonical (main) name of the actual machine
-were simple.example.com.
    
-
-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 Also:
    
-DNS Issues
    
-Apache virtual host documentation
    
-UseCanonicalName
    
-NameVirtualHost
    
-ServerAlias
    
-
    
-
    
-
-
    ServerPath directive
    
-
-Syntax: ServerPath directory-path
    
-Context: virtual host
    
-Status: core
    
-Compatibility: ServerPath is only available in Apache
-1.1 and later.
    
-
-The ServerPath directive sets the legacy URL pathname for a host, for
-use with name-based virtual hosts.
-
-
    See also:
-Apache Virtual Host documentation
-
-
    
-
-
    ServerRoot directive
    
-
-Syntax: ServerRoot directory-path
    
-Default: ServerRoot /usr/local/apache
    
-Context: server config
    
-Status: core
    
-
-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.
    
-
-See also the -d option to httpd.
    
-See also the security tips
-for information on how to properly set permissions on the ServerRoot.
    
-
-
    
-
-
    ServerSignature directive
    
-
-Syntax: ServerSignature On|Off|EMail
    
-Default: ServerSignature Off
    
-Context: server config, virtual host, directory,
-.htaccess
    
-Status: core
    
-Compatibility: ServerSignature is only available in
-Apache
-1.3 and later.
    
-
-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 directive
    
-
-Syntax: ServerTokens Minimal|ProductOnly|OS|Full
    
-Default: ServerTokens Full
    
-Context: server config 
    
-Status: core
    
-Compatibility: ServerTokens is only available
- in Apache 1.3 and later; the ProductOnly keyword is
- only available in versions later than 1.3.12
-
-
    
-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 directive
    
-
-Syntax: SetHandler handler-name
    
-Context: directory, files, location, .htaccess
    
-Status: Base
    
-Module: core
    
-Compatibility: SetHandler was introduced in mod_mime 
-with Apache 1.1, and moved into the core with 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:
+
    + +

    Apache 1.3 and above 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.

    + +

    See also: How + Directory, Location and Files sections work for an + explanation of how these different sections are combined when a + request is received

    +
    + +

    <LocationMatch>

    + Syntax: <LocationMatch + regex> ... </LocationMatch>
    + Context: server config, virtual + host
    + Status: core
    + Compatibility: LocationMatch is + only available in Apache 1.3 and later. + +

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

    + See also: How + Directory, Location and Files sections work for an + explanation of how these different sections are combined when a + request is received +
    + +

    LogLevel directive

    + Syntax: LogLevel level
    + Default: LogLevel + warn
    + Context: server config, virtual + host
    + Status: core
    + Compatibility: LogLevel is only + available in 1.3 or 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 ..."
    + +

    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 + directive

    + Syntax: MaxKeepAliveRequests + number
    + Default: MaxKeepAliveRequests + 100
    + Context: server config
    + Status: core
    + Compatibility: Only available in + Apache 1.2 and later. + +

    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 + directive

    + + Syntax: NameVirtualHost + addr[:port]
    + Context: server config
    + Status: core
    + Compatibility: NameVirtualHost is + only available in Apache 1.3 and later + +

    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 +
    + See also: Apache Virtual + Host documentation +
    + +

    Options directive

    + + Syntax: Options + [+|-]option [[+|-]option] ...
    + Context: server config, virtual + host, directory, .htaccess
    + Override: Options
    + Status: 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:

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

    +
    + +

    Port directive

    + + Syntax: Port number
    + Default: Port 80
    + Context: server config
    + Status: core + +

    Number is a number from 0 to 65535; some port + numbers (especially below 1024) are reserved for particular + protocols. See /etc/services for a list of some + defined ports; the standard port for the http protocol is + 80.

    + +

    The Port directive has two behaviors, the first of which is + necessary for NCSA backwards compatibility (and which is + confusing in the context of Apache).

    + + + The primary behavior of Port should be considered to be + similar to that of the ServerName + directive. The ServerName and Port together specify what you + consider to be the canonical address of the server. + (See also UseCanonicalName.) + +

    Port 80 is one of Unix's special ports. All ports numbered + below 1024 are reserved for system use, i.e., regular + (non-root) users cannot make use of them; instead they can only + use higher port numbers. To use port 80, you must start the + server from the root account. After binding to the port and + before accepting requests, Apache will change to a low + privileged user as set by the User directive.

    + +

    If you cannot use port 80, choose any other unused port. + Non-root users will have to choose a port number higher than + 1023, such as 8000.

    + +

    SECURITY: if you do start the server as root, be sure not to + set User to root. If you run + the server as root whilst handling connections, your site may + be open to a major security attack.

    +
    + +

    Require directive

    + + Syntax: Require + entity-name [entity-name] ...
    + Context: directory, .htaccess
    + Override: AuthConfig
    + Status: core + +

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

    + + + +

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

    See also Satisfy and mod_access.

    +
    + +

    RLimitCPU directive

    + + Syntax: RLimitCPU + number|max [number|max]
    + Default: Unset; uses operating + system defaults
    + Context: server config, virtual + host
    + Status: core
    + Compatibility: RLimitCPU is only + available in Apache 1.2 and later. 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.

    + +

    See also RLimitMEM or RLimitNPROC.

    +
    + +

    RLimitMEM directive

    + + Syntax: RLimitMEM + number|max [number|max]
    + Default: Unset; uses operating + system defaults
    + Context: server config, virtual + host
    + Status: core
    + Compatibility: RLimitMEM is only + available in Apache 1.2 and later. 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.

    + +

    See also RLimitCPU or RLimitNPROC.

    +
    + +

    RLimitNPROC directive

    + + Syntax: RLimitNPROC + number|max [number|max]
    + Default: Unset; uses operating + system defaults
    + Context: server config, virtual + host
    + Status: core
    + Compatibility: RLimitNPROC is only + available in Apache 1.2 and later. 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.

    + +

    See also RLimitMEM or RLimitCPU.

    +
    + +

    Satisfy directive

    + + Syntax: Satisfy any|all
    + Default: Satisfy all
    + Context: directory, .htaccess
    + Status: core
    + Compatibility: Satisfy is only + available in Apache 1.2 and later + +

    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.

    + +

    See also Require and mod_access.

    +
    + +

    ScriptInterpreterSource + directive

    + + Syntax: ScriptInterpreterSource + registry|script
    + Default: + ScriptInterpreterSource script
    + Context: directory, .htaccess
    + Status: core (Windows only) + +

    This directive is used to control how Apache 1.3.5 and later + 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 directive

    + + Syntax: ServerAdmin + email-address
    + Context: server config, virtual + host
    + Status: core + +

    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 directive

    + Syntax: ServerAlias + hostname [hostname] ...
    + Context: virtual host
    + Status: core
    + Compatibility: ServerAlias is only + available in Apache 1.1 and later. + +

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

    + +

    See also: Apache + Virtual Host documentation

    +
    + +

    ServerName directive

    + + Syntax: ServerName + fully-qualified-domain-name
    + Context: server config, virtual + host
    + Status: core + +

    The ServerName directive sets the hostname of the server; + this is used when creating redirection URLs. If it is not + specified, then the server attempts to deduce it from its own + IP address; however this may not work reliably, or may not + return the preferred hostname. For example:

    + +
    + ServerName www.example.com +
    + would be used if the canonical (main) name of the actual + machine were simple.example.com. + +

    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 Also:
    + DNS Issues
    + Apache virtual host documentation
    + UseCanonicalName
    + NameVirtualHost
    + ServerAlias
    +

    +
    + +

    ServerPath directive

    + Syntax: ServerPath + directory-path
    + Context: virtual host
    + Status: core
    + Compatibility: ServerPath is only + available in Apache 1.1 and later. + +

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

    + +

    See also: Apache + Virtual Host documentation

    +
    + +

    ServerRoot directive

    + + Syntax: ServerRoot + directory-path
    + Default: ServerRoot + /usr/local/apache
    + Context: server config
    + Status: core + +

    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.

    + +

    See also the -d + option to httpd.

    + +

    See also the + security tips for information on how to properly set + permissions on the ServerRoot.

    +
    + +

    ServerSignature + directive

    + + Syntax: ServerSignature + On|Off|EMail
    + Default: ServerSignature + Off
    + Context: server config, virtual + host, directory, .htaccess
    + Status: core
    + Compatibility: ServerSignature is + only available in Apache 1.3 and later. + +

    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 directive

    + + Syntax: ServerTokens + Minimal|ProductOnly|OS|Full
    + Default: ServerTokens + Full
    + Context: server config
    + Status: core
    + Compatibility: ServerTokens is only + available in Apache 1.3 and later; the ProductOnly + keyword is only available in versions later than 1.3.12 + +

    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 directive

    + Syntax: SetHandler + handler-name
    + Context: directory, files, + location, .htaccess
    + Status: Base
    + Module: core
    + Compatibility: SetHandler was + introduced in mod_mime with Apache 1.1, and moved into the core + with 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 access.conf: +

    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 access.conf:

         <Location /status>
     SetHandler server-status
     </Location>
    - -
    - -

    SetInputFilter directive

    -

    Syntax: SetInputFilter filter[;filter...]
    -Default: none
    -Context: directory, files, location, .htaccess
    -Status: 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 seperated by -semicolons in the order in which they should process the content.

    - -

    See also the Filters documentation.

    - - -

    -

    SetOutputFilter directive

    -

    Syntax: SetOutputFilter filter -[filter] ...
    -Default: none
    -Context: directory, files, location, .htaccess
    -Status: 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 seperated by -semicolons in the order in which they should process the content.

    - -

    See also the Filters documentation.

    - -

    -

    TimeOut directive

    - -Syntax: TimeOut number
    -Default: TimeOut 300
    -Context: server config
    -Status: core

    - -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. The amount of time between receipt of TCP packets on a POST or - PUT request. -
    3. The amount of time between ACKs on transmissions of TCP packets - in responses. -
    - -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 directive

    - - -Syntax: UseCanonicalName on|off|dns
    - -Default: UseCanonicalName on
    - -Context: server config, virtual host, directory
    - -Override: Options
    - -Compatibility: UseCanonicalName is only available in -Apache 1.3 and later

    - -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 (and in all versions prior to -1.3) Apache will use the ServerName and Port directives 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. - -

    See also: -ServerName, -Port - -

    - -

    <VirtualHost> directive

    - -Syntax: <VirtualHost addr[:port] -[addr[:port]] ...> ... -</VirtualHost>
    -Context: server config
    -Status: Core.
    -Compatibility: Non-IP address-based Virtual Hosting only -available in Apache 1.1 and later.
    -Compatibility: Multiple address support only available in -Apache 1.2 and later.

    - -<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> -
    - -Each VirtualHost 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 -Port 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. - -

    See also: -Apache Virtual Host documentation
    -See also: -Warnings about DNS and Apache
    -See also: -Setting which addresses and ports Apache uses
    -See also: How Directory, -Location and Files sections work for an explanation of how these -different sections are combined when a request is received -

    - - - - +
    + +

    SetInputFilter directive

    + +

    Syntax: SetInputFilter + filter[;filter...]
    + Default: none
    + Context: directory, files, + location, .htaccess
    + Status: 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 seperated + by semicolons in the order in which they should process the + content.

    + +

    See also the Filters + documentation.

    +
    + +

    SetOutputFilter + directive

    + +

    Syntax: SetOutputFilter + filter [filter] ...
    + Default: none
    + Context: directory, files, + location, .htaccess
    + Status: 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 seperated + by semicolons in the order in which they should process the + content.

    + +

    See also the Filters + documentation.

    +
    + +

    TimeOut directive

    + + Syntax: TimeOut number
    + Default: TimeOut + 300
    + Context: server config
    + Status: core + +

    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 + directive

    + + Syntax: UseCanonicalName + on|off|dns
    + Default: UseCanonicalName + on
    + Context: server config, virtual + host, directory
    + Override: Options
    + Compatibility: UseCanonicalName is + only available in Apache 1.3 and later + +

    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 (and + in all versions prior to 1.3) Apache will use the ServerName and Port + directives 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.

    + +

    See also: ServerName, Port

    +
    + +

    <VirtualHost> + directive

    + + Syntax: <VirtualHost + addr[:port] [addr[:port]] + ...> ... </VirtualHost>
    + Context: server config
    + Status: Core.
    + Compatibility: Non-IP address-based + Virtual Hosting only available in Apache 1.1 and later.
    + Compatibility: Multiple address + support only available in Apache 1.2 and later. + +

    <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

    + + + 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>     +
    + Each VirtualHost 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 Port 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.

    + +

    See also: Apache + Virtual Host documentation
    + See also: Warnings about DNS and Apache
    + See also: Setting + which addresses and ports Apache uses
    + See also: How + Directory, Location and Files sections work for an + explanation of how these different sections are combined when a + request is received

    + + +