From: Joshua Slive Date: Tue, 19 Feb 2002 18:37:19 +0000 (+0000) Subject: Here goes: now committing the transformed version of the xml docs. This is X-Git-Url: https://granicus.if.org/sourcecode?a=commitdiff_plain;h=cacc8eb0a21ece6e92ad3fb319cbd998055f25f1;p=apache Here goes: now committing the transformed version of the xml docs. This is necessary to avoid having to keep the two in sync while we convert. git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@93501 13f79535-47bb-0310-9956-ffa450edef68 --- diff --git a/docs/manual/mod/core.html b/docs/manual/mod/core.html index c2a3b5819f..9ccd54a78f 100644 --- a/docs/manual/mod/core.html +++ b/docs/manual/mod/core.html @@ -1,204 +1,301 @@ - + + + + +core - Apache HTTP Server + + + +
+
+[APACHE DOCUMENTATION]

Apache HTTP Server Version 2.0

+
+

Apache Module core

+ + + + +
+ + + + + + + +
Description: +Core Apache HTTP Server features that are always +available +
Status:Core
+
+

Directives

+ +
+

+AcceptPathInfo Directive +

+ + + + +
+ + + + + + + + + + + + + + + + + + + + + + +
Description: Controls whether requests can contain trailing pathname information
Syntax: +AcceptPathInfo On|Off|Default +
Default:AcceptPathInfo Default
Context:server config, virtual host, directory, .htaccess
Status:Core
Module:core
Compatibility:Available in Apache 2.0.30 and later
+
+ - - - - - Apache Core Features - - - - - - -

Apache Core Features

- -

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

- -

Directives

- - -
- -

AcceptPathInfo directive

- Syntax: AcceptPathInfo On|Off|Default
- Default: - AcceptPathInfo Default
- Context: server config, virtual host, - directory, .htaccess
- Status: core
- Compatibility: - AcceptPathInfo is only available in Apache 2.0.30 and later - -

This directive controls whether requests that contain trailing + +

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

-

For example, assume the location /test/ points to + +

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

-

The three possible arguments for the - AcceptPathInfo directive are:

-
-
off
A request will only be accepted if it + +

The three possible arguments for the + AcceptPathInfo directive are:

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

The primary purpose of the AcceptPathInfo + +

The primary purpose of the AcceptPathInfo directive is to allow you to override the handler's choice of accepting or rejecting PATH_INFO. This override is required, for example, when you use a filter, such @@ -206,637 +303,1036 @@ based on PATH_INFO. The core handler would usually reject the request, so you can use the following configuration to enable such a script:

-
-<Files "mypaths.shtml">
-    Options +Includes
-    SetOutputFilter INCLUDES
-    AcceptPathInfo on
+
+
+ + + + +
+<Files "mypaths.shtml">
+ Options +Includes
+ SetOutputFilter INCLUDES
+ AcceptPathInfo on
</Files> - -
- -

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 +

+
+ + +
+

+AccessFileName Directive +

+ + + + +
+ + + + + + + + + + + + + + + + + + + +
Description: Sets the name of the .htaccess file
Syntax: +AccessFileName filename [filename] ... +
Default:AccessFileName .htaccess
Context:server config, virtual host
Status:Core
Module:core
+
+ + +

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 and Configuration Files

-
- -

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. For - example:

- -
- AddDefaultCharset utf-8 -
- -
-

AddModule - directive

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

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

+ +
+

+AddDefaultCharset Directive +

+ + + + +
+ + + + + + + + + + + + + + + + + + + +
Description: Specifies the default character set to be added for a +response without an explicit character set
Syntax: +AddDefaultCharset On|Off|charset + +
Default:AddDefaultCharset Off
Context:server config, virtual host, directory, .htaccess
Status:Core
Module:core
+
+ -

The server can have modules compiled in which are not + +

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

+ + +
+ + + + +
+ AddDefaultCharset utf-8 +
+
+ +
+
+

+AddModule Directive +

+ + + + +
+ + + + + + + + + + + + + + + + +
Description:
Syntax: +AddModule module [module] ... +
Context:server config
Status:Core
Module:core
+
+ + +

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

- -

For example:

- -
- AddDefaultCharset utf-8 -
- -
- -

AllowOverride - 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 + active modules; this list can be cleared with the ClearModuleList directive.

+ + +

For example:

+ +
+ + + + +
+AddDefaultCharset utf-8 +
+
+ +
+
+

+AllowOverride Directive +

+ + + + +
+ + + + + + + + + + + + + + + + + + + +
Description: Sets the types of directives that are allowed in +.htaccess files
Syntax: +AllowOverride All|None|directive-type [directive-type] ... +
Default:AllowOverride All
Context:directory
Status:Core
Module: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 + +

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

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

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
- -
+ +
+ +
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, + (AddDescription, + AddIcon, AddIconByEncoding, + AddIconByType, + DefaultIcon, DirectoryIndex, FancyIndexing, HeaderName, IndexIgnore, IndexOptions, ReadmeName, etc.).
-
Limit
+ +
Limit
-
- Allow use of the directives controlling host access (Allow, - Deny and Order).
+ +
+ Allow use of the directives controlling host access (Allow, Deny and Order).
-
Options
+ +
Options
-
+ +
Allow use of the directives controlling specific directory - features (Options and XBitHack).
-
- -

Example:

- -
AllowOverride AuthConfig Indexes
- -

See Also: AccessFileName and Configuration Files

-
- -

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 + features (Options and + XBitHack).

+ +
+ + +

Example:

+ + +
+ + + + +
AllowOverride AuthConfig Indexes
+
+ +
+

+See also: +

+ +
+

+AuthName Directive +

+ + + + +
+ + + + + + + + + + + + + + + + + + + +
Description: Sets the authorization realm for use in HTTP +authentication
Syntax: +AuthName auth-domain + +
Context:directory, .htaccess
Override:AuthConfig
Status:Core
Module: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 + AuthName takes a single argument; if the + realm name contains spaces, it must be enclosed in quotation + marks. It must be accompanied by AuthType and Require directives, and directives such + as AuthUserFile and + AuthGroupFile to work.

-

For example:

+ +

For example:

-
AuthName "Top Secret"
+ +
+ + + + +
AuthName "Top Secret"
+
-

The string provided for the AuthRealm is what will + +

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

-

See also: Authentication, Authorization, and - Access Control

- -
- -

AuthType - directive

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

This directive selects the type of user authentication for a + +

+See also: +

+ +
+

+AuthType Directive +

+ + + + +
+ + + + + + + + + + + + + + + + +
Description: Selects the type of user authentication
Syntax: +AuthType Basic|Digest +
Context:directory, .htaccess
Status:Core
Module: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.

- -

See also: Authentication, Authorization, and - Access Control

-
- -

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 + It must be accompanied by AuthName and Require directives, and directives such + as AuthUserFile and + AuthGroupFile to + work.

+ +
+

+See also: +

+ +
+

+ContentDigest Directive +

+ + + + +
+ + + + + + + + + + + + + + + + + + + + + + + + + +
Description: Enables the generation of Content-MD5 HTTP Response +headers
Syntax: +ContentDigest on|off +
Default:ContentDigest off
Context:server config, virtual host, directory, .htaccess
Override:Options
Status:Core
Module:core
Compatibility: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" + +

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

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

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

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


+

+DefaultType Directive +

+ + + + +
+ + + + + + + + + + + + + + + + + + + + + + +
Description: Sets the MIME content-type that will be sent if the +server cannot determine a type in any other way
Syntax: +DefaultType MIME-type + +
Default:DefaultType text/html
Context:server config, virtual host, directory, .htaccess
Override:FileInfo
Status:Core
Module: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 + +

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

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 +

+ + + + +
+ + + + + + + + + + + + + + + + +
Description: Enclose a group of directives that apply only to the +named file-system directory and sub-directories
Syntax: +<Directory directory-path> +... </Directory> +
Context:server config, virtual host
Status:Core
Module: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. 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 + +

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

  • Apply any FileInfo directives in + /home/web/.htaccess +
  • + +
+ + +

Regular expressions are not considered until after all of the + normal sections have been applied. Then all of the regular + expressions are tested in the order they appeared in the + configuration file. For example, with

+ + +
+ + + + +
<Directory ~ abc$>
+ ... directives here ...
+ </Directory>
+ +
+
+ + +

The regular expression section won't be considered until after + all normal <Directory>s and .htaccess files + have been applied. Then the regular expression will match on + /home/abc/public_html/abc and be applied.

+ + +

+Note that the default Apache access for <Directory /> is Allow from All. This means that Apache will serve any file mapped from an URL. It is recommended that you change this with a block such - as

-
- <Directory />
-     Order Deny,Allow
-     Deny from All
+    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. +

-

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

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 + request is received

  • +
+
+

+<DirectoryMatch> Directive +

+ + + + +
+ + + + + + + + + + + + + + + + +
Description: Enclose a group of directives that apply only to +file-system directories that match a regular expression and their +subdirectories
Syntax: +<Directory regex> +... </Directory> +
Context:server config, virtual host
Status:Core
Module:core
+
+ + +

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

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

+See also: +

+ +
+

+DocumentRoot Directive +

+ + + + +
+ + + + + + + + + + + + + + + + + + + +
Description: Sets the directory that forms the main document tree visible +from the web
Syntax: +DocumentRoot directory-path + +
Default:DocumentRoot /usr/local/apache/htdocs
Context:server config, virtual host
Status:Core
Module:core
+
+ + +

This directive sets the directory from which httpd will serve files. Unless matched by a directive like Alias, the server appends the path from the requested URL to the document root to make the path to the document. Example:

-
- DocumentRoot /usr/web -
- then an access to +
+ + + + +
+ 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 + /usr/web/index.html.

+ + +

The DocumentRoot should be specified without + a trailing slash.

+ +
+

+See also: +

+ +
+

+ErrorDocument Directive +

+ + + + +
+ + + + + + + + + + + + + + + + + + + + + + +
Description: Specifies what the server will return to the client +in case of an error
Syntax: +ErrorDocument error-code document + +
Context:server config, virtual host, directory, .htaccess
Override:FileInfo
Status:Core
Module:core
Compatibility:Quoting syntax for text messages is different in Apache +2.0
+
+ + +

In the event of a problem or error, Apache can be configured to do one of four things,

-
    -
  1. output a simple hardcoded error message
  2. + +
      + +
    1. output a simple hardcoded error message
    2. -
    3. output a customized message
    4. + +
    5. output a customized message
    6. -
    7. redirect to a local URL-path to handle the + +
    8. redirect to a local URL-path to handle the problem/error
    9. -
    10. redirect to an external URL to handle the + +
    11. redirect to an external URL to handle the problem/error
    12. -
    + +
-

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

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

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

Note that when you specify an ErrorDocument + +

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 @@ -850,254 +1346,433 @@ 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.

+ document. +

-

Prior to version 2.0, messages were indicated by prefixing + +

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

+See also: +

+ +
+

+ErrorLog Directive +

+ + + + +
+ + + + + + + + + + + + + + + + + + + +
Description: Sets the name of the file to which the server +will log errors
Syntax: + ErrorLog file-path|syslog[:facility] +
Default:ErrorLog logs/error_log (Unix) +ErrorLog logs/error.log (Windows and OS/2)
Context:server config, virtual host
Status:Core
Module:core
+
+ + +

The ErrorLog directive sets the name of + the file to which the server will log any errors it encounters. If + the file-path does not begin with a slash (/) then it is + assumed to be relative to the ServerRoot. If the file-path + begins with a pipe (|) then it is assumed to be a command to spawn + to handle the error log.

+ + +

Using syslog instead of a filename enables logging + via syslogd(8) if the system supports it. The default is to use + syslog facility local7, but you can override this by + using the syslog:facility syntax where facility can be one of the names usually documented in syslog(1).

-

SECURITY: See the security tips + +

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

-
- -

FileETag directive

- Syntax: FileETag - component ...
- Context: server config, virtual - host, directory, .htaccess
- Override: FileInfo
- Status: core
- Compatibility: only available - in Apache 1.3.23 versions and later. - -

- The FileETag directive configures the file attributes that are - used to create the ETag (entity tag) response header field - when the document is based on a file. - (The ETag value is used in cache management to save network - bandwidth.) In Apache 1.3.22 and earlier, the ETag value was - always formed from the file's inode, size, and last-modified - time (mtime). The FileETag directive allows you to choose - which of these -- if any -- should be used. The recognised - keywords are: + +

+See also: +

+ +
+

+FileETag Directive +

+ + + + +
+ + + + + + + + + + + + + + + + + + + +
Description: Configures the file attributes used to create the ETag +HTTP response header
Syntax: +FileETag component ... +
Context:server config, virtual host, directory, .htaccess
Override:FileInfo
Status:Core
Module:core
+
+ + +

+ The FileETag directive configures the file + attributes that are used to create the ETag (entity tag) response + header field when the document is based on a file. (The ETag + value is used in cache management to save network bandwidth.) In + Apache 1.3.22 and earlier, the ETag value was always formed + from the file's inode, size, and last-modified time (mtime). The + FileETag directive allows you to choose which of these -- if any + -- should be used. The recognized keywords are:

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

+ +

+ +

The INode, MTime, and Size keywords may be prefixed with either '+' or '-', which allow changes to be made to the default setting inherited from a broader scope. Any keyword appearing without such a prefix immediately and completely cancels the inherited setting.

-

+ +

If a directory's configuration includes 'FileETag INode MTime Size', and a subdirectory's includes 'FileETag -INode', the setting for that subdirectory (which will be inherited by any sub-subdirectories that don't override it) will be equivalent to - 'FileETag MTime Size'. + 'FileETag MTime Size'.

-
- -

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


+

+<Files> Directive +

+ + + + +
+ + + + + + + + + + + + + + + + +
Description: Contains that directives that apply to matched +filenames
Syntax: +<Files filename> ... </Files> +
Context:server config, virtual host, directory, .htaccess
Status:Core
Module:core
+
+ + +

The <Files> directive + provides for access control by filename. It is comparable to the + Directory + directive and Location directives. It should be + 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 +

+
+ +

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:

    -
    +    request is received
  • +
+
+

+<FilesMatch> Directive +

+ + + + +
+ + + + + + + + + + + + + + + + +
Description: Contains that directives that apply to regular-expression matched +filenames
Syntax: +<FilesMatch regex> ... </FilesMatch> +
Context:server config, virtual host, directory, .htaccess
Status:Core
Module:core
+
+ + +

The <FilesMatch> directive + provides for access control by filename, just as the <Files> directive + does. However, it accepts a regular expression. For example:

+ +
+ + + + +
<FilesMatch "\.(gif|jpe?g|png)$"> - +
+
-

would match most common Internet graphics formats.

- See also: How + +

would match most common Internet graphics formats.

+ +
+

+See also: +

+
+
+

+ForceType Directive +

+ + + + +
+ + + + + + + + + + + + + + + + + + + +
Description: Forces all matching files to be served with the specified +MIME content-type
Syntax: +ForceType mime-type + +
Context:directory, .htaccess
Status:Core
Module:core
Compatibility:Moved to the core in Apache 2.0
+
+ + +

When placed into an .htaccess file or a + <Directory>, or + <Location> or + <Files> section, this directive forces all matching files to be served with the content type identification given by mime-type. For example, if you had a directory full of GIF files, but did not want to label them all with ".gif", you might want to use:

-
+
+
+ + + + +
ForceType image/gif - +
+
-

Note that unlike DefaultType, + +

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


+

+HostnameLookups Directive +

+ + + + +
+ + + + + + + + + + + + + + + + + + + +
Description: Enables DNS lookups on client IP addresses
Syntax: +HostnameLookups on|off|double +
Default:HostnameLookups off
Context:server config, virtual host, directory
Status:Core
Module:core
+
+ + +

This directive enables DNS lookups so that host names can be logged (and passed to CGIs/SSIs in REMOTE_HOST). The value double refers to doing double-reverse DNS. That is, after a reverse lookup is performed, a forward @@ -1106,108 +1781,163 @@ 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 + +

Regardless of the setting, when mod_access is + used for controlling access by hostname, a double reverse lookup + will be performed. This is necessary for security. Note that the + result of this double-reverse isn't generally available unless you + set HostnameLookups double. For example, if only + HostnameLookups on and a request is made to an object + that is protected by hostname restrictions, regardless of whether + the double-reverse fails or not, CGIs will still be passed the + single-reverse result in REMOTE_HOST.

+ + +

The default is off in order to save the network traffic for those sites that don't truly need the reverse lookups done. It is also better for the end users because they don't have to suffer the extra latency that a lookup entails. Heavily loaded sites should leave this directive off, since DNS lookups can take considerable - amounts of time. The utility logresolve, provided in + 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 + + +


+

+IdentityCheck Directive +

+ + + + +
+ + + + + + + + + + + + + + + + + + + +
Description: Enables logging of the RFC1413 identity of the remote +user
Syntax: +IdentityCheck on|off +
Default:IdentityCheck off
Context:
Status:Core
Module: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 access log.

-

The information should not be trusted in any way except for + +

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

-

Note that this can cause serious latency problems accessing + +

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:

- -
    -
  • parameter-name
  • - -
  • !parameter-name
  • -
- -

In the former case, the directives between the start and end + + +


+

+<IfDefine> Directive +

+ + + + +
+ + + + + + + + + + + + + + + + +
Description: Encloses directives that will be processed only +if a test is true at startup
Syntax: +<IfDefine [!]parameter-name> ... + </IfDefine> +
Context:server config, virtual host, directory, .htaccess
Status:Core
Module:core
+
+ + +

The <IfDefine + test>...</IfDefine> section is used to + mark directives that are conditional. The directives within an + <IfDefine> section are only + processed if the test is true. If test is false, + everything between the start and end markers is ignored.

+ + +

The test in the <IfDefine> section directive can be one + of two forms:

+ + +
    + +
  • +parameter-name +
  • + + +
  • +!parameter-name +
  • + +
+ + +

In the former case, the directives between the start and end markers are only processed if the parameter named parameter-name is defined. The second format reverses the test, and only processes the directives if parameter-name is not defined.

-

The parameter-name argument is a define as given on + +

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

+ +

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

+ +
+ + + + +
   $ httpd -DReverseProxy ...
 
@@ -1217,132 +1947,241 @@
   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:

- -
    -
  • module name
  • - -
  • !module name
  • -
- -

In the former case, the directives between the start and end +

+
+ + +
+
+

+<IfModule> Directive +

+ + + + +
+ + + + + + + + + + + + + + + + +
Description: Encloses directives that are processed conditional on the +presence of absence of a specific module
Syntax: +<IfModule [!]module-name> ... + </IfModule> +
Context:server config, virtual host, directory, .htaccess
Status:Core
Module:core
+
+ + +

The <IfModule + test>...</IfModule> section is used to + mark directives that are conditional. The directives within an + <IfModule> section are only + processed if the test is true. If test is false, + everything between the start and end markers is ignored.

+ + +

The test in the <IfModule> section directive can be one + of two forms:

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

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

-

The module name argument is the file name of the + +

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

-

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

-
- -

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

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

+ +
+
+

+Include Directive +

+ + + + +
+ + + + + + + + + + + + + + + + +
Description: Includes other configuration files from within +the server configuration files
Syntax: +Include file-path|directory-path + +
Context:server config
Status:Core
Module:core
+
+ + +

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

-

If Include points to a directory, rather than a + +

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

-

The file path specified may be a fully qualified path (i.e. + +

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

+ ServerRoot directory.

+ + +

Examples:

-

Examples:

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

Or, providing paths relative to your ServerRoot + +

Or, providing paths relative to your ServerRoot directory:

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

Make sure that an included directory does not contain any stray + +

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

+ check:

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

This will help in verifying that you are getting only the files + +

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

-

See also: apachectl

- - -
- -

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

+See also: +

+ +
+

+KeepAlive Directive +

+ + + + +
+ + + + + + + + + + + + + + + + + + + +
Description: Turns on or off HTTP persistent connections.
Syntax: +KeepAlive on|off +
Default:KeepAlive On
Context:server config
Status:Core
Module:core
+
+ + +

The Keep-Alive extension to HTTP/1.0 and the persistent connection feature of HTTP/1.1 provide long-lived HTTP sessions which allow multiple requests to be sent over the same TCP connection. In some cases this has been shown to result in an @@ -1350,7 +2189,8 @@ 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 + +

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 @@ -1362,853 +2202,1386 @@ 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 + +

+See also: +

+ +
+

+KeepAliveTimeout Directive +

+ + + + +
+ + + + + + + + + + + + + + + + + + + +
Description: Sets the amount of time the server will wait for subsequent +requests on a persistent connection
Syntax: +KeepAliveTimeout seconds + +
Default:KeepAliveTimeout 15
Context:server config
Status:Core
Module:core
+
+ + +

The number of seconds Apache will wait for a subsequent request before closing the connection. Once a request has been - received, the timeout value specified by the Timeout directive applies.

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

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


+

+<Limit> Directive +

+ + + + +
+ + + + + + + + + + + + + + + + +
Description: Restrict access controls to only certain HTTP +methods
Syntax: +<Limit method [method] ... > ... + </Limit> +
Context:server config, virtual host, directory, .htaccess
Status:Core
Module:core
+
+ + +

Access controls are normally effective for all access methods, and this is the usual desired behavior. In the general case, access control 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> 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, +
+
+ +

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

+ + +
+

+<LimitExcept> Directive +

+ + + + +
+ + + + + + + + + + + + + + + + +
Description: Restrict access controls to all HTTP methods +except the named ones
Syntax: +<LimitExcept method [method] ... > ... + </LimitExcept> +
Context:server config, virtual host, directory, .htaccess
Status:Core
Module:core
+
+ + +

+<LimitExcept> and + </LimitExcept> are used to enclose a group of + access control directives which will then apply to any HTTP access + method not listed in the arguments; i.e., it is + the opposite of a <Limit> section and can be used to control + both standard and nonstandard/unrecognized methods. See the + documentation for <Limit> for more details.

+ +
+
+

+LimitRequestBody Directive +

+ + + + +
+ + + + + + + + + + + + + + + + + + + +
Description: Restricts the total size of the HTTP request body sent +from the client
Syntax: +LimitRequestBody bytes + +
Default:LimitRequestBody 0
Context:server config, virtual host, directory, .htaccess
Status:Core
Module:core
+
+ + +

This directive specifies the number of bytes from 0 (meaning unlimited) to 2147483647 (2GB) that are allowed in a request body. The default value is defined by the compile-time 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 + +

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


+

+LimitRequestFields Directive +

+ + + + +
+ + + + + + + + + + + + + + + + + + + +
Description: Limits the number of HTTP request header fields that +will be accepted from the client
Syntax: +LimitRequestFields number + +
Default:LimitRequestFields 100
Context:server config
Status:Core
Module:core
+
+ + +

+Number is an integer from 0 (meaning unlimited) to 32767. The default value is defined by the compile-time constant DEFAULT_LIMIT_REQUEST_FIELDS (100 as 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 + +

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


+

+LimitRequestFieldSize Directive +

+ + + + +
+ + + + + + + + + + + + + + + + + + + +
Description: Limits the size of the HTTP request header allowed from the +client
Syntax: +LimitRequestFieldsize bytes + +
Default:LimitRequestFieldsize 8190
Context:server config
Status:Core
Module:core
+
+ + +

This directive specifies the number of bytes from 0 to the value of the compile-time constant DEFAULT_LIMIT_REQUEST_FIELDSIZE (8190 as distributed) that will be allowed in an HTTP request header.

-

The LimitRequestFieldsize directive allows the server - administrator to reduce the limit on the allowed size of an - HTTP request header field below the normal input buffer size - compiled with the server. A server needs this value to be large - enough to hold any one header field from a normal client + +

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

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


+

+LimitRequestLine Directive +

+ + + + +
+ + + + + + + + + + + + + + + + + + + +
Description: Limit the size of the HTTP request line that will be accepted +from the client
Syntax: +LimitRequestLine bytes + +
Default:LimitRequestLine 8190
Context:server config
Status:Core
Module:core
+
+ + +

This directive sets the number of bytes from 0 to the value of the compile-time constant DEFAULT_LIMIT_REQUEST_LINE (8190 as distributed) 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 + +

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


+

+LimitXMLRequestBody Directive +

+ + + + +
+ + + + + + + + + + + + + + + + + + + +
Description: Limits the size of an XML-based request body
Syntax: +LimitXMLRequestBody number + +
Default:LimitXMLRequestBody 1000000
Context:server config
Status:Core
Module:core
+
+ + +

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

-
- -

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


+

+<Location> Directive +

+ + + + +
+ + + + + + + + + + + + + + + + +
Description: Applies the enclosed directives only to matching +URLs
Syntax: +<Location + URL-path|URL> ... </Location> +
Context:server config, virtual host
Status:Core
Module:core
+
+ + +

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

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

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

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

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

-

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

The <Location> + functionality is especially useful when combined with the + SetHandler + directive. For example, to enable status requests, but allow them + only from browsers at foo.com, you might use:

+ +
+ + + + +
+ <Location /status>
+ SetHandler server-status
+ Order Deny,Allow
+ Deny from all
+ Allow from .foo.com
+ </Location> +
+
+ + +
+ + + + +
+

+Note about / (slash) +

+

The slash character has +special meaning depending on where in a URL it appears. People may be +used to its behavior in the filesystem where multiple adjacent slashes +are frequently collapsed to a single slash (i.e., +/home///foo is the same as /home/foo). In +URL-space this is not necessarily true. The <LocationMatch> directive and the regex +version of <Location> require you +to explicitly specify multiple slashes if that is your intention. For +example, <LocationMatch ^/abc> would match the +request URL /abc but not the request URL +//abc. The (non-regex) <Location> directive behaves similarly when +used for proxy requests. But when (non-regex) <Location> is used for non-proxy requests it +will implicitly match multiple slashes with a single slash. For +example, if you specify <Location /abc/def> and the +request is to /abc//def then it will match.

+ +
+
+ + +

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

    -
    +    request is received
  • +
+
+

+<LocationMatch> Directive +

+ + + + +
+ + + + + + + + + + + + + + + + +
Description: Applies the enclosed directives only to regular-expression +matching URLs
Syntax: +<LocationMatch + regex> ... </Location> +
Context:server config, virtual host
Status:Core
Module:core
+
+ + +

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

would match URLs that contained the substring "/extra/data" or "/special/data".

- See also: How + +
+

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

    - - - - + request is received + +
    +

    +LogLevel Directive +

    +
    Level
    + + + +
    + + + + + + + + + + + + + + + + + + + +
    Description: Controls the verbosity of the ErrorLog
    Syntax: +LogLevel level + +
    Default:LogLevel warn
    Context:server config, virtual host
    Status:Core
    Module:core
    +
    + + +

    +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
    emerg Emergencies - system is unusable.
    + +
    "Child cannot open lock file. Exiting"
    alert
    alert Action must be taken immediately.
    + +
    "getpwuid: couldn't determine user name from uid"
    crit
    crit Critical Conditions.
    + +
    "socket: Failed to get a socket, exiting child"
    error
    error Error conditions.
    + +
    "Premature end of script headers"
    warn
    warn Warning conditions.
    + +
    "child process 1234 did not exit, sending another SIGHUP"
    notice
    notice Normal but significant condition.
    + +
    "httpd: caught SIGBUS, attempting to dump core in ..."
    info
    info Informational.
    + +
    "Server seems busy, (you may need to increase StartServers, or Min/MaxSpareServers)..."
    debug
    debug Debug-level messages
    + +
    "Opening config file ..."
    + + + + -

    When a particular level is specified, messages from all + +

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

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


    +

    +MaxKeepAliveRequests Directive +

    + + + + +
    + + + + + + + + + + + + + + + + + + + +
    Description: Sets the number of requests allowed on a persistent +connection
    Syntax: +MaxKeepAliveRequests number + +
    Default:MaxKeepAliveRequests 100
    Context:server config
    Status:Core
    Module:core
    +
    + + +

    The MaxKeepAliveRequests directive + limits the number of requests allowed per connection when + KeepAlive is on. If it is + set to "0", unlimited requests will be allowed. We recommend that this setting be kept to a high value for maximum server performance.

    -
    - -

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

    + + + + +
    + + + + + + + + + + + + + + + + +
    Description: Configures an IP address for name-virtual +hosting
    Syntax: +NameVirtualHost addr[:port] +
    Context:server config
    Status:Core
    Module:core
    +
    + + +

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

    -
    - NameVirtualHost 111.22.33.44:8080 -
    + +

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

    -

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

    -
    - NameVirtualHost [fe80::a00:20ff:fea7:ccea]:8080 -
    +
    + + + + +
    NameVirtualHost 111.22.33.44
    +
    - See also: Apache Virtual - Host documentation -
    + +

    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.

    -

    Options directive

    + +

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

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

    +
    + + + + +
    NameVirtualHost 111.22.33.44:8080
    +
    + + +

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

    + + +
    + + + + +
    NameVirtualHost [fe80::a00:20ff:fea7:ccea]:8080
    +
    + + +
    +
    +

    +Options Directive +

    + + + + +
    + + + + + + + + + + + + + + + + + + + + + + +
    Description: Configures what features are available in a particular +directory
    Syntax: +Options + [+|-]option [[+|-]option] ... +
    Default:Options All
    Context:server config, virtual host, directory, .htaccess
    Override:Options
    Status:Core
    Module:core
    +
    + + +

    The Options directive controls which + server features are available in a particular directory.

    -

    option can be set to None, in which + +

    +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
    -
    All options except for MultiViews. This is the default + +
    All options except for MultiViews. This is the default setting.
    -
    ExecCGI
    + +
    ExecCGI
    -
    + +
    Execution of CGI scripts is permitted.
    -
    FollowSymLinks
    + +
    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.
    + 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
    + +
    Includes
    -
    + +
    Server-side includes are permitted.
    -
    IncludesNOEXEC
    + +
    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
    + +
    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
    + +
    MultiViews
    -
    - Content negotiated + +
    + +Content negotiated MultiViews are allowed.
    -
    SymLinksIfOwnerMatch
    + +
    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 + 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 - + 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: + force.

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

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

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

    The default in the absence of any other settings is All.

    -
    - -

    Require directive

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

    This directive selects which authenticated users can access + + +


    +

    +Require Directive +

    + + + + +
    + + + + + + + + + + + + + + + + + + + +
    Description: Selects which authenticated users can access +a resource
    Syntax: +Require entity-name [entity-name] ... +
    Context:directory, .htaccess
    Override:AuthConfig
    Status:Core
    Module:core
    +
    + + +

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

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

        Only the named users can access the directory.

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

        Only users in the named groups can access the directory.

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

        All valid users can access the directory.

        -
      • -
      - -

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

      - -
      - AuthType Basic
      - AuthName "Restricted Directory"
      - AuthUserFile /web/users
      - AuthGroupFile /web/groups
      - Require group admin
      -
      -
      - Access controls which are applied in this way are effective for + +
    • + +
    + + +

    +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 + place the Require statement into a + <Limit> + section.

    + +
    +

    +See also: +

    + +
    +

    +RLimitCPU Directive +

    + + + + +
    + + + + + + + + + + + + + + + + + + + + + + +
    Description: Limits the CPU consumption of processes launched +by Apache children
    Syntax: +RLimitCPU number|max [number|max] +
    Default:Unset; uses operating system defaults
    Context:server config, virtual host
    Status:Core
    Module:core
    Compatibility: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 @@ -2217,39 +3590,68 @@ the server is running as root, or in the initial startup phase.

    -

    This applies to processes forked off from Apache children + +

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

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

    +See also: +

    + +
    +

    +RLimitMEM Directive +

    + + + + +
    + + + + + + + + + + + + + + + + + + + + + + +
    Description: Limits the memory consumption of processes launched +by Apache children
    Syntax: +RLimitMEM number|max [number|max] +
    Default:Unset; uses operating system defaults
    Context:server config, virtual host
    Status:Core
    Module:core
    Compatibility: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 @@ -2258,39 +3660,68 @@ the server is running as root, or in the initial startup phase.

    -

    This applies to processes forked off from Apache children + +

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

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

    +See also: +

    + +
    +

    +RLimitNPROC Directive +

    + + + + +
    + + + + + + + + + + + + + + + + + + + + + + +
    Description: Limits the number of processes that can be launched by +processes launched by Apache children
    Syntax: +RLimitNPROC number|max [number|max] +
    Default:Unset; uses operating system defaults
    Context:server config, virtual host
    Status:Core
    Module:core
    Compatibility: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 @@ -2299,155 +3730,282 @@ the server is running as root, or in the initial startup phase.

    -

    This applies to processes forked off from Apache children + +

    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.

    + +

    Process limits control the number of processes per user.

    -

    Note: If CGI processes are not running + +

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

    +See also: +

    + +
    +

    +Satisfy Directive +

    + + + + +
    + + + + + + + + + + + + + + + + + + + +
    Description: Configures how host-level access control and user authentication +interact
    Syntax: +Satisfy any|all +
    Default:Satisfy all
    Context:directory, .htaccess
    Status:Core
    Module:core
    +
    + + +

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

    + +
    +
    +

    +ScriptInterpreterSource Directive +

    + + + + +
    + + + + + + + + + + + + + + + + + + + + + + +
    Description: Controls how the interpreter for CGI scripts is +located
    Syntax: +ScriptInterpreterSource registry|script +
    Default:ScriptInterpreterSource script
    Context:directory, .htaccess
    Status:Core
    Module:core
    Compatibility:Win32 only
    +
    + + +

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

    -
    - -

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

    - -

    Example:

    - -
    -    <VirtualHost *>
    -    ServerName server.domain.com
    -    ServerAlias server server2.domain.com server2
    -    ...
    +
    +
    +
    +

    +ServerAdmin Directive +

    + + + + +
    + + + + + + + + + + + + + + + + +
    Description: Sets the email address that the server includes in error +messages sent to the client
    Syntax: +ServerAdmin email-address + +
    Context:server config, virtual host
    Status:Core
    Module: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 +

    + + + + +
    + + + + + + + + + + + + + + + + +
    Description: Sets alternate names for a host used when matching requests +to name-virtual hosts
    Syntax: +ServerAlias hostname [hostname] ... +
    Context:virtual host
    Status:Core
    Module:core
    +
    + + +

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

    + + +
    + + + + +
    + <VirtualHost *>
    + ServerName server.domain.com
    + ServerAlias server server2.domain.com server2
    + ...
    </VirtualHost> - - -

    See also: Apache - Virtual Host documentation

    -
    - -

    ServerName - directive

    - - Syntax: ServerName - fully-qualified-domain-name[:port]
    - Context: server config, virtual - host
    - Status: core
    - Compatibility: In version 2.0, this - directive supercedes the functionality of the Port - directive from version 1.3. - -

    The ServerName directive sets the hostname and +

    +
    + +
    +

    +See also: +

    + +
    +

    +ServerName Directive +

    + + + + +
    + + + + + + + + + + + + + + + + + + + +
    Description: Sets the hostname and port that the server uses to identify +itself
    Syntax: +ServerName fully-qualified-domain-name[:port] + +
    Context:server config, virtual host
    Status:Core
    Module:core
    Compatibility:In version 2.0, this + directive supersedes the functionality of the Port + directive from version 1.3.
    +
    + + +

    The ServerName directive sets the hostname and port that the server uses to identify itself. This is used when creating redirection URLs. For example, if the name of the machine hosting the webserver is simple.example.com, @@ -2455,348 +4013,606 @@ and you wish the webserver to be so identified, the following directive should be used:

    -
    - ServerName www.example.com:80 -
    - -

    If no ServerName is specified, then the server attempts - to deduce the hostname by performing a reverse lookup on the IP - address. If no port is specified in the servername, then the - server will use the port from the incoming request. For optimal - reliability and predictability, you should specify an explict - hostname and port using the ServerName directive.

    - -

    If you are using name-based virtual hosts, - the ServerName inside a <VirtualHost> + +

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

    If no ServerName is specified, then the + server attempts to deduce the hostname by performing a reverse + lookup on the IP address. If no port is specified in the + servername, then the server will use the port from the incoming + request. For optimal reliability and predictability, you should + specify an explicit hostname and port using the + ServerName directive.

    + + +

    If you are using name-based virtual hosts, + the ServerName inside a + <VirtualHost> section specifies what hostname must appear in the request's Host: header to match this virtual host.

    -

    See the description of the - UseCanonicalName directive for + +

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

    -

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

    +See also: +

    + +
    +

    +ServerPath Directive +

    + + + + +
    + + + + + + + + + + + + + + + + +
    Description: Sets the legacy URL pathname for a name-virtual host that +is accessed by an incompatible browser
    Syntax: +ServerPath directory-path + +
    Context:virtual host
    Status:Core
    Module:core
    +
    + + +

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

    + +
    +

    +See also: +

    + +
    +

    +ServerRoot Directive +

    + + + + +
    + + + + + + + + + + + + + + + + + + + +
    Description: Sets the base directory for the server installation
    Syntax: +ServerRoot directory-path + +
    Default:ServerRoot /usr/local/apache
    Context:server config
    Status:Core
    Module: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 + +

    +See also: +

    +
      +
    • +the -d + option to httpd +
    • +
    • +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, + permissions on the ServerRoot

    • +
    +
    +

    +ServerSignature Directive +

    + + + + +
    + + + + + + + + + + + + + + + + + + + +
    Description: Configures the footer on server-generated documents
    Syntax: +ServerSignature On|Off|EMail +
    Default:ServerSignature Off
    Context:server config, virtual host, directory, .htaccess
    Status:Core
    Module:core
    +
    + + +

    The ServerSignature directive allows the + configuration of a trailing footer line under server-generated + documents (error messages, mod_proxy ftp directory listings, + mod_info output, ...). The reason why you would want to enable + such a footer line is that in a chain of proxies, the user often + has no possibility to tell which of the chained servers actually + produced a returned error message.
    The Off + setting, which is the default, suppresses the 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 + "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 + + +


    +

    +ServerTokens Directive +

    + + + + +
    + + + + + + + + + + + + + + + + + + + +
    Description: Configures the Server HTTP response header
    Syntax: +ServerTokens Minimal|ProductOnly|OS|Full +
    Default:ServerTokens Full
    Context:server config
    Status:Core
    Module:core
    +
    + + +

    This directive controls whether Server response header field which is sent back to clients includes a description of the generic OS-type of the server as well as information about compiled-in modules.

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

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


    +

    +SetHandler Directive +

    + + + + +
    + + + + + + + + + + + + + + + + + + + +
    Description: Forces all matching files to be processed by a +handler
    Syntax: +SetHandler handler-name + +
    Context:server config, virtual host, directory, .htaccess
    Status:Core
    Module:core
    Compatibility:Moved into the core in Apache 2.0
    +
    + + +

    When placed into an .htaccess file or a + <Directory> or + <Location> section, this directive forces all matching files to be parsed through the handler given by handler-name. For example, if you had a directory you wanted to be parsed entirely as imagemap rule files, regardless of extension, you might put the following into an .htaccess file in that directory:

    -
    +
    +
    + + + + +
    SetHandler imap-file - +
    +
    -

    Another example: if you wanted to have the server display a + +

    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
    +    the following into httpd.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 +

    +
    + + +
    +

    +SetInputFilter Directive +

    + + + + +
    + + + + + + + + + + + + + + + + +
    Description: Sets the filters that will process client requests and POST +input
    Syntax: +SetInputFilter filter[;filter...] +
    Context:server config, virtual host, directory, .htaccess
    Status:Core
    Module: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 + +

    If more than one filter is specified, they must be separated 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 + +

    +See also: +

    + +
    +

    +SetOutputFilter Directive +

    + + + + +
    + + + + + + + + + + + + + + + + +
    Description: Sets the filters that will process responses from the +server
    Syntax: +SetOutputFilter filter [filter] ... +
    Context:server config, virtual host, directory, .htaccess
    Status:Core
    Module: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 + 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>
    -
    + +

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

    If more than one filter is specified, they must be separated 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:

    +
    +

    +See also: +

    + +
    +

    +TimeOut Directive +

    + + + + +
    + + + + + + + + + + + + + + + + + + + +
    Description: Defines the amount of time the server will wait for +certain events before failing a request
    Syntax: +TimeOut number + +
    Default:TimeOut 300
    Context:server config
    Status:Core
    Module: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 + +
        + +
      1. The total amount of time it takes to receive a GET request.
      2. -
      3. The amount of time between receipt of TCP packets on a + +
      4. The amount of time between receipt of TCP packets on a POST or PUT request.
      5. -
      6. The amount of time between ACKs on transmissions of TCP + +
      7. The amount of time between ACKs on transmissions of TCP packets in responses.
      8. -
      - We plan on making these separately configurable at some point + +
    + + +

    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 hostname and - port specified in the ServerName - directive to construct a canonical name for the server. This - name is used in all self-referential URLs, and for the values - of SERVER_NAME and SERVER_PORT in - CGIs.

    - -

    With UseCanonicalName off Apache will form + the timer is not reset when a packet is sent.

    + +
    +
    +

    +UseCanonicalName Directive +

    + + + + +
    + + + + + + + + + + + + + + + + + + + + + + +
    Description: Configures how the server determines its own name and +port
    Syntax: +UseCanonicalName on|off|dns +
    Default:UseCanonicalName on
    Context:server config, virtual host, directory, .htaccess
    Override:Options
    Status:Core
    Module:core
    +
    + + +

    In many situations Apache has to construct a + self-referential URL. That is, a URL which refers back to + the same server. With UseCanonicalName on Apache will + use the hostname and port specified in the ServerName directive to construct a canonical + name for the server. This name is used in all self-referential + URLs, and for the values of SERVER_NAME and + SERVER_PORT in CGIs.

    + + +

    With UseCanonicalName off Apache will form self-referential URLs using the hostname and port supplied by the client if any are supplied (otherwise it will use the canonical name). These values are the same that are used to @@ -2806,7 +4622,8 @@ SERVER_PORT will be constructed from the client supplied values as well.

    -

    An example where this may be useful is on an intranet server + +

    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 @@ -2816,135 +4633,195 @@ 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 + UseCanonicalName is set off, then Apache will redirect to http://www/splat/.

    -

    There is a third option, UseCanonicalName DNS, + +

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

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

    -
    +
    +

    +See also: +

    + +
    +

    +<VirtualHost> Directive +

    + + + + +
    + + + + + + + + + + + + + + + + +
    Description: Contains directives that apply only to a specific +hostname or IP address
    Syntax: +<VirtualHost + addr[:port] [addr[:port]] + ...> ... </VirtualHost> +
    Context:server config
    Status:Core
    Module:core
    +
    + + +

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

    -

    <VirtualHost> - directive

    + +
      + +
    • The IP address of the virtual host
    • - 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 + +
      • A fully qualified domain name for the IP address of the virtual host.
      • -
      + +
    Example: -
    - <VirtualHost 10.1.2.3>
    - ServerAdmin webmaster@host.foo.com
    - DocumentRoot /www/docs/host.foo.com
    - ServerName host.foo.com
    - ErrorLog logs/host.foo.com-error_log
    - TransferLog logs/host.foo.com-access_log
    - </VirtualHost>
    -
    - -

    IPv6 addresses must be specified in square brackets because - the optional port number could not be determined otherwise. An - IPv6 example is shown below:

    - -
    - <VirtualHost [fe80::a00:20ff:fea7:ccea]>
    - ServerAdmin webmaster@host.foo.com
    - DocumentRoot /www/docs/host.foo.com
    - ServerName host.foo.com
    - ErrorLog logs/host.foo.com-error_log
    - TransferLog logs/host.foo.com-access_log
    - </VirtualHost>
    -
    - -

    Each VirtualHost must correspond to a different IP address, +

    + + + + +
    <VirtualHost 10.1.2.3>
    + ServerAdmin webmaster@host.foo.com
    + DocumentRoot /www/docs/host.foo.com
    + ServerName host.foo.com
    + ErrorLog logs/host.foo.com-error_log
    + TransferLog logs/host.foo.com-access_log
    + </VirtualHost> +
    +
    + + + +

    IPv6 addresses must be specified in square brackets because + the optional port number could not be determined otherwise. An + IPv6 example is shown below:

    + + +
    + + + + +
    +<VirtualHost [fe80::a00:20ff:fea7:ccea]>
    + ServerAdmin webmaster@host.foo.com
    + DocumentRoot /www/docs/host.foo.com
    + ServerName host.foo.com
    + ErrorLog logs/host.foo.com-error_log
    + TransferLog logs/host.foo.com-access_log
    + </VirtualHost> +
    +
    + + +

    Each Virtual Host must correspond to a different IP address, different port number or a different host name for the server, in the former case the server machine must be configured to accept IP packets for multiple addresses. (If the machine does not have multiple network interfaces, then this can be accomplished with the ifconfig alias command (if - your OS supports it), or with kernel patches like VIF (for SunOS(TM) 4.1.x)).

    + your OS supports it), or with kernel patches like VIF (for SunOS(TM) 4.1.x)).

    -

    The special name _default_ can be specified in + +

    The special name _default_ can be specified in which case this virtual host will match any IP address that is not explicitly listed in another virtual host. In the absence of any _default_ virtual host the "main" server config, consisting of all those definitions outside any VirtualHost section, is used when no match occurs.

    -

    You can specify a :port to change the port that - is matched. If unspecified then it defaults to the same port as - the most recent Listen statement - of the main server. You may also specify :* to - match all ports on that address. (This is recommended when used + +

    You can specify a :port to change the port that is + matched. If unspecified then it defaults to the same port as the + most recent Listen + statement of the main server. You may also specify :* + to match all ports on that address. (This is recommended when used with _default_.)

    -

    SECURITY: See the security tips document + +

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

    +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 HTTP Server Version 2.0

    +IndexHome +
+ - diff --git a/docs/manual/mod/mod_access.html b/docs/manual/mod/mod_access.html index 915dcbee70..6db8ed5cf9 100644 --- a/docs/manual/mod/mod_access.html +++ b/docs/manual/mod/mod_access.html @@ -1,303 +1,429 @@ - - - - - - - Apache module mod_access - - - - - - -

Module mod_access

- -

This module provides access control based on client - hostname, IP address, or other characteristics of the client - request.

- -

Status: Base
- Source File: mod_access.c
- Module Identifier: - access_module

- -

Summary

- -

The directives provided by mod_access are used in <Directory>, <Files>, and <Location> sections - as well as .htaccess files to - control access to particular parts of the server. Access can be - controlled based on the client hostname, IP address, or other - characteristics of the client request, as captured in environment variables. The - Allow and Deny directives are used to - specify which clients are or are not allowed access to the - server, while the Order directive sets the default - access state, and configures how the Allow and - Deny directives interact with each other.

- -

Both host-based access restrictions and password-based + + + + +mod_access - Apache HTTP Server + + + +

+
+[APACHE DOCUMENTATION]

Apache HTTP Server Version 2.0

+
+

Apache Module mod_access

+ + + + +
+ + + + + + + + + + +
Description: +Provides access control based on client hostname, IP +address, or other characteristics of the client request. +
Status:Base
Module Identifier:access_module
+
+

Summary

+ + +

The directives provided by mod_access are used in <Directory>, <Files>, and <Location> sections as well as + .htaccess + files to control access to particular parts of the server. Access + can be controlled based on the client hostname, IP address, or + other characteristics of the client request, as captured in environment variables. The Allow and Deny directives are used to + specify which clients are or are not allowed access to the server, + while the Order + directive sets the default access state, and configures how the + Allow and Deny directives interact with each + other.

+ + +

Both host-based access restrictions and password-based authentication may be implemented simultaneously. In that case, - the Satisfy directive is used + the Satisfy directive is used to determine how the two sets of restrictions interact.

-

In general, access restriction directives apply to all + +

In general, access restriction directives apply to all access methods (GET, PUT, POST, etc). This is the desired behavior in most cases. However, it is possible to restrict some methods, while leaving other methods unrestricted, by enclosing the directives - in a <Limit> section.

- -

Directives

- - - -

See also Satisfy and Require.

-
- -

Allow directive

- -

- Syntax: Allow from + in a <Limit> section.

+ +
+

+See also: +

+ +

Directives

+ +
+

+Allow Directive +

+ + + + +
+ + + + + + + + + + + + + + + + + + + +
Description: Controls which hosts can access an area of the +server
Syntax: + Allow from all|host|env=env-variable - [host|env=env-variable] ...
- Context: directory, - .htaccess
- Override: Limit
- Status: Base
- Module: mod_access

- -

The Allow directive affects which hosts can + [host|env=env-variable] ... +

Context:directory, .htaccess
Override:Limit
Status:Base
Module:mod_access
+
+ + + +

The Allow directive affects which hosts can access an area of the server. Access can be controlled by hostname, IP Address, IP Address range, or by other characteristics of the client request captured in environment variables.

-

The first argument to this directive is always + +

The first argument to this directive is always from. The subsequent arguments can take three - different forms. If Allow from all is specified, - then all hosts are allowed access, subject to the configuration - of the Deny and Order directives as - discussed below. To allow only particular hosts or groups of - hosts to access the server, the host can be specified - in any of the following formats:

- -
-
A (partial) domain-name
- -
Example: Allow from apache.org
+ different forms. If Allow from all is specified, then + all hosts are allowed access, subject to the configuration of the + Deny and Order directives as discussed + below. To allow only particular hosts or groups of hosts to access + the server, the host can be specified in any of the + following formats:

+ + +
+ +
A (partial) domain-name
+ + +
Example: Allow from apache.org +
Hosts whose names match, or end in, this string are allowed access. Only complete components are matched, so the above example will match foo.apache.org but it will not match fooapache.org. This configuration will cause the server to perform a reverse DNS lookup on the - client IP address, regardless of the setting of the HostnameLookups + client IP address, regardless of the setting of the HostnameLookups directive.
-
A full IP address
+ +
A full IP address
-
Example: Allow from 10.1.2.3
+ +
Example: Allow from 10.1.2.3 +
An IP address of a host allowed access
-
A partial IP address
+ +
A partial IP address
-
Example: Allow from 10.1
+ +
Example: Allow from 10.1 +
The first 1 to 3 bytes of an IP address, for subnet restriction.
-
A network/netmask pair
+ +
A network/netmask pair
-
Example: Allow from - 10.1.0.0/255.255.0.0
+ +
Example: Allow from + 10.1.0.0/255.255.0.0 +
A network a.b.c.d, and a netmask w.x.y.z. For more fine-grained subnet restriction.
-
A network/nnn CIDR specification
+ +
A network/nnn CIDR specification
-
Example: Allow from 10.1.0.0/16
+ +
Example: Allow from 10.1.0.0/16 +
Similar to the previous case, except the netmask consists of nnn high-order 1 bits.
-
+ +
-

Note that the last three examples above match exactly the + +

Note that the last three examples above match exactly the same set of hosts.

-

IPv6 addresses and IPv6 subnets can be specified as shown + +

IPv6 addresses and IPv6 subnets can be specified as shown below:

-
-       Allow from fe80::a00:20ff:fea7:ccea
+    
+
+ + + + +
+ Allow from fe80::a00:20ff:fea7:ccea
Allow from fe80::a00:20ff:fea7:ccea/10 - - -

The third format of the arguments to the Allow - directive allows access to the server to be controlled based on - the existence of an environment - variable. When Allow from - env=env-variable is specified, then the request - is allowed access if the environment variable - env-variable exists. The server provides the ability - to set environment variables in a flexible way based on - characteristics of the client request using the directives - provided by mod_setenvif. - Therefore, this directive can be used to allow access based on - such factors as the clients User-Agent (browser - type), Referer, or other HTTP request header - fields.

- -

Example:

- -
-
-SetEnvIf User-Agent ^KnockKnock/2.0 let_me_in
-<Directory /docroot>
-    Order Deny,Allow
-    Deny from all
-    Allow from env=let_me_in
+    
+
+ + +

The third format of the arguments to the + Allow directive allows access to the server + to be controlled based on the existence of an environment variable. When Allow from + env=env-variable is specified, then the request is + allowed access if the environment variable env-variable + exists. The server provides the ability to set environment + variables in a flexible way based on characteristics of the client + request using the directives provided by + mod_setenvif. Therefore, this directive can be + used to allow access based on such factors as the clients + User-Agent (browser type), Referer, or + other HTTP request header fields.

+ + +
+ + + + +
+

+Example: +

+ + +SetEnvIf User-Agent ^KnockKnock/2.0 let_me_in
+<Directory /docroot>
+   Order Deny,Allow
+   Deny from all
+   Allow from env=let_me_in
</Directory> - - - -

In this case, browsers with a user-agent string beginning - with KnockKnock/2.0 will be allowed access, and all +

+
+ + +

In this case, browsers with a user-agent string beginning + with KnockKnock/2.0 will be allowed access, and all others will be denied.

-

See also Deny, Order and SetEnvIf.

-
- -

Deny directive

- -

- Syntax: Deny from + +


+

+Deny Directive +

+ + + + +
+ + + + + + + + + + + + + + + + + + + +
Description: Controls which hosts are denied access to the +server
Syntax: + Deny from all|host|env=env-variable - [host|env=env-variable] ...
- Context: directory, - .htaccess
- Override: Limit
- Status: Base
- Module: mod_access

- -

This directive allows access to the server to be restricted + [host|env=env-variable] ... +

Context:directory, .htaccess
Override:Limit
Status:Base
Module:mod_access
+
+ + +

This directive allows access to the server to be restricted based on hostname, IP address, or environment variables. The - arguments for the Deny directive are identical to - the arguments for the Allow directive.

- -

See also Allow, Order and SetEnvIf.

-
- -

Order directive

- -

- Syntax: Order - ordering
- Default: Order - Deny,Allow
- Context: directory, - .htaccess
- Override: Limit
- Status: Base
- Module: mod_access

- -

The Order directive controls the default access - state and the order in which Allow and Deny directives are evaluated. + arguments for the Deny directive are + identical to the arguments for the Allow directive.

+ +
+
+

+Order Directive +

+ + + + +
+ + + + + + + + + + + + + + + + + + + + + + +
Description: Controls the default access state and the order in which +Allow and Deny are +evaluated.
Syntax: + Order ordering + +
Default:Order Deny,Allow
Context:directory, .htaccess
Override:Limit
Status:Base
Module:mod_access
+
+ + + +

The Order directive controls the default + access state and the order in which Allow and Deny directives are evaluated. Ordering is one of

-
-
Deny,Allow
- -
The Deny directives are evaluated before the - Allow directives. Access is allowed by default. - Any client which does not match a Deny directive - or does match an Allow directive will be allowed - access to the server.
- -
Allow,Deny
- -
The Allow directives are evaluated before - the Deny directives. Access is denied by - default. Any client which does not match an - Allow directive or does match a - Deny directive will be denied access to the - server.
- -
Mutual-failure
- -
Only those hosts which appear on the Allow - list and do not appear on the Deny list are - granted access. This ordering has the same effect as - Order Allow,Deny and is deprecated in favor of - that configuration.
-
+ +
+ +
Deny,Allow
+ + +
The Deny directives + are evaluated before the Allow directives. Access is + allowed by default. Any client which does not match a + Deny directive or does + match an Allow + directive will be allowed access to the server.
+ + +
Allow,Deny
+ + +
The Allow + directives are evaluated before the Deny directives. Access is denied + by default. Any client which does not match an Allow directive or does match a + Deny directive will be + denied access to the server.
+ + +
Mutual-failure
+ + +
Only those hosts which appear on the Allow list and do not appear on + the Deny list are + granted access. This ordering has the same effect as Order + Allow,Deny and is deprecated in favor of that + configuration.
+ +
+ + +

Keywords may only be separated by a comma; no whitespace is + allowed between them. Note that in all cases every Allow and Deny statement is evaluated.

+ + +

In the following example, all hosts in the apache.org domain + are allowed access; all other hosts are denied access.

-

Keywords may only be separated by a comma; no whitespace is - allowed between them. Note that in all cases every - Allow and Deny statement is - evaluated.

-

In the following example, all hosts in the apache.org domain - are allowed access; all other hosts are denied access.

+
+ + + + +
+ Order Deny,Allow
+ Deny from all
+ Allow from apache.org
-
- Order Deny,Allow
- Deny from all
- Allow from apache.org
-
-
+
+
-

In the next example, all hosts in the apache.org domain are + +

In the next example, all hosts in the apache.org domain are allowed access, except for the hosts which are in the foo.apache.org subdomain, who are denied access. All hosts not in the apache.org domain are denied access because the default state is to deny access to the server.

-
- Order Allow,Deny
- Allow from apache.org
- Deny from foo.apache.org
-
-
-

On the other hand, if the Order in the last +

+ + + + +
+ Order Allow,Deny
+ Allow from apache.org
+ Deny from foo.apache.org
+ +
+
+ + +

On the other hand, if the Order in the last example is changed to Deny,Allow, all hosts will be allowed access. This happens because, regardless of the actual ordering of the directives in the configuration file, @@ -307,38 +433,47 @@ SetEnvIf User-Agent ^KnockKnock/2.0 let_me_in be allowed access because the default state will change to allow.

-

The presence of an Order directive can affect - access to a part of the server even in the absence of - accompanying Allow and Deny - directives because of its effect on the default access state. - For example,

- -
- <Directory /www>
-   Order Allow,Deny
- </Directory>
-
- -

will deny all access to the /www directory + +

The presence of an Order directive can affect + access to a part of the server even in the absence of accompanying + Allow and Deny directives because of its effect + on the default access state. For example,

+ + +
+ + + + +
+ <Directory /www>
+   Order Allow,Deny
+ </Directory> +
+
+ + +

will deny all access to the /www directory because the default access state will be set to deny.

-

The Order directive controls the order of - access directive processing only within each phase of the - server's configuration processing. This implies, for example, - that an Allow or Deny directive - occurring in a <Location> section will always be - evaluated after an Allow or Deny - directive occurring in a <Directory> section or + +

The Order directive controls the order of access + directive processing only within each phase of the server's + configuration processing. This implies, for example, that an + Allow or Deny directive occurring in a + <Location> section will + always be evaluated after an Allow or Deny directive occurring in a + <Directory> section or .htaccess file, regardless of the setting of the - Order directive. For details on the merging of - configuration sections, see the documentation on How Directory, Location and Files - sections work.

- -

See also: Deny and Allow. -

- + Order directive. For details on the merging + of configuration sections, see the documentation on How Directory, Location and Files sections + work.

+ +
+
+

Apache HTTP Server Version 2.0

+IndexHome +
+ - diff --git a/docs/manual/mod/mod_actions.html b/docs/manual/mod/mod_actions.html index edeeb4653b..20d0444b25 100644 --- a/docs/manual/mod/mod_actions.html +++ b/docs/manual/mod/mod_actions.html @@ -1,122 +1,201 @@ - - - - - - - Module mod_actions - - - - - - -

Module mod_actions

- -

This module provides for executing CGI scripts based on - media type or request method.

- -

Status: Base
- Source File: - mod_actions.c
- Module Identifier: - actions_module

- -

Summary

- -

This module has two directives. The Action directive lets - you run CGI scripts whenever a file of a certain type is - requested. The Script directive lets you run CGI scripts - whenever a particular method is used in a request. This makes - it much easier to execute scripts that process files.

- -

Directives

- - -
- -

Action directive

- -

Syntax: Action action-type - cgi-script
- Context: server config, virtual - host, directory, .htaccess
- Override: FileInfo
- Status: Base
- Module: mod_actions

- -

This directive adds an action, which will activate + + + + +mod_actions - Apache HTTP Server + + + +

+
+[APACHE DOCUMENTATION]

Apache HTTP Server Version 2.0

+
+

Apache Module mod_actions

+ + + + +
+ + + + + + + + + + +
Description: +This module provides for executing CGI scripts based on +media type or request method. +
Status:Base
Module Identifier:actions_module
+
+

Summary

+ + +

This module has two directives. The Action directive lets you run CGI + scripts whenever a file of a certain type is requested. The + Script directive lets + you run CGI scripts whenever a particular method is used in a + request. This makes it much easier to execute scripts that process + files.

+ +
+

Directives

+ +
+

+Action Directive +

+ + + + +
+ + + + + + + + + + + + + + + + + + + +
Description: Activates a CGI script for a particular handler or +content-type
Syntax: +Action action-type cgi-script + +
Context:server config, virtual host, directory, .htaccess
Override:FileInfo
Status:Base
Module:mod_actions
+
+ + +

This directive adds an action, which will activate cgi-script when action-type is triggered by - the request. The action-type can be either a handler or a MIME content type. It + the request. The action-type can be either a handler or a MIME content type. It sends the URL and file path of the requested document using the standard CGI PATH_INFO and PATH_TRANSLATED environment variables.

-

Examples:

-
-    # Requests for files of a particular type:
-    Action image/gif /cgi-bin/images.cgi
 
-    # Files of a particular file extension
-    AddHandler my-file-type .xyz
-    Action my-file-type /cgi-bin/program.cgi
-    
+
+ + + + +
+

+Examples +

+ -

In the first example, requests for files with a MIME content - type of image/gif will instead be handled by the - specified cgi script /cgi-bin/images.cgi.

-

In the second example, requests for files with a file extension of - .xyz are handled instead by the specified cgi script - /cgi-bin/program.cgi.

+ # Requests for files of a particular type:
+ Action image/gif /cgi-bin/images.cgi
-

See also: AddHandler

+
+ # Files of a particular file extension
+ AddHandler my-file-type .xyz
+ Action my-file-type /cgi-bin/program.cgi
-
+
+
-

Script directive

+ +

In the first example, requests for files with a MIME content + type of image/gif will instead be handled by the + specified cgi script /cgi-bin/images.cgi.

-

Syntax: Script method - cgi-script
- Context: server config, virtual - host, directory
- Status: Base
- Module: mod_actions

+ +

In the second example, requests for files with a file extension of + .xyz are handled instead by the specified cgi script + /cgi-bin/program.cgi.

-

This directive adds an action, which will activate - cgi-script when a file is requested using the method of - method. It sends the URL and file path of the requested + +

+See also: +

+ +
+

+Script Directive +

+ + + + +
+ + + + + + + + + + + + + + + + +
Description: Activates a CGI script for a particular request +method.
Syntax: + Script method cgi-script + +
Context:server config, virtual host, directory
Status:Base
Module:mod_actions
+
+ + +

This directive adds an action, which will activate + cgi-script when a file is requested using the method of + method. It sends the URL and file path of the requested document using the standard CGI PATH_INFO and PATH_TRANSLATED environment variables.

-
- Any arbitrary method name may be used. Method names are - case-sensitive, so Script PUT and + +
+ + + + +
+ Any arbitrary method name may be used. Method names are + case-sensitive, so Script PUT and Script put have two entirely different effects. - +
+
-

Note that the Script command defines default actions only. + +

Note that the Script command defines default actions only. If a CGI script is called, or some other resource that is capable of handling the requested method internally, it will do so. Also note that Script with a method of GET @@ -124,14 +203,30 @@ (e.g., foo.html?hi). Otherwise, the request will proceed normally.

-

Examples:

-
-    # For <ISINDEX>-style searching
-    Script GET /cgi-bin/search
-    # A CGI PUT handler
-    Script PUT /~bob/put.cgi
-
- - - +
+ + + + +
+

+Examples +

+ + + # For <ISINDEX>-style searching
+ Script GET /cgi-bin/search
+ # A CGI PUT handler
+ Script PUT /~bob/put.cgi
+ +
+
+ + +
+

Apache HTTP Server Version 2.0

+IndexHome +
+ + diff --git a/docs/manual/mod/mod_alias.html b/docs/manual/mod/mod_alias.html index a0da19fd7a..34579569cf 100644 --- a/docs/manual/mod/mod_alias.html +++ b/docs/manual/mod/mod_alias.html @@ -1,367 +1,598 @@ - - - - - - - Apache module mod_alias - - - - - - -

Module mod_alias

- -

This module provides for mapping different parts of the host - filesystem in the document tree, and for URL redirection.

- -

Status: Base
- Source File: mod_alias.c
- Module Identifier: - alias_module

- -

Summary

- -

The directives contained in this module allow for - manipulation and control of URLs as requests arrive at the - server. The Alias and ScriptAlias - directives are used to map between URLs and filesystem paths. - This allows for content which is not directly under the DocumentRoot to - be served as part of the web document tree. The - ScriptAlias directive has the additional effect of - marking the target directory as containing only CGI - scripts.

- -

The Redirect directives are used to instruct - clients to make a new request with a different URL. They are - often used when a resource has moved to a new location.

- -

A more powerful and flexible set of directives for - manipulating URLs is contained in the mod_rewrite + + + + +mod_alias - Apache HTTP Server + + + +

+
+[APACHE DOCUMENTATION]

Apache HTTP Server Version 2.0

+
+

Apache Module mod_alias

+ + + + +
+ + + + + + + + + + +
Description: +Provides for mapping different parts of the host + filesystem in the document tree and for URL redirection +
Status:Base
Module Identifier:alias_module
+
+

Summary

+ + +

The directives contained in this module allow for manipulation + and control of URLs as requests arrive at the server. The + Alias and ScriptAlias directives are used to + map between URLs and filesystem paths. This allows for content + which is not directly under the DocumentRoot served as part of the web + document tree. The ScriptAlias directive has the + additional effect of marking the target directory as containing + only CGI scripts.

+ + +

The Redirect + directives are used to instruct clients to make a new request with + a different URL. They are often used when a resource has moved to + a new location.

+ + +

A more powerful and flexible set of directives for + manipulating URLs is contained in the mod_rewrite module.

-

Directives

- - -
- -

Alias directive

- -

- Syntax: Alias URL-path - file-path|directory-path
- Context: server config, virtual - host
- Status: Base
- Module: mod_alias

- -

The Alias directive allows documents to be stored in the - local filesystem other than under the DocumentRoot. URLs with a - (%-decoded) path beginning with url-path will be - mapped to local files beginning with - directory-filename.

- -

Example:

- -
- Alias /image /ftp/pub/image -
- -

A request for http://myserver/image/foo.gif would cause the +

+

Directives

+ +
+

+Alias Directive +

+ + + + +
+ + + + + + + + + + + + + + + + +
Description: Maps URLs to filesystem locations
Syntax: + Alias URL-path + file-path|directory-path + +
Context:server config, virtual host
Status:Base
Module:mod_alias
+
+ + + +

The Alias directive allows documents to + be stored in the local filesystem other than under the + DocumentRoot. URLs with a + (%-decoded) path beginning with url-path will be mapped + to local files beginning with directory-filename.

+ + +

Example:

+ + +
+ + + + +
Alias /image /ftp/pub/image
+
+ + +

A request for http://myserver/image/foo.gif would cause the server to return the file /ftp/pub/image/foo.gif.

-

Note that if you include a trailing / on the + +

Note that if you include a trailing / on the url-path then the server will require a trailing / in order to expand the alias. That is, if you use Alias /icons/ /usr/local/apache/icons/ then the url /icons will not be aliased.

-

Note that you may need to specify additional <Directory> - sections which cover the destination of aliases. - Aliasing occurs before <Directory> sections + +

Note that you may need to specify additional <Directory> sections which cover + the destination of aliases. Aliasing occurs before + <Directory> sections are checked, so only the destination of aliases are affected. - (Note however <Location> + (Note however <Location> sections are run through once before aliases are performed, so they will apply.)

-

See also ScriptAlias.

-
- -

AliasMatch

- -

Syntax: AliasMatch regex - file-path|directory-path
- Context: server config, virtual - host
- Status: Base
- Module: mod_alias

- -

This directive is equivalent to Alias, - but makes use of standard regular expressions, instead of - simple prefix matching. The supplied regular expression is - matched against the URL-path, and if it matches, the server - will substitute any parenthesized matches into the given string - and use it as a filename. For example, to activate the - /icons directory, one might use:

-
+
+
+
+

+AliasMatch Directive +

+ + + + +
+ + + + + + + + + + + + + + + + +
Description: Maps URLs to filesystem locations using regular +expressions
Syntax: +AliasMatch regex + file-path|directory-path + +
Context:server config, virtual host
Status:Base
Module:mod_alias
+
+ + +

This directive is equivalent to Alias, but makes use of standard + regular expressions, instead of simple prefix matching. The + supplied regular expression is matched against the URL-path, and + if it matches, the server will substitute any parenthesized + matches into the given string and use it as a filename. For + example, to activate the /icons directory, one might + use:

+ +
+ + + + +
AliasMatch ^/icons(.*) /usr/local/apache/icons$1 - -
-
- -
- -

Redirect - directive

- -

- Syntax: Redirect - [status] URL-path URL
- Context: server config, virtual - host, directory, .htaccess
- Override: FileInfo
- Status: Base
- Module: mod_alias

- -

The Redirect directive maps an old URL into a new one. The +

+
+ +
+
+

+Redirect Directive +

+ + + + +
+ + + + + + + + + + + + + + + + + + + +
Description: Sends an external redirect asking the client to fetch +a different URL
Syntax: +Redirect [status] URL-path URL + +
Context:server config, virtual host, directory, .htaccess
Override:FileInfo
Status:Base
Module:mod_alias
+
+ + +

The Redirect directive maps an old URL into a new one. The new URL is returned to the client which attempts to fetch it again with the new address. URL-path a (%-decoded) path; any requests for documents beginning with this path will be returned a redirect error to a new (%-encoded) URL beginning with URL.

-

Example:

+ +

Example:

-
- Redirect /service http://foo2.bar.com/service -
-

If the client requests http://myserver/service/foo.txt, it +

+ + + + +
Redirect /service http://foo2.bar.com/service
+
+ + +

If the client requests http://myserver/service/foo.txt, it will be told to access http://foo2.bar.com/service/foo.txt instead.

-

Note: Redirect directives take precedence - over Alias and ScriptAlias directives, irrespective of their - ordering in the configuration file. Also, URL-path - must be an absolute path, not a relative path, even when used - with .htaccess files or inside of <Directory> - sections.

-

If no status argument is given, the redirect will +

+ + + + +
+

+Note +

+

Redirect directives take precedence over +Alias and ScriptAlias directives, irrespective of their ordering in +the configuration file. Also, URL-path must be an absolute +path, not a relative path, even when used with .htaccess files or +inside of <Directory> +sections.

+
+
+ + +

If no status argument is given, the redirect will be "temporary" (HTTP status 302). This indicates to the client that the resource has moved temporarily. The status argument can be used to return other HTTP status codes:

-
-
permanent
+ +
+ +
permanent
-
Returns a permanent redirect status (301) indicating that + +
Returns a permanent redirect status (301) indicating that the resource has moved permanently.
-
temp
+ +
temp
-
Returns a temporary redirect status (302). This is the + +
Returns a temporary redirect status (302). This is the default.
-
seeother
+ +
seeother
-
Returns a "See Other" status (303) indicating that the + +
Returns a "See Other" status (303) indicating that the resource has been replaced.
-
gone
+ +
gone
-
Returns a "Gone" status (410) indicating that the + +
Returns a "Gone" status (410) indicating that the resource has been permanently removed. When this status is used the url argument should be omitted.
-
+ +
-

Other status codes can be returned by giving the numeric + +

Other status codes can be returned by giving the numeric status code as the value of status. If the status is between 300 and 399, the url argument must be present, otherwise it must be omitted. Note that the status must be known to the Apache code (see the function send_error_response in http_protocol.c).

-
- -

RedirectMatch

- -

Syntax: RedirectMatch - [status] regex URL
- Context: server config, virtual - host, directory, .htaccess
- Override: FileInfo
- Status: Base
- Module: mod_alias

- -

This directive is equivalent to Redirect, but makes use of standard + + +


+

+RedirectMatch Directive +

+ + + + +
+ + + + + + + + + + + + + + + + + + + +
Description: Sends an external redirect asking the client to fetch +a different URL based on a regular expression match of the +current URL
Syntax: +RedirectMatch [status] regex URL + +
Context:server config, virtual host, directory, .htaccess
Override:FileInfo
Status:Base
Module:mod_alias
+
+ + +

This directive is equivalent to Redirect, but makes use of standard regular expressions, instead of simple prefix matching. The - supplied regular expression is matched against the URL-path, - and if it matches, the server will substitute any parenthesized + supplied regular expression is matched against the URL-path, and + if it matches, the server will substitute any parenthesized matches into the given string and use it as a filename. For example, to redirect all GIF files to like-named JPEG files on another server, one might use:

-
+
+
+ + + + +
RedirectMatch (.*)\.gif$ http://www.anotherserver.com$1.jpg - -
-
- -
- -

RedirectTemp - directive

- -

- Syntax: RedirectTemp - URL-path URL
- Context: server config, virtual - host, directory, .htaccess
- Override: FileInfo
- Status: Base
- Module: mod_alias

- -

This directive makes the client know that the Redirect is - only temporary (status 302). Exactly equivalent to - Redirect temp.

-
- -

RedirectPermanent - directive

- -

- Syntax: RedirectPermanent - URL-path URL
- Context: server config, virtual - host, directory, .htaccess
- Override: FileInfo
- Status: Base
- Module: mod_alias

- -

This directive makes the client know that the Redirect is +

+
+ + +
+

+RedirectPermanent Directive +

+ + + + +
+ + + + + + + + + + + + + + + + + + + +
Description: Sends an external permanent redirect asking the client to fetch +a different URL
Syntax: +RedirectPermanent URL-path URL + +
Context:server config, virtual host, directory, .htaccess
Override:FileInfo
Status:Base
Module:mod_alias
+
+ + +

This directive makes the client know that the Redirect is permanent (status 301). Exactly equivalent to Redirect permanent.

-
- -

ScriptAlias - directive

- -

- - Syntax: ScriptAlias - URL-path file-path|directory-path
- Context: server config, virtual - host
- Status: Base
- Module: mod_alias

- -

The ScriptAlias directive has the same behavior as the Alias directive, except that in addition it - marks the target directory as containing CGI scripts that will be - processed by mod_cgi's cgi-script - handler. URLs with a (%-decoded) path beginning with - URL-path will be mapped to scripts beginning with the - second argument which is a full pathname in the local - filesystem.

- -

Example:

- -
- ScriptAlias /cgi-bin/ /web/cgi-bin/ -
- -

A request for http://myserver/cgi-bin/foo would cause the - server to run the script /web/cgi-bin/foo.

-
- -

ScriptAliasMatch

- -

Syntax: ScriptAliasMatch - regex file-path|directory-path
- Context: server config, virtual - host
- Status: Base
- Module: mod_alias

- -

This directive is equivalent to ScriptAlias, but makes use of standard + + +


+

+RedirectTemp Directive +

+ + + + +
+ + + + + + + + + + + + + + + + + + + +
Description: Sends an external temporary redirect asking the client to fetch +a different URL
Syntax: +RedirectTemp URL-path URL + +
Context:server config, virtual host, directory, .htaccess
Override:FileInfo
Status:Base
Module:mod_alias
+
+ + +

This directive makes the client know that the Redirect is + only temporary (status 302). Exactly equivalent to + Redirect temp.

+ +
+
+

+ScriptAlias Directive +

+ + + + +
+ + + + + + + + + + + + + + + + +
Description: Maps a URL to a filesystem location and designates the +target as a CGI script
Syntax: +ScriptAlias +URL-path file-path|directory-path + +
Context:server config, virtual host
Status:Base
Module:mod_alias
+
+ + +

The ScriptAlias directive has the same + behavior as the Alias + directive, except that in addition it marks the target directory + as containing CGI scripts that will be processed by mod_cgi's cgi-script handler. URLs with a + (%-decoded) path beginning with URL-path will be mapped + to scripts beginning with the second argument which is a full + pathname in the local filesystem.

+ + +

Example:

+ + +
+ + + + +
ScriptAlias /cgi-bin/ /web/cgi-bin/
+
+ + +

A request for http://myserver/cgi-bin/foo would cause the + server to run the script /web/cgi-bin/foo.

+ +
+
+

+ScriptAliasMatch Directive +

+ + + + +
+ + + + + + + + + + + + + + + + +
Description: Maps a URL to a filesystem location using a regular expression +and designates the target as a CGI script
Syntax: +ScriptAliasMatch +regex file-path|directory-path + +
Context:server config, virtual host
Status:Base
Module:mod_alias
+
+ + +

This directive is equivalent to ScriptAlias, but makes use of standard regular expressions, instead of simple prefix matching. The supplied regular expression is matched against the URL-path, and if it matches, the server will substitute any parenthesized matches into the given string and use it as a filename. For example, to activate the standard /cgi-bin, one might use:

-
+
+
+ + + + +
ScriptAliasMatch ^/cgi-bin(.*) /usr/local/apache/cgi-bin$1 - -
-
- - +
+
+ + +
+

Apache HTTP Server Version 2.0

+IndexHome +
+ - diff --git a/docs/manual/mod/mod_asis.html b/docs/manual/mod/mod_asis.html index c71ec725c1..6b517585a8 100644 --- a/docs/manual/mod/mod_asis.html +++ b/docs/manual/mod/mod_asis.html @@ -1,93 +1,125 @@ - - - - - - - Apache module mod_asis - - - - - - -

Module mod_asis

- -

This module provides for sending files which contain their - own HTTP headers.

- -

Status: Base
- Source File: mod_asis.c
- Module Identifier: - asis_module

- -

Summary

- -

This module provides the handler send-as-is + + + + +mod_asis - Apache HTTP Server + + + +

+
+[APACHE DOCUMENTATION]

Apache HTTP Server Version 2.0

+
+

Apache Module mod_asis

+ + + + +
+ + + + + + + + + + +
Description: +Sends files that contain their own +HTTP headers +
Status:Base
Module Identifier:asis_module
+
+

Summary

+ + +

This module provides the handler send-as-is which causes Apache to send the document without adding most of the usual HTTP headers.

-

This can be used to send any kind of data from the server, + +

This can be used to send any kind of data from the server, including redirects and other special HTTP responses, without requiring a cgi-script or an nph script.

-

For historical reasons, this module will also process any + +

For historical reasons, this module will also process any file with the mime type httpd/send-as-is.

-

Directives

+
+

Directives

+

This module provides no directives.

+

Usage

-

This module provides no directives.

+ +

In the server configuration file, associate files with the + send-as-is handler e.g. +

-

Usage

-

In the server configuration file, associate files with the - send-as-is handler e.g.

+
+ + + + +
AddHandler send-as-is asis
+
-
- AddHandler send-as-is asis -
- The contents of any file with a .asis extension + +

The contents of any file with a .asis extension will then be sent by Apache to the client with almost no changes. Clients will need HTTP headers to be attached, so do not forget them. A Status: header is also required; the data should be the 3-digit HTTP response code, followed by a textual - message. + message.

-

Here's an example of a file whose contents are sent as + +

Here's an example of a file whose contents are sent as is so as to tell the client that a file has redirected.

-
- Status: 301 Now where did I leave that URL
- Location: http://xyz.abc.com/foo/bar.html
- Content-type: text/html
-
- <HTML>
- <HEAD>
- <TITLE>Lame excuses'R'us</TITLE>
- </HEAD>
- <BODY>
+ + +
+ + + + +
Status: 301 Now where did I leave that URL
+ Location: http://xyz.abc.com/foo/bar.html
+ Content-type: text/html
+ +
+ <HTML>
+ <HEAD>
+ <TITLE>Lame excuses'R'us</TITLE>
+ </HEAD>
+ <BODY>
<H1>Fred's exceptionally wonderful page has moved - to
+ to
<A HREF="http://xyz.abc.com/foo/bar.html">Joe's</A> - site.
- </H1>
- </BODY>
- </HTML>
- - -

Notes: the server always adds a Date: and Server: header to + site.
+ </H1>
+ </BODY>
+ </HTML> +

+
+ + +

Notes: the server always adds a Date: and Server: header to the data returned to the client, so these should not be included in the file. The server does not add a - Last-Modified header; it probably should. - -

- - + Last-Modified header; it probably should.

+
+

Apache HTTP Server Version 2.0

+IndexHome +
+ + diff --git a/docs/manual/mod/mod_auth.html b/docs/manual/mod/mod_auth.html index 26d3bf54b9..28edd22ded 100644 --- a/docs/manual/mod/mod_auth.html +++ b/docs/manual/mod/mod_auth.html @@ -1,218 +1,368 @@ - - - - - - - Apache module mod_auth - - - - - - -

Module mod_auth

- -

This module provides for user authentication using text - files.

- -

Status: Base
- Source File: mod_auth.c
- Module Identifier: - auth_module

- -

Summary

- -

This module allows the use of HTTP Basic Authentication to + + + + +mod_auth - Apache HTTP Server + + + +

+
+[APACHE DOCUMENTATION]

Apache HTTP Server Version 2.0

+
+

Apache Module mod_auth

+ + + + +
+ + + + + + + + + + +
Description: +User authentication using text files +
Status:Base
Module Identifier:auth_module
+
+

Summary

+ + + +

This module allows the use of HTTP Basic Authentication to restrict access by looking up users in plain text password and group files. Similar functionality and greater scalability is - provided by mod_auth_dbm. - HTTP Digest Authentication is provided by mod_auth_digest.

- -

Directives

- - - -

See also: require and satisfy.

-
- -

AuthGroupFile directive

- - Syntax: AuthGroupFile - file-path
- Context: directory, - .htaccess
- Override: AuthConfig
- Status: Base
- Module: mod_auth - -

The AuthGroupFile directive sets the name of a textual file - containing the list of user groups for user authentication. - File-path is the path to the group file. If it is not - absolute (i.e., if it doesn't begin with a slash), it - is treated as relative to the ServerRoot.

- -

Each line of the group file contains a groupname followed by - a colon, followed by the member usernames separated by spaces. - Example:

- -
- mygroup: bob joe anne -
- Note that searching large text files is very - inefficient; AuthDBMGroupFile - should be used instead. - -

Security: make sure that the AuthGroupFile is stored outside + provided by mod_auth_dbm. HTTP Digest + Authentication is provided by + mod_auth_digest.

+ + +
+

+See also: +

+ +

Directives

+ +
+

+AuthAuthoritative Directive +

+ + + + +
+ + + + + + + + + + + + + + + + + + + + + + +
Description: Sets whether authorization and authentication are +passed to lower level modules
Syntax: +AuthAuthoritative on|off +
Default:AuthAuthoritative on
Context:directory, .htaccess
Override:AuthConfig
Status:Base
Module:mod_auth
+
+ + + +
+ + + + +
This information has not been updated for Apache 2.0, which +uses a different system for module ordering.
+
+ + +

Setting the AuthAuthoritative directive + explicitly to 'off' allows for both + authentication and authorization to be passed on to lower level + modules (as defined in the Configuration and + modules.c files) if there is no + userID or rule matching the supplied + userID. If there is a userID and/or rule specified; the usual + password and access checks will be applied and a failure will give + an Authorization Required reply.

+ + +

So if a userID appears in the database of more than one module; + or if a valid Require + directive applies to more than one module; then the first module + will verify the credentials; and no access is passed on; + regardless of the AuthAuthoritative setting.

+ + +

A common use for this is in conjunction with one of the + database modules; such as auth_dbm, + mod_auth_msql, and mod_auth_anon. + These modules supply the bulk of the user credential checking; but + a few (administrator) related accesses fall through to a lower + level with a well protected AuthUserFile.

+ + +

By default; control is not passed on; and an unknown userID or + rule will result in an Authorization Required reply. Not setting + it thus keeps the system secure; and forces an NCSA compliant + behaviour.

+ + +
+ + + + +
+

+Security +

Do consider the implications of + allowing a user to allow fall-through in his .htaccess file; and + verify that this is really what you want; Generally it is easier + to just secure a single .htpasswd file, than it is to secure a + database such as mSQL. Make sure that the AuthUserFile is stored outside the + document tree of the web-server; do not put it in the + directory that it protects. Otherwise, clients will be able to + download the AuthUserFile. +
+
+ +
+
+

+AuthGroupFile Directive +

+ + + + +
+ + + + + + + + + + + + + + + + + + + +
Description: Sets the name of a text file containing the list +of user groups for authentication
Syntax: +AuthGroupFile file-path + +
Context:directory, .htaccess
Override:AuthConfig
Status:Base
Module:mod_auth
+
+ + +

The AuthGroupFile directive sets the + name of a textual file containing the list of user groups for user + authentication. File-path is the path to the group + file. If it is not absolute (i.e., if it doesn't begin + with a slash), it is treated as relative to the ServerRoot.

+ + +

Each line of the group file contains a groupname followed by a + colon, followed by the member usernames separated by spaces. + Example:

+ + +
+ + + + +
mygroup: bob joe anne
+
+ + +

Note that searching large text files is very + inefficient; AuthDBMGroupFile should be used + instead.

+ + +
+ + + + +
+

+Security +

+ +

Make sure that the AuthGroupFile is stored outside the document tree of the web-server; do not put it in the directory that it protects. Otherwise, clients will be able to download the AuthGroupFile.

-

See also AuthName, AuthType and AuthUserFile.

-
- -

AuthUserFile - directive

- - Syntax: AuthUserFile - file-path
- Context: directory, - .htaccess
- Override: AuthConfig
- Status: Base
- Module: mod_auth - -

The AuthUserFile directive sets the name of a textual file - containing the list of users and passwords for user - authentication. File-path is the path to the user +

+
+ +
+
+

+AuthUserFile Directive +

+ + + + +
+ + + + + + + + + + + + + + + + + + + +
Description: Sets the name of a text file containing the list of users and +passwords for authentication
Syntax: +AuthUserFile file-path + +
Context:directory, .htaccess
Override:AuthConfig
Status:Base
Module:mod_auth
+
+ + +

The AuthUserFile directive sets the name + of a textual file containing the list of users and passwords for + user authentication. File-path is the path to the user file. If it is not absolute (i.e., if it doesn't begin - with a slash), it is treated as relative to the ServerRoot.

+ with a slash), it is treated as relative to the ServerRoot.

-

Each line of the user file file contains a username followed - by a colon, followed by the crypt() encrypted password. The - behavior of multiple occurrences of the same user is + +

Each line of the user file file contains a username followed by + a colon, followed by the crypt() encrypted + password. The behavior of multiple occurrences of the same user is undefined.

-

The utility htpasswd + +

The utility htpasswd which is installed as part of the binary distribution, or which can be found in src/support, is used to maintain this password file. See the man page for more - details. In short

- -
- htpasswd -c Filename username
- Create a password file 'Filename' with 'username' as the - initial ID. It will prompt for the password. htpasswd - Filename username2
- Adds or modifies in password file 'Filename' the 'username'. -
- -

Note that searching large text files is very - inefficient; AuthDBMUserFile - should be used instead.

- -

Security: make sure that the AuthUserFile is stored outside - the document tree of the web-server; do not put it in - the directory that it protects. Otherwise, clients will be able - to download the AuthUserFile.

- -

See also AuthName, AuthType and AuthGroupFile.

-
- -

AuthAuthoritative directive

- - Syntax: AuthAuthoritative - on|off
- Default: - AuthAuthoritative on
- Context: directory, - .htaccess
- Override: AuthConfig
- Status: Base
- Module: mod_auth - -

Setting the AuthAuthoritative directive explicitly to - 'off' allows for both authentication and - authorization to be passed on to lower level modules (as - defined in the Configuration and - modules.c files) if there is no - userID or rule matching the supplied - userID. If there is a userID and/or rule specified; the usual - password and access checks will be applied and a failure will - give an Authorization Required reply.

- -

So if a userID appears in the database of more than one - module; or if a valid Require directive applies to - more than one module; then the first module will verify the - credentials; and no access is passed on; regardless of the - AuthAuthoritative setting.

- -

A common use for this is in conjunction with one of the - database modules; such as mod_auth_dbm.c, mod_auth_msql.c, and mod_auth_anon.c. - These modules supply the bulk of the user credential checking; - but a few (administrator) related accesses fall through to a - lower level with a well protected AuthUserFile.

- -

Default: By default; control is - not passed on; and an unknown userID or rule will result in an - Authorization Required reply. Not setting it thus keeps the - system secure; and forces an NCSA compliant behaviour.

- -

Security: Do consider the implications of allowing a user to - allow fall-through in his .htaccess file; and verify that this - is really what you want; Generally it is easier to just secure - a single .htpasswd file, than it is to secure a database such - as mSQL. Make sure that the AuthUserFile is stored outside the - document tree of the web-server; do not put it in the - directory that it protects. Otherwise, clients will be able to - download the AuthUserFile.

- -

See also AuthName, AuthType and AuthGroupFile.

- -

-

- + details. In short:

+ + +

Create a password file 'Filename' with 'username' as the + initial ID. It will prompt for the password:

+ +
+ + + + +
htpasswd -c Filename username
+
+ + +

Adds or modifies in password file 'Filename' the 'username':

+ +
+ + + + +
htpasswd Filename username2
+
+ + +

Note that searching large text files is very + inefficient; AuthDBMUserFile should be used + instead.

+ + +
+ + + + +
+

+Security +

+

Make sure that the AuthUserFile is +stored outside the document tree of the web-server; do not +put it in the directory that it protects. Otherwise, clients will be +able to download the AuthUserFile.

+
+
+ + +
+
+

Apache HTTP Server Version 2.0

+IndexHome +
+ - diff --git a/docs/manual/mod/mod_include.html b/docs/manual/mod/mod_include.html index dcb4531a86..0bf121dcd0 100644 --- a/docs/manual/mod/mod_include.html +++ b/docs/manual/mod/mod_include.html @@ -709,10 +709,8 @@ potentially change on subsequent requests).

-
-

-

+ diff --git a/docs/manual/mod/mod_info.html b/docs/manual/mod/mod_info.html index fc5d2aac18..6942076ab1 100644 --- a/docs/manual/mod/mod_info.html +++ b/docs/manual/mod/mod_info.html @@ -1,103 +1,173 @@ - - - - - - - Apache module mod_info - - - - - - -

Module mod_info

- -

This module provides a comprehensive overview of the server - configuration including all installed modules and directives in - the configuration files.

+ + + + +mod_info - Apache HTTP Server + + + +
+
+[APACHE DOCUMENTATION]

Apache HTTP Server Version 2.0

+
+

Apache Module mod_info

+ + + + +
+ + + + + + + + + + + + + +
Description: +This module provides a comprehensive overview of the server +configuration including all installed modules and directives in the +configuration files. +
Status:Extension
Module Identifier:info_module
Compatibility: +Available in Apache 1.1 and later +
+
+

Summary

+ + + +

Using mod_info

+ + +

To configure it, add the following to your + httpd.conf file.

-

Status: Extension
- Source File: mod_info.c
- Module Identifier: - info_module
- Compatibility: Available in - Apache 1.1 and later.

-

Directives

+
+ + + + +
+<Location /server-info>
+SetHandler server-info
+</Location>
- +
+
-

Using mod_info

- -

To configure it, add the following to your - httpd.conf file.

-
-<Location /server-info>
-SetHandler server-info
-</Location>
-
- You may wish to add a <Limit> clause inside the location directive to limit - access to your server configuration information. + You may wish to add a + <Limit> + clause inside the + <location> + directive to limit access to your server configuration + information.

Once configured, the server information is obtained by - accessing http://your.host.dom/server-info

- -
- Note that the configuration files are read by the + accessing http://your.host.dom/server-info +

+ + +
+ + + + +
+ Note that the configuration files are read by the module at run-time, and therefore the display may not reflect the running server's active configuration if the files have been changed since the server was last reloaded. Also, the configuration files must be readable by the user as which the server is running (see the - User directive), or - else the directive settings will not be listed. + User directive), or + else the directive settings will not be listed. -

It should also be noted that if - mod_info is compiled into the server, its +

It should also be noted that if + mod_info is compiled into the server, its handler capability is available in all configuration files, including per-directory files (e.g., - .htaccess). This may have security-related - ramifications for your site.

- -
- -

AddModuleInfo

- Syntax: AddModuleInfo - module-name string
- Context: server config, virtual - host
- Status: Extension
- Module: mod_info
- Compatibility: Apache 1.3 and - above - -

This allows the content of string to be shown as + .htaccess). This may have security-related + ramifications for your site.

+ +
+
+ +
+

Directives

+ +
+

+AddModuleInfo Directive +

+ + + + +
+ + + + + + + + + + + + + + + + + + + + + + +
Description: Allows additional information to be added to the module +information displayed by the server-info handler
Syntax: +AddModuleInfo module-name string + +
Default:none
Context:server config, virtual +host
Status:Extension
Module:mod_info
Compatibility:Apache 1.3 and above
+
+ + +

This allows the content of string to be shown as HTML interpreted, Additional Information for the module module-name. Example:

-
-
+
+
+ + + + +
AddModuleInfo mod_auth.c 'See <A HREF="http://www.apache.org/docs/mod/mod_auth.html">http://www.apache.org/docs/mod/mod_auth.html</A>' - - - - +
+
+ + +
+

Apache HTTP Server Version 2.0

+IndexHome +
+ - diff --git a/docs/manual/mod/mod_rewrite.html b/docs/manual/mod/mod_rewrite.html index 66d2f273ef..e514ecd349 100644 --- a/docs/manual/mod/mod_rewrite.html +++ b/docs/manual/mod/mod_rewrite.html @@ -1,83 +1,86 @@ - - - - - - - - - - Apache module mod_rewrite - - - - -
- - -
- - -

Module mod_rewrite
- URL Rewriting Engine

- -

This module provides a rule-based rewriting engine to - rewrite requested URLs on the fly.

- -

Status: Extension
- Source File: - mod_rewrite.c
- Module Identifier: - rewrite_module
- Compatibility: Available in - Apache 1.2 and later.

-
-
- - -

Summary

- -
-
-
- ``The great thing about mod_rewrite is it gives you + + + + +mod_rewrite - Apache HTTP Server + + + +
+
+[APACHE DOCUMENTATION]

Apache HTTP Server Version 2.0

+
+

Apache Module mod_rewrite

+ + + + +
+ + + + + + + + + + + + + +
Description: +Provides a rule-based rewriting engine to rewrite requested +URLs on the fly +
Status:Extension
Module Identifier:rewrite_module
Compatibility: +Available in Apache 1.3 and later +
+
+

Summary

+ + +
+ +``The great thing about mod_rewrite is it gives you all the configurability and flexibility of Sendmail. The downside to mod_rewrite is that it gives you all the configurability and flexibility of Sendmail.'' -
- -- Brian Behlendorf
+ +
+ -- Brian Behlendorf
Apache Group
-
-
-
+ +
-
-
-
- `` Despite the tons of examples and docs, + +
+ +`` Despite the tons of examples and docs, mod_rewrite is voodoo. Damned cool voodoo, but still voodoo. '' -
- -- Brian Moore
+ +
+ -- Brian Moore
bem@news.cmc.net
-
-
-
- Welcome to mod_rewrite, the Swiss Army Knife of URL - manipulation! + +
+ -

This module uses a rule-based rewriting engine (based on a + +

Welcome to mod_rewrite, the Swiss Army Knife of URL + manipulation!

+ + +

This module uses a rule-based rewriting engine (based on a regular-expression parser) to rewrite requested URLs on the fly. It supports an unlimited number of rules and an unlimited number of attached rule conditions for each rule to @@ -88,7 +91,8 @@ various formats can be used to achieve a really granular URL matching.

-

This module operates on the full URLs (including the + +

This module operates on the full URLs (including the path-info part) both in per-server context (httpd.conf) and per-directory context (.htaccess) and can even generate query-string @@ -96,83 +100,78 @@ sub-processing, external request redirection or even to an internal proxy throughput.

-

But all this functionality and flexibility has its + +

But all this functionality and flexibility has its drawback: complexity. So don't expect to understand this entire module in just one day.

-

This module was invented and originally written in April - 1996
- and gifted exclusively to the The Apache Group in July 1997 + +

This module was invented and originally written in April + 1996 and gifted exclusively to the The Apache Group in July 1997 by

-
- Ralf S. - Engelschall
- rse@engelschall.com
- www.engelschall.com -
-
- -

Table Of Contents

- -

Internal Processing

- - - -

Configuration Directives

- - - Miscellaneous - - -
- -
-

Internal - Processing

-
-
- -

The internal processing of this module is very complex but + +

+ +Ralf S. + Engelschall +
+ +rse@engelschall.com +
+ +www.engelschall.com + +
+ + +

Directives

+ +

+Interal Processing +

+ + +

The internal processing of this module is very complex but needs to be explained once even to the average user to avoid common mistakes and to let you exploit its full functionality.

-

API - Phases

-

First you have to understand that when Apache processes a +

+API Phases +

+ + +

First you have to understand that when Apache processes a HTTP request it does this in phases. A hook for each of these phases is provided by the Apache API. Mod_rewrite uses two of these hooks: the URL-to-filename translation hook which is @@ -182,7 +181,8 @@ config files (.htaccess) have been read, but before the content handler is activated.

-

So, after a request comes in and Apache has determined the + +

So, after a request comes in and Apache has determined the corresponding server (or virtual server) the rewriting engine starts processing of all mod_rewrite directives from the per-server configuration in the URL-to-filename phase. A few @@ -196,8 +196,10 @@ mod_rewrite can operate. To make this point more clear remember the following two points:

-
    -
  1. Although mod_rewrite rewrites URLs to URLs, URLs to + +
      + +
    1. Although mod_rewrite rewrites URLs to URLs, URLs to filenames and even filenames to filenames, the API currently provides only a URL-to-filename hook. In Apache 2.0 the two missing hooks will be added to make the @@ -206,7 +208,8 @@ Apache does more in the URL-to-filename hook than the API intends for it.
    2. -
    3. + +
    4. Unbelievably mod_rewrite provides URL manipulations in per-directory context, i.e., within .htaccess files, although these are reached @@ -233,14 +236,22 @@ egg problem. But on the other hand this is the only way mod_rewrite can provide (locally restricted) URL manipulations to the average user.

      -
    5. -
    + +
  2. + +
+ + +

Don't forget these two points!

-

Don't forget these two points!

-

Ruleset - Processing

- Now when mod_rewrite is triggered in these two API phases, it + +

+Ruleset Processing +

+ + +

Now when mod_rewrite is triggered in these two API phases, it reads the configured rulesets from its configuration structure (which itself was either created on startup for per-server context or during the directory walk of the Apache @@ -249,35 +260,44 @@ rules together with their conditions). The operation of the URL rewriting engine itself is exactly the same for both configuration contexts. Only the final result processing is - different. + different.

-

The order of rules in the ruleset is important because the + +

The order of rules in the ruleset is important because the rewriting engine processes them in a special (and not very obvious) order. The rule is this: The rewriting engine loops - through the ruleset rule by rule (RewriteRule - directives) and when a particular rule matches it optionally - loops through existing corresponding conditions - (RewriteCond directives). For historical reasons - the conditions are given first, and so the control flow is a - little bit long-winded. See Figure 1 for more details.

- -
- - - - - - - - -
[Needs graphics capability to display]
Figure 1: The - control flow through the rewriting ruleset
-
+ through the ruleset rule by rule (RewriteRule directives) and + when a particular rule matches it optionally loops through + existing corresponding conditions (RewriteCond + directives). For historical reasons the conditions are given + first, and so the control flow is a little bit long-winded. See + Figure 1 for more details.

+ + +
+ + + + + + + + -

As you can see, first the URL is matched against the + +

+ + + + + +
[Needs graphics capability to display]
Figure 1: The + control flow through the rewriting ruleset
+ +
+ + +

As you can see, first the URL is matched against the Pattern of each rule. When it fails mod_rewrite immediately stops processing this rule and continues with the next rule. If the Pattern matches, mod_rewrite looks @@ -298,10 +318,15 @@ with the substitution of the URL with Substitution.

-

Quoting Special - Characters

-

As of Apache 1.3.20, special characters in + + +

+Quoting Special Characters +

+ + +

As of Apache 1.3.20, special characters in TestString and Substitution strings can be escaped (that is, treated as normal characters without their usual special meaning) by prefixing them with a slosh ('\') @@ -310,675 +335,247 @@ using '\$'; this keeps mod_rewrite from trying to treat it as a backreference.

-

Regex - Back-Reference Availability

- One important thing here has to be remembered: Whenever you + + +

+Regex Back-Reference Availability +

+ + +

One important thing here has to be remembered: Whenever you use parentheses in Pattern or in one of the CondPattern, back-references are internally created which can be used with the strings $N and %N (see below). These are available for creating the strings Substitution and TestString. Figure 2 shows to which locations the back-references are - transfered for expansion. - -

- - - - - - - - -
[Needs graphics capability to display]
Figure 2: The - back-reference flow through a rule
-
+ transfered for expansion.

+ + +
+ + + + + + + + -

We know this was a crash course on mod_rewrite's internal + +

+ + + + + +
[Needs graphics capability to display]
Figure 2: The + back-reference flow through a rule
+ +
+ + +

We know this was a crash course on mod_rewrite's internal processing. But you will benefit from this knowledge when reading the following documentation of the available directives.

-
- -
-

Configuration Directives

-
-
- -

RewriteEngine

- Syntax: RewriteEngine - on|off
- Default: RewriteEngine - off
- Context: server config, - virtual host, directory, .htaccess
- Override: FileInfo
- Status: Extension
- Module: mod_rewrite.c
- Compatibility: Apache - 1.2
- - -

The RewriteEngine directive enables or - disables the runtime rewriting engine. If it is set to - off this module does no runtime processing at - all. It does not even update the SCRIPT_URx - environment variables.

- -

Use this directive to disable the module instead of - commenting out all the RewriteRule - directives!

- -

Note that, by default, rewrite configurations are not - inherited. This means that you need to have a - RewriteEngine on directive for each virtual host - in which you wish to use it.

-
- -

RewriteOptions

- Syntax: RewriteOptions - Option
- Default: None
- Context: server config, - virtual host, directory, .htaccess
- Override: FileInfo
- Status: Extension
- Module: mod_rewrite.c
- Compatibility: Apache - 1.2
- -

The RewriteOptions directive sets some - special options for the current per-server or per-directory - configuration. The Option strings can be one of the - following:

-
    -
  • 'inherit'
    - This forces the current configuration to inherit the - configuration of the parent. In per-virtual-server context - this means that the maps, conditions and rules of the main - server are inherited. In per-directory context this means - that conditions and rules of the parent directory's - .htaccess configuration are inherited.
  • -
-
- -

RewriteLog

- Syntax: RewriteLog - file-path
- Default: None
- Context: server config, - virtual host
- Override: Not - applicable
- Status: Extension
- Module: mod_rewrite.c
- Compatibility: Apache - 1.2
- -

The RewriteLog directive sets the name of the - file to which the server logs any rewriting actions it - performs. If the name does not begin with a slash - ('/') then it is assumed to be relative to the - Server Root. The directive should occur only once - per server config.

+

+Environment Variables +

- - - - -
Note: To disable the logging of - rewriting actions it is not recommended to set - Filename to /dev/null, because - although the rewriting engine does not then output to a - logfile it still creates the logfile output internally. - This will slow down the server with no advantage - to the administrator! To disable logging either - remove or comment out the RewriteLog - directive or use RewriteLogLevel 0!
- - - - - -
Security: See the Apache 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.
- -

Example:

- -
-
-RewriteLog "/usr/local/var/apache/logs/rewrite.log"
-
-
-
- -

RewriteLogLevel

- Syntax: RewriteLogLevel - Level
- Default: - RewriteLogLevel 0
- Context: server config, - virtual host
- Override: Not - applicable
- Status: Extension
- Module: mod_rewrite.c
- Compatibility: Apache - 1.2
- + +

This module keeps track of two additional (non-standard) + CGI/SSI environment variables named SCRIPT_URL + and SCRIPT_URI. These contain the + logical Web-view to the current resource, while the + standard CGI/SSI variables SCRIPT_NAME and + SCRIPT_FILENAME contain the physical + System-view.

-

The RewriteLogLevel directive sets the - verbosity level of the rewriting logfile. The default level 0 - means no logging, while 9 or more means that practically all - actions are logged.

+ +

Notice: These variables hold the URI/URL as they were + initially requested, i.e., before any + rewriting. This is important because the rewriting process is + primarily used to rewrite logical URLs to physical + pathnames.

-

To disable the logging of rewriting actions simply set - Level to 0. This disables all rewrite action - logs.

+ +

+Example: +

- - - - -
Notice: Using a high value for - Level will slow down your Apache server - dramatically! Use the rewriting logfile at a - Level greater than 2 only for debugging!
-

Example:

+
+ + + + +
-
-RewriteLogLevel 3
+SCRIPT_NAME=/sw/lib/w3s/tree/global/u/rse/.www/index.html
+SCRIPT_FILENAME=/u/rse/.www/index.html
+SCRIPT_URL=/u/rse/
+SCRIPT_URI=http://en1.engelschall.com/u/rse/
 
-
-
- -

RewriteLock

- Syntax: RewriteLock - file-path
- Default: None
- Context: server config
- Override: Not - applicable
- Status: Extension
- Module: mod_rewrite.c
- Compatibility: Apache - 1.3
- -

This directive sets the filename for a synchronization - lockfile which mod_rewrite needs to communicate with - RewriteMap programs. Set this lockfile - to a local path (not on a NFS-mounted device) when you want - to use a rewriting map-program. It is not required for other - types of rewriting maps.

-
- -

RewriteMap

- Syntax: RewriteMap - MapName MapType:MapSource
- Default: not used per - default
- Context: server config, - virtual host
- Override: Not - applicable
- Status: Extension
- Module: mod_rewrite.c
- Compatibility: Apache 1.2 - (partially), Apache 1.3
- +
+
-

The RewriteMap directive defines a - Rewriting Map which can be used inside rule - substitution strings by the mapping-functions to - insert/substitute fields through a key lookup. The source of - this lookup can be of various types.

-

The MapName is - the name of the map and will be used to specify a - mapping-function for the substitution strings of a rewriting - rule via one of the following constructs:

+

+Practical Solutions +

-
- ${ MapName : - LookupKey }
- ${ MapName : - LookupKey | DefaultValue - }
-
- When such a construct occurs the map MapName is - consulted and the key LookupKey is looked-up. If the - key is found, the map-function construct is substituted by - SubstValue. If the key is not found then it is - substituted by DefaultValue or by the empty string - if no DefaultValue was specified. + +

We also have an URL + Rewriting Guide available, which provides a collection of + practical solutions for URL-based problems. There you can + find real-life rulesets and additional information about + mod_rewrite.

+ +
+

+RewriteBase Directive +

+ + + + +
+ + + + + + + + + + + + + + + + + + + + + + +
Description: Sets the base URL for per-directory rewrites
Syntax: +RewriteBase URL-path + +
Default:RewriteBase physical-directory-path
Context:directory, .htaccess
Override:FileInfo
Status:Extension
Module:mod_rewrite
+
+ + +

The RewriteBase directive explicitly + sets the base URL for per-directory rewrites. As you will see + below, RewriteRule + can be used in per-directory config files + (.htaccess). There it will act locally, + i.e., the local directory prefix is stripped at this + stage of processing and your rewriting rules act only on the + remainder. At the end it is automatically added back to the + path.

-

The following combinations for MapType and - MapSource can be used:

+ +

When a substitution occurs for a new URL, this module has + to re-inject the URL into the server processing. To be able + to do this it needs to know what the corresponding URL-prefix + or URL-base is. By default this prefix is the corresponding + filepath itself. But at most websites URLs are NOT + directly related to physical filename paths, so this + assumption will usually be wrong! There you have to + use the RewriteBase directive to specify the + correct URL-prefix.

-
    -
  • - Standard Plain Text
    - MapType: txt, MapSource: Unix filesystem - path to valid regular file -

    This is the standard rewriting map feature where the - MapSource is a plain ASCII file containing - either blank lines, comment lines (starting with a '#' - character) or pairs like the following - one per - line.

    +
    + + + + +
    If your webserver's URLs are not directly +related to physical file paths, you have to use +RewriteBase in every .htaccess +files where you want to use RewriteRule directives. +
    +
    -
    - MatchingKey - SubstValue -
    + +

    For example, assume the following per-directory config file:

    -

    Example:

    - - - + +
    -
    -##
    -##  map.txt -- rewriting map
    -##
    +
    + + + - -
    -Ralf.S.Engelschall rse # Bastard Operator From Hell -Mr.Joe.Average joe # Mr. Average - -
    - - - - - -
    -RewriteMap real-to-user txt:/path/to/file/map.txt
    -
    -
    - - -
  • - Randomized Plain Text
    - MapType: rnd, MapSource: Unix filesystem - path to valid regular file +# +# /abc/def/.htaccess -- per-dir config file for directory /abc/def +# Remember: /abc/def is the physical path of /xyz, i.e., the server +# has a 'Alias /xyz /abc/def' directive e.g. +# -

    This is identical to the Standard Plain Text variant - above but with a special post-processing feature: After - looking up a value it is parsed according to contained - ``|'' characters which have the meaning of - ``or''. In other words they indicate a set of - alternatives from which the actual returned value is - chosen randomly. Although this sounds crazy and useless, - it was actually designed for load balancing in a reverse - proxy situation where the looked up values are server - names. Example:

    +RewriteEngine On - - - - -
    -
    -##
    -##  map.txt -- rewriting map
    -##
    +#  let the server know that we were reached via /xyz and not
    +#  via the physical path prefix /abc/def
    +RewriteBase   /xyz
     
    -static   www1|www2|www3|www4
    -dynamic  www5|www6
    -
    -
    - - - - - -
    -
    -RewriteMap servers rnd:/path/to/file/map.txt
    +#  now the rewriting rules
    +RewriteRule   ^oldstuff\.html$  newstuff.html
     
    -
    -
  • - -
  • - Hash File
    - MapType: dbm, MapSource: Unix filesystem - path to valid regular file - -

    Here the source is a binary NDBM format file - containing the same contents as a Plain Text - format file, but in a special representation which is - optimized for really fast lookups. You can create such a - file with any NDBM tool or with the following Perl - script:

    - - - + +
    -
    -#!/path/to/bin/perl
    -##
    -##  txt2dbm -- convert txt map to dbm format
    -##
    +
    +
  • -use NDBM_File; -use Fcntl; + +

    In the above example, a request to + /xyz/oldstuff.html gets correctly rewritten to + the physical file /abc/def/newstuff.html.

    -($txtmap, $dbmmap) = @ARGV; -open(TXT, "<$txtmap") or die "Couldn't open $txtmap!\n"; -tie (%DB, 'NDBM_File', $dbmmap,O_RDWR|O_TRUNC|O_CREAT, 0644) or die "Couldn't create $dbmmap!\n"; +
    + + + - -
    +

    +For Apache Hackers +

    -while (<TXT>) { - next if (/^\s*#/ or /^\s*$/); - $DB{$1} = $2 if (/^\s*(\S+)\s+(\S+)/); -} +

    The following list gives detailed information about + the internal processing steps:

    -untie %DB; -close(TXT); - -
    - - - - - -
    -$ txt2dbm map.txt map.db
    -
    -
    - - -
  • - Internal Function
    - MapType: int, MapSource: Internal Apache - function - -

    Here the source is an internal Apache function. - Currently you cannot create your own, but the following - functions already exists:

    - -
      -
    • toupper:
      - Converts the looked up key to all upper case.
    • -
    • tolower:
      - Converts the looked up key to all lower case.
    • +Request: + /xyz/oldstuff.html -
    • escape:
      - Translates special characters in the looked up key to - hex-encodings.
    • +Internal Processing: + /xyz/oldstuff.html -> /abc/def/oldstuff.html (per-server Alias) + /abc/def/oldstuff.html -> /abc/def/newstuff.html (per-dir RewriteRule) + /abc/def/newstuff.html -> /xyz/newstuff.html (per-dir RewriteBase) + /xyz/newstuff.html -> /abc/def/newstuff.html (per-server Alias) -
    • unescape:
      - Translates hex-encodings in the looked up key back to - special characters.
    • -
    -
  • +Result: + /abc/def/newstuff.html + -
  • - External Rewriting Program
    - MapType: prg, MapSource: Unix filesystem - path to valid regular file - -

    Here the source is a program, not a map file. To - create it you can use the language of your choice, but - the result has to be a executable (i.e., either - object-code or a script with the magic cookie trick - '#!/path/to/interpreter' as the first - line).

    - -

    This program is started once at startup of the Apache - servers and then communicates with the rewriting engine - over its stdin and stdout - file-handles. For each map-function lookup it will - receive the key to lookup as a newline-terminated string - on stdin. It then has to give back the - looked-up value as a newline-terminated string on - stdout or the four-character string - ``NULL'' if it fails (i.e., there - is no corresponding value for the given key). A trivial - program which will implement a 1:1 map (i.e., - key == value) could be:

    - - - - - -
    -
    -#!/usr/bin/perl
    -$| = 1;
    -while (<STDIN>) {
    -    # ...put here any transformations or lookups...
    -    print $_;
    -}
     
    -
    - -

    But be very careful:
    -

    - -
      -
    1. ``Keep it simple, stupid'' (KISS), because - if this program hangs it will hang the Apache server - when the rule occurs.
    2. - -
    3. Avoid one common mistake: never do buffered I/O on - stdout! This will cause a deadloop! Hence - the ``$|=1'' in the above example...
    4. - -
    5. Use the RewriteLock directive to - define a lockfile mod_rewrite can use to synchronize - the communication to the program. By default no such - synchronization takes place.
    6. -
    -
  • - - The RewriteMap directive can occur more than - once. For each mapping-function use one - RewriteMap directive to declare its rewriting - mapfile. While you cannot declare a map in - per-directory context it is of course possible to - use this map in per-directory context. - - - - - -
    Note: For plain text and DBM format - files the looked-up keys are cached in-core until the - mtime of the mapfile changes or the server - does a restart. This way you can have map-functions in - rules which are used for every request. - This is no problem, because the external lookup only - happens once!
    -
    - -

    RewriteBase

    - Syntax: RewriteBase - URL-path
    - Default: default is the - physical directory path
    - Context: directory, - .htaccess
    - Override: - FileInfo
    - Status: Extension
    - Module: mod_rewrite.c
    - Compatibility: Apache - 1.2
    - - -

    The RewriteBase directive explicitly sets the - base URL for per-directory rewrites. As you will see below, - RewriteRule can be used in per-directory config - files (.htaccess). There it will act locally, - i.e., the local directory prefix is stripped at this - stage of processing and your rewriting rules act only on the - remainder. At the end it is automatically added back to the - path.

    - -

    When a substitution occurs for a new URL, this module has - to re-inject the URL into the server processing. To be able - to do this it needs to know what the corresponding URL-prefix - or URL-base is. By default this prefix is the corresponding - filepath itself. But at most websites URLs are NOT - directly related to physical filename paths, so this - assumption will usually be wrong! There you have to - use the RewriteBase directive to specify the - correct URL-prefix.

    - - - - - -
    Notice: If your webserver's URLs are - not directly related to physical file - paths, you have to use RewriteBase in every - .htaccess files where you want to use - RewriteRule directives.
    - -

    Example:

    - -
    - Assume the following per-directory config file: - - - - - -
    -
    -#
    -#  /abc/def/.htaccess -- per-dir config file for directory /abc/def
    -#  Remember: /abc/def is the physical path of /xyz, i.e., the server
    -#            has a 'Alias /xyz /abc/def' directive e.g.
    -#
    -
    -RewriteEngine On
    -
    -#  let the server know that we were reached via /xyz and not
    -#  via the physical path prefix /abc/def
    -RewriteBase   /xyz
    -
    -#  now the rewriting rules
    -RewriteRule   ^oldstuff\.html$  newstuff.html
    -
    -
    - -

    In the above example, a request to - /xyz/oldstuff.html gets correctly rewritten to - the physical file /abc/def/newstuff.html.

    - - - - - -
    - Note - For Apache - hackers:
    - The following list gives detailed information about - the internal processing steps:
    -
    -Request:
    -  /xyz/oldstuff.html
    -
    -Internal Processing:
    -  /xyz/oldstuff.html     -> /abc/def/oldstuff.html  (per-server Alias)
    -  /abc/def/oldstuff.html -> /abc/def/newstuff.html  (per-dir    RewriteRule)
    -  /abc/def/newstuff.html -> /xyz/newstuff.html      (per-dir    RewriteBase)
    -  /xyz/newstuff.html     -> /abc/def/newstuff.html  (per-server Alias)
    -
    -Result:
    -  /abc/def/newstuff.html
    -
    -
    - This seems very complicated but is + +

    +This seems very complicated but is the correct Apache internal processing, because the per-directory rewriting comes too late in the process. So, when it occurs the (rewritten) request @@ -988,53 +585,81 @@ Result: internally to the Apache server and the same procedure is used by many other operations inside Apache. So, you can be sure the design and - implementation is correct. -

    -
    -
    - -

    RewriteCond

    - Syntax: RewriteCond - TestString CondPattern
    - Default: None
    - Context: server config, - virtual host, directory, .htaccess
    - Override: - FileInfo
    - Status: Extension
    - Module: mod_rewrite.c
    - Compatibility: Apache 1.2 - (partially), Apache 1.3
    - - -

    The RewriteCond directive defines a rule - condition. Precede a RewriteRule directive with - one or more RewriteCond directives. The - following rewriting rule is only used if its pattern matches - the current state of the URI and if these - additional conditions apply too.

    - -

    TestString is a string which can contains the + implementation is correct. +

    + +
    +
+ + + +
+

+RewriteCond Directive +

+ + + + +
+ + + + + + + + + + + + + + + + + + + + + + +
Description: Defines a condition under which rewriting will take place +
Syntax: + RewriteCond + TestString CondPattern + +
Default:None
Context:server config, virtual host, directory, .htaccess
Override:FileInfo
Status:Extension
Module:mod_rewrite
+
+ + +

The RewriteCond directive defines a + rule condition. Precede a RewriteRule directive with one + or more RewriteCond directives. The following + rewriting rule is only used if its pattern matches the current + state of the URI and if these additional + conditions apply too.

+ + +

+TestString is a string which can contains the following expanded constructs in addition to plain text:

-
    -
  • - RewriteRule backreferences: These are + +
      + +
    • + +RewriteRule backreferences: These are backreferences of the form
      - $N -
      + +$N + +
(0 <= N <= 9) which provide access to the grouped parts (parenthesis!) of the pattern from the corresponding RewriteRule directive (the one @@ -1042,118 +667,164 @@ Result: directives). -
  • - RewriteCond backreferences: These are + +
  • + +RewriteCond backreferences: These are backreferences of the form
    - %N -
    + +%N + +
  • (1 <= N <= 9) which provide access to the grouped parts (parentheses!) of the pattern from the last matched RewriteCond directive in the current bunch of conditions. -
  • - RewriteMap expansions: These are + +
  • + +RewriteMap expansions: These are expansions of the form
    - ${mapname:key|default} -
    + +${mapname:key|default} + +
  • See the documentation for RewriteMap for more details. -
  • - Server-Variables: These are variables of + +
  • + +Server-Variables: These are variables of the form
    - %{ NAME_OF_VARIABLE + +%{ NAME_OF_VARIABLE } -
    + +
  • where NAME_OF_VARIABLE can be a string taken from the following list: - - + + + +

    +HTTP_USER_AGENT
    + HTTP_REFERER
    + HTTP_COOKIE
    + HTTP_FORWARDED
    + HTTP_HOST
    + HTTP_PROXY_CONNECTION
    + HTTP_ACCEPT
    + +
    +

    + + - - - - + + + + + + + + +

    +DOCUMENT_ROOT
    + SERVER_ADMIN
    + SERVER_NAME
    + SERVER_ADDR
    + SERVER_PORT
    + SERVER_PROTOCOL
    + SERVER_SOFTWARE
    + +
    +

    + + + +

    +TIME_YEAR
    + TIME_MON
    + TIME_DAY
    + TIME_HOUR
    + TIME_MIN
    + TIME_SEC
    + TIME_WDAY
    + TIME
    + +
    +

    + + - -
    + +
    HTTP headers: -

    HTTP_USER_AGENT
    - HTTP_REFERER
    - HTTP_COOKIE
    - HTTP_FORWARDED
    - HTTP_HOST
    - HTTP_PROXY_CONNECTION
    - HTTP_ACCEPT
    -

    -
    connection & request: -

    REMOTE_ADDR
    - REMOTE_HOST
    - REMOTE_USER
    - REMOTE_IDENT
    - REQUEST_METHOD
    - SCRIPT_FILENAME
    - PATH_INFO
    - QUERY_STRING
    - AUTH_TYPE
    -

    -
    + +

    +REMOTE_ADDR
    + REMOTE_HOST
    + REMOTE_USER
    + REMOTE_IDENT
    + REQUEST_METHOD
    + SCRIPT_FILENAME
    + PATH_INFO
    + QUERY_STRING
    + AUTH_TYPE
    + +
    +

    + +
    server internals: -

    DOCUMENT_ROOT
    - SERVER_ADMIN
    - SERVER_NAME
    - SERVER_ADDR
    - SERVER_PORT
    - SERVER_PROTOCOL
    - SERVER_SOFTWARE
    -

    -
    system stuff: -

    TIME_YEAR
    - TIME_MON
    - TIME_DAY
    - TIME_HOUR
    - TIME_MIN
    - TIME_SEC
    - TIME_WDAY
    - TIME
    -

    -
    specials: -

    API_VERSION
    - THE_REQUEST
    - REQUEST_URI
    - REQUEST_FILENAME
    - IS_SUBREQ
    -

    -
    - - - - + + + +
    -

    Notice: These variables all + +

    +API_VERSION
    + THE_REQUEST
    + REQUEST_URI
    + REQUEST_FILENAME
    + IS_SUBREQ
    + +
    +

    + +
    + + +
    + + + - -
    + +

    These variables all correspond to the similarly named HTTP MIME-headers, C variables of the Apache server or struct tm fields of the Unix system. @@ -1161,18 +832,27 @@ Result: the CGI specification. Those that are special to mod_rewrite include:

    -
    -
    IS_SUBREQ
    + +
    + +
    +IS_SUBREQ +
    -
    Will contain the text "true" if the request + +
    Will contain the text "true" if the request currently being processed is a sub-request, "false" otherwise. Sub-requests may be generated by modules that need to resolve additional files or URIs in order to complete their tasks.
    -
    API_VERSION
    + +
    +API_VERSION +
    -
    This is the version of the Apache module API + +
    This is the version of the Apache module API (the internal interface between server and module) in the current httpd build, as defined in include/ap_mmn.h. The module API version @@ -1181,35 +861,55 @@ Result: instance, it is 19990320:10), but is mainly of interest to module authors.
    -
    THE_REQUEST
    + +
    +THE_REQUEST +
    -
    The full HTTP request line sent by the + +
    The full HTTP request line sent by the browser to the server (e.g., "GET /index.html HTTP/1.1"). This does not include any additional headers sent by the browser.
    -
    REQUEST_URI
    + +
    +REQUEST_URI +
    -
    The resource requested in the HTTP request + +
    The resource requested in the HTTP request line. (In the example above, this would be "/index.html".)
    -
    REQUEST_FILENAME
    + +
    +REQUEST_FILENAME +
    -
    The full local filesystem path to the file or + +
    The full local filesystem path to the file or script matching the request.
    -
    -
    - - - -

    Special Notes:

    - -
      -
    1. The variables SCRIPT_FILENAME and REQUEST_FILENAME + + + + + + +
    + + + + + + +

    Special Notes:

    + + +
      + +
    1. The variables SCRIPT_FILENAME and REQUEST_FILENAME contain the same value, i.e., the value of the filename field of the internal request_rec structure of the Apache server. @@ -1218,235 +918,1027 @@ Result: REQUEST_URI (which contains the value of the uri field of request_rec).
    2. -
    3. There is the special format: + +
    4. There is the special format: %{ENV:variable} where variable can be any environment variable. This is looked-up via internal Apache structures and (if not found there) via getenv() from the Apache server process.
    5. -
    6. There is the special format: - %{HTTP:header} where header can be - any HTTP MIME-header name. This is looked-up from the HTTP - request. Example: %{HTTP:Proxy-Connection} is - the value of the HTTP header - ``Proxy-Connection:''.
    7. + +
    8. There is the special format: + %{HTTP:header} where header can be + any HTTP MIME-header name. This is looked-up from the HTTP + request. Example: %{HTTP:Proxy-Connection} is + the value of the HTTP header + ``Proxy-Connection:''.
    9. + + +
    10. There is the special format + %{LA-U:variable} for look-aheads which perform + an internal (URL-based) sub-request to determine the final + value of variable. Use this when you want to use a + variable for rewriting which is actually set later in an + API phase and thus is not available at the current stage. + For instance when you want to rewrite according to the + REMOTE_USER variable from within the + per-server context (httpd.conf file) you have + to use %{LA-U:REMOTE_USER} because this + variable is set by the authorization phases which come + after the URL translation phase where mod_rewrite + operates. On the other hand, because mod_rewrite implements + its per-directory context (.htaccess file) via + the Fixup phase of the API and because the authorization + phases come before this phase, you just can use + %{REMOTE_USER} there.
    11. + + +
    12. There is the special format: + %{LA-F:variable} which performs an internal + (filename-based) sub-request to determine the final value + of variable. Most of the time this is the same as + LA-U above.
    13. + +
    + + +

    +CondPattern is the condition pattern, + i.e., a regular expression which is applied to the + current instance of the TestString, i.e., + TestString is evaluated and then matched against + CondPattern.

    + + +

    +Remember: CondPattern is a + standard Extended Regular Expression with some + additions:

    + + +
      + +
    1. You can prefix the pattern string with a + '!' character (exclamation mark) to specify a + non-matching pattern.
    2. + + +
    3. + There are some special variants of CondPatterns. + Instead of real regular expression strings you can also + use one of the following: + +
        + +
      • '<CondPattern' (is lexically + lower)
        + Treats the CondPattern as a plain string and + compares it lexically to TestString. True if + TestString is lexically lower than + CondPattern.
      • + + +
      • '>CondPattern' (is lexically + greater)
        + Treats the CondPattern as a plain string and + compares it lexically to TestString. True if + TestString is lexically greater than + CondPattern.
      • + + +
      • '=CondPattern' (is lexically + equal)
        + Treats the CondPattern as a plain string and + compares it lexically to TestString. True if + TestString is lexically equal to + CondPattern, i.e the two strings are exactly + equal (character by character). If CondPattern + is just "" (two quotation marks) this + compares TestString to the empty string.
      • + + +
      • '-d' (is + directory)
        + Treats the TestString as a pathname and tests + if it exists and is a directory.
      • + + +
      • '-f' (is regular + file)
        + Treats the TestString as a pathname and tests + if it exists and is a regular file.
      • + + +
      • '-s' (is regular file with + size)
        + Treats the TestString as a pathname and tests + if it exists and is a regular file with size greater + than zero.
      • + + +
      • '-l' (is symbolic + link)
        + Treats the TestString as a pathname and tests + if it exists and is a symbolic link.
      • + + +
      • '-F' (is existing file via + subrequest)
        + Checks if TestString is a valid file and + accessible via all the server's currently-configured + access controls for that path. This uses an internal + subrequest to determine the check, so use it with care + because it decreases your servers performance!
      • + + +
      • '-U' (is existing URL via + subrequest)
        + Checks if TestString is a valid URL and + accessible via all the server's currently-configured + access controls for that path. This uses an internal + subrequest to determine the check, so use it with care + because it decreases your server's performance!
      • + +
      + + +
      + + + + +
      +

      +Notice +

      + All of these tests can + also be prefixed by an exclamation mark ('!') to + negate their meaning. +
      +
      + +
    4. + +
    + + +

    Additionally you can set special flags for + CondPattern by appending

    + + +
    + +[flags] + +
    + as the third argument to the RewriteCond + directive. Flags is a comma-separated list of the + following flags: + +
      + +
    • 'nocase|NC' + (no case)
      + This makes the test case-insensitive, i.e., there + is no difference between 'A-Z' and 'a-z' both in the + expanded TestString and the CondPattern. + This flag is effective only for comparisons between + TestString and CondPattern. It has no + effect on filesystem and subrequest checks.
    • + + +
    • + 'ornext|OR' + (or next condition)
      + Use this to combine rule conditions with a local OR + instead of the implicit AND. Typical example: + +
      + + + + +
      + +
      +RewriteCond %{REMOTE_HOST}  ^host1.*  [OR]
      +RewriteCond %{REMOTE_HOST}  ^host2.*  [OR]
      +RewriteCond %{REMOTE_HOST}  ^host3.*
      +RewriteRule ...some special stuff for any of these hosts...
      +
      + +
      +
      + + Without this flag you would have to write the cond/rule + three times. +
    • + +
    + + +

    +Example: +

    + + +

    To rewrite the Homepage of a site according to the + ``User-Agent:'' header of the request, you can + use the following:

    + + +
    + + + + +
    + +
    +RewriteCond  %{HTTP_USER_AGENT}  ^Mozilla.*
    +RewriteRule  ^/$                 /homepage.max.html  [L]
    +
    +RewriteCond  %{HTTP_USER_AGENT}  ^Lynx.*
    +RewriteRule  ^/$                 /homepage.min.html  [L]
    +
    +RewriteRule  ^/$                 /homepage.std.html  [L]
    +
    + +
    +
    + + +

    Interpretation: If you use Netscape Navigator as your + browser (which identifies itself as 'Mozilla'), then you + get the max homepage, which includes Frames, etc. + If you use the Lynx browser (which is Terminal-based), then + you get the min homepage, which contains no images, no + tables, etc. If you use any other browser you get + the standard homepage.

    + + +
    +
    +

    +RewriteEngine Directive +

    + + + + +
    + + + + + + + + + + + + + + + + + + + + + + +
    Description:
    Syntax: +RewriteEngine on|off +
    Default:RewriteEngine off
    Context:server config, virtual host, directory, .htaccess
    Override:FileInfo
    Status:Extension
    Module:mod_rewrite
    +
    + + + +

    The RewriteEngine directive enables or + disables the runtime rewriting engine. If it is set to + off this module does no runtime processing at + all. It does not even update the SCRIPT_URx + environment variables.

    + + +

    Use this directive to disable the module instead of + commenting out all the RewriteRule directives!

    + + +

    Note that, by default, rewrite configurations are not + inherited. This means that you need to have a + RewriteEngine on directive for each virtual host + in which you wish to use it.

    + +
    +
    +

    +RewriteLock Directive +

    + + + + +
    + + + + + + + + + + + + + + + + + + + +
    Description: Sets the name of the lock file used for RewriteMap +synchronization
    Syntax: +RewriteLock file-path + +
    Default:None
    Context:server config
    Status:Extension
    Module:mod_rewrite
    +
    + + +

    This directive sets the filename for a synchronization + lockfile which mod_rewrite needs to communicate with RewriteMap + programs. Set this lockfile to a local path (not on a + NFS-mounted device) when you want to use a rewriting + map-program. It is not required for other types of rewriting + maps.

    + +
    +
    +

    +RewriteLog Directive +

    + + + + +
    + + + + + + + + + + + + + + + + +
    Description: Sets the name of the file used for logging rewrite engine +processing
    Syntax: +RewriteLog file-path + +
    Context:server config, virtual host
    Status:Extension
    Module:mod_rewrite
    +
    + + +

    The RewriteLog directive sets the name + of the file to which the server logs any rewriting actions it + performs. If the name does not begin with a slash + ('/') then it is assumed to be relative to the + Server Root. The directive should occur only once per + server config.

    + + +
    + + + + +
    To disable the logging of + rewriting actions it is not recommended to set + Filename to /dev/null, because + although the rewriting engine does not then output to a + logfile it still creates the logfile output internally. + This will slow down the server with no advantage + to the administrator! To disable logging either + remove or comment out the RewriteLog + directive or use RewriteLogLevel 0! +
    +
    + + +
    + + + + +
    +

    +Security +

    + +See the Apache 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. +
    +
    + + +
    + + + + +
    +

    +Example +

    + +RewriteLog "/usr/local/var/apache/logs/rewrite.log" +
    +
    + + +
    +
    +

    +RewriteLogLevel Directive +

    + + + + +
    + + + + + + + + + + + + + + + + + + + +
    Description: Sets the verbosity of the log file used by the rewrite +engine
    Syntax: +RewriteLogLevel Level + +
    Default:RerwiteLogLevel 0
    Context:server config, virtual host
    Status:Extension
    Module:mod_rewrite
    +
    + + +

    The RewriteLogLevel directive sets the + verbosity level of the rewriting logfile. The default level 0 + means no logging, while 9 or more means that practically all + actions are logged.

    + + +

    To disable the logging of rewriting actions simply set + Level to 0. This disables all rewrite action + logs.

    + + +
    + + + + +
    Using a high value for + Level will slow down your Apache server + dramatically! Use the rewriting logfile at a + Level greater than 2 only for debugging! +
    +
    + + +
    + + + + +
    +

    +Example +

    + +RewriteLogLevel 3 +
    +
    + + +
    +
    +

    +RewriteMap Directive +

    + + + + +
    + + + + + + + + + + + + + + + + + + + +
    Description: Defines a mapping function for key-lookup
    Syntax: +RewriteMap MapName MapType:MapSource + + +
    Default:None
    Context:server config, virtual host
    Status:Extension
    Module:mod_rewrite
    +
    + + +

    The RewriteMap directive defines a + Rewriting Map which can be used inside rule + substitution strings by the mapping-functions to + insert/substitute fields through a key lookup. The source of + this lookup can be of various types.

    + + +

    The MapName is + the name of the map and will be used to specify a + mapping-function for the substitution strings of a rewriting + rule via one of the following constructs:

    + + +
    + +${ MapName : + LookupKey } +
    + +${ MapName : + LookupKey | DefaultValue + }
    + +
    + + +

    When such a construct occurs the map MapName is + consulted and the key LookupKey is looked-up. If the + key is found, the map-function construct is substituted by + SubstValue. If the key is not found then it is + substituted by DefaultValue or by the empty string + if no DefaultValue was specified.

    + + +

    The following combinations for MapType and + MapSource can be used:

    + + +
      + +
    • + +Standard Plain Text +
      + MapType: txt, MapSource: Unix filesystem + path to valid regular file + +

      This is the standard rewriting map feature where the + MapSource is a plain ASCII file containing + either blank lines, comment lines (starting with a '#' + character) or pairs like the following - one per + line.

      + + +
      + +MatchingKey + SubstValue + +
      + + +
      + + + + +
      +

      +Example +

      + + +
      +##
      +##  map.txt -- rewriting map
      +##
      +
      +Ralf.S.Engelschall    rse   # Bastard Operator From Hell
      +Mr.Joe.Average        joe   # Mr. Average
      +
      + +
      +
      + + +
      + + + + +
      +RewriteMap real-to-user txt:/path/to/file/map.txt +
      +
      + +
    • + + +
    • + +Randomized Plain Text +
      + MapType: rnd, MapSource: Unix filesystem + path to valid regular file + +

      This is identical to the Standard Plain Text variant + above but with a special post-processing feature: After + looking up a value it is parsed according to contained + ``|'' characters which have the meaning of + ``or''. In other words they indicate a set of + alternatives from which the actual returned value is + chosen randomly. Although this sounds crazy and useless, + it was actually designed for load balancing in a reverse + proxy situation where the looked up values are server + names. Example:

      + + +
      + + + + +
      + +
      +##
      +##  map.txt -- rewriting map
      +##
      +
      +static   www1|www2|www3|www4
      +dynamic  www5|www6
      +
      + +
      +
      + -
    • There is the special format - %{LA-U:variable} for look-aheads which perform - an internal (URL-based) sub-request to determine the final - value of variable. Use this when you want to use a - variable for rewriting which is actually set later in an - API phase and thus is not available at the current stage. - For instance when you want to rewrite according to the - REMOTE_USER variable from within the - per-server context (httpd.conf file) you have - to use %{LA-U:REMOTE_USER} because this - variable is set by the authorization phases which come - after the URL translation phase where mod_rewrite - operates. On the other hand, because mod_rewrite implements - its per-directory context (.htaccess file) via - the Fixup phase of the API and because the authorization - phases come before this phase, you just can use - %{REMOTE_USER} there.
    • +
      + + + + +
      +RewriteMap servers rnd:/path/to/file/map.txt +
      +
      + + + + +
    • + +Hash File +
      + MapType: dbm, MapSource: Unix filesystem + path to valid regular file -
    • There is the special format: - %{LA-F:variable} which performs an internal - (filename-based) sub-request to determine the final value - of variable. Most of the time this is the same as - LA-U above.
    • - +

      Here the source is a binary NDBM format file + containing the same contents as a Plain Text + format file, but in a special representation which is + optimized for really fast lookups. You can create such a + file with any NDBM tool or with the following Perl + script:

      -

      CondPattern is the condition pattern, - i.e., a regular expression which is applied to the - current instance of the TestString, i.e., - TestString is evaluated and then matched against - CondPattern.

      -

      Remember: CondPattern is a - standard Extended Regular Expression with some - additions:

      +
      + + + + +
      -
        -
      1. You can prefix the pattern string with a - '!' character (exclamation mark) to specify a - non-matching pattern.
      2. +
        +#!/path/to/bin/perl
        +##
        +##  txt2dbm -- convert txt map to dbm format
        +##
         
        -        
      3. - There are some special variants of CondPatterns. - Instead of real regular expression strings you can also - use one of the following: +use NDBM_File; +use Fcntl; -
          -
        • '<CondPattern' (is lexically - lower)
          - Treats the CondPattern as a plain string and - compares it lexically to TestString. True if - TestString is lexically lower than - CondPattern.
        • +($txtmap, $dbmmap) = @ARGV; -
        • '>CondPattern' (is lexically - greater)
          - Treats the CondPattern as a plain string and - compares it lexically to TestString. True if - TestString is lexically greater than - CondPattern.
        • +open(TXT, "<$txtmap") or die "Couldn't open $txtmap!\n"; +tie (%DB, 'NDBM_File', $dbmmap,O_RDWR|O_TRUNC|O_CREAT, 0644) or die "Couldn't create $dbmmap!\n"; -
        • '=CondPattern' (is lexically - equal)
          - Treats the CondPattern as a plain string and - compares it lexically to TestString. True if - TestString is lexically equal to - CondPattern, i.e the two strings are exactly - equal (character by character). If CondPattern - is just "" (two quotation marks) this - compares TestString to the empty string.
        • +while (<TXT>) { + next if (/^\s*#/ or /^\s*$/); + $DB{$1} = $2 if (/^\s*(\S+)\s+(\S+)/); +} -
        • '-d' (is - directory)
          - Treats the TestString as a pathname and tests - if it exists and is a directory.
        • +untie %DB; +close(TXT); +
      4. -
      5. '-f' (is regular - file)
        - Treats the TestString as a pathname and tests - if it exists and is a regular file.
      6. +
      +
      -
    • '-s' (is regular file with - size)
      - Treats the TestString as a pathname and tests - if it exists and is a regular file with size greater - than zero.
    • -
    • '-l' (is symbolic - link)
      - Treats the TestString as a pathname and tests - if it exists and is a symbolic link.
    • +
      + + + + +
      +$ txt2dbm map.txt map.db +
      +
      + + + + +
    • + +Internal Function +
      + MapType: int, MapSource: Internal Apache + function -
    • '-F' (is existing file via - subrequest)
      - Checks if TestString is a valid file and - accessible via all the server's currently-configured - access controls for that path. This uses an internal - subrequest to determine the check, so use it with care - because it decreases your servers performance!
    • +

      Here the source is an internal Apache function. + Currently you cannot create your own, but the following + functions already exists:

      -
    • '-U' (is existing URL via - subrequest)
      - Checks if TestString is a valid URL and - accessible via all the server's currently-configured - access controls for that path. This uses an internal - subrequest to determine the check, so use it with care - because it decreases your server's performance!
    • -
    + +
      + +
    • +toupper:
      + Converts the looked up key to all upper case.
    • - - - - -
      Notice: All of these tests can - also be prefixed by an exclamation mark ('!') to - negate their meaning.
      - - + +
    • +tolower:
      + Converts the looked up key to all lower case.
    • -

      Additionally you can set special flags for - CondPattern by appending

      + +
    • +escape:
      + Translates special characters in the looked up key to + hex-encodings.
    • -
      - [flags] -
      - as the third argument to the RewriteCond - directive. Flags is a comma-separated list of the - following flags: + +
    • +unescape:
      + Translates hex-encodings in the looked up key back to + special characters.
    • + +
    + + + + +
  • + +External Rewriting Program +
    + MapType: prg, MapSource: Unix filesystem + path to valid regular file -
      -
    • 'nocase|NC' - (no case)
      - This makes the test case-insensitive, i.e., there - is no difference between 'A-Z' and 'a-z' both in the - expanded TestString and the CondPattern. - This flag is effective only for comparisons between - TestString and CondPattern. It has no - effect on filesystem and subrequest checks.
    • +

      Here the source is a program, not a map file. To + create it you can use the language of your choice, but + the result has to be a executable (i.e., either + object-code or a script with the magic cookie trick + '#!/path/to/interpreter' as the first + line).

      -
    • - 'ornext|OR' - (or next condition)
      - Use this to combine rule conditions with a local OR - instead of the implicit AND. Typical example: + +

      This program is started once at startup of the Apache + servers and then communicates with the rewriting engine + over its stdin and stdout + file-handles. For each map-function lookup it will + receive the key to lookup as a newline-terminated string + on stdin. It then has to give back the + looked-up value as a newline-terminated string on + stdout or the four-character string + ``NULL'' if it fails (i.e., there + is no corresponding value for the given key). A trivial + program which will implement a 1:1 map (i.e., + key == value) could be:

      + + +
      + + + + +
      -
      -RewriteCond %{REMOTE_HOST}  ^host1.*  [OR]
      -RewriteCond %{REMOTE_HOST}  ^host2.*  [OR]
      -RewriteCond %{REMOTE_HOST}  ^host3.*
      -RewriteRule ...some special stuff for any of these hosts...
      +#!/usr/bin/perl
      +$| = 1;
      +while (<STDIN>) {
      +    # ...put here any transformations or lookups...
      +    print $_;
      +}
       
      -
      - Without this flag you would have to write the cond/rule - three times. - - -

      Example:

      +
      +
      -
      - To rewrite the Homepage of a site according to the - ``User-Agent:'' header of the request, you can - use the following: + +

      But be very careful:

      -
      -
      -RewriteCond  %{HTTP_USER_AGENT}  ^Mozilla.*
      -RewriteRule  ^/$                 /homepage.max.html  [L]
      +          
      +
        + +
      1. ``Keep it simple, stupid'' (KISS), because + if this program hangs it will hang the Apache server + when the rule occurs.
      2. -RewriteCond %{HTTP_USER_AGENT} ^Lynx.* -RewriteRule ^/$ /homepage.min.html [L] + +
      3. Avoid one common mistake: never do buffered I/O on + stdout! This will cause a deadloop! Hence + the ``$|=1'' in the above example...
      4. -RewriteRule ^/$ /homepage.std.html [L] -
      -
      - Interpretation: If you use Netscape Navigator as your - browser (which identifies itself as 'Mozilla'), then you - get the max homepage, which includes Frames, etc. - If you use the Lynx browser (which is Terminal-based), then - you get the min homepage, which contains no images, no - tables, etc. If you use any other browser you get - the standard homepage. -
      -
      - -

      RewriteRule

      - Syntax: RewriteRule - Pattern Substitution
      - Default: None
      - Context: server config, - virtual host, directory, .htaccess
      - Override: - FileInfo
      - Status: Extension
      - Module: mod_rewrite.c
      - Compatibility: Apache 1.2 - (partially), Apache 1.3
      - + +
    • Use the RewriteLock directive to + define a lockfile mod_rewrite can use to synchronize the + communication to the program. By default no such + synchronization takes place.
    • + + + + + +
    + The RewriteMap directive can occur more than + once. For each mapping-function use one + RewriteMap directive to declare its rewriting + mapfile. While you cannot declare a map in + per-directory context it is of course possible to + use this map in per-directory context. + +
    + + + + +
    +

    +Note +

    For plain text and DBM format files the +looked-up keys are cached in-core until the mtime of the +mapfile changes or the server does a restart. This way you can have +map-functions in rules which are used for every +request. This is no problem, because the external lookup only happens +once! +
    +
    + + + +
    +

    +RewriteOptions Directive +

    + + + + +
    + + + + + + + + + + + + + + + + + + + +
    Description: Sets some special options for the rewrite engine
    Syntax: +RewriteOptions Options + +
    Default:None
    Context:server config, virtual host, directory, .htaccess
    Status:Extension
    Module:mod_rewrite
    +
    + + + +

    The RewriteOptions directive sets some + special options for the current per-server or per-directory + configuration. The Option strings can be one of the + following:

    -

    The RewriteRule directive is the real + +

      + +
    • 'inherit'
      + This forces the current configuration to inherit the + configuration of the parent. In per-virtual-server context + this means that the maps, conditions and rules of the main + server are inherited. In per-directory context this means + that conditions and rules of the parent directory's + .htaccess configuration are inherited.
    • + +
    + +
    +
    +

    +RewriteRule Directive +

    + + + + +
    + + + + + + + + + + + + + + + + + + + + + + +
    Description: Defines rules for the rewriting engine
    Syntax: +RewriteRule + Pattern Substitution + +
    Default:None
    Context:server config, virtual host, directory, .htaccess
    Override:FileInfo
    Status:Extension
    Module:mod_rewrite
    +
    + + +

    The RewriteRule directive is the real rewriting workhorse. The directive can occur more than once. Each directive then defines one single rewriting rule. The definition order of these rules is important, because this order is used when applying the rules at run-time.

    -

    Pattern can + +

    +Pattern can be (for Apache 1.1.x a System V8 and for Apache 1.2.x and later a POSIX) regular expression which gets applied to the current URL. Here @@ -1455,12 +1947,18 @@ RewriteRule ^/$ /homepage.std.html [L] because any number of rules may already have matched and made alterations to it.

    -

    Some hints about the syntax of regular expressions:

    + +

    Some hints about the syntax of regular expressions:

    + + + + + + + + + + +
    - - - - -
    +
     Text:
       .           Any single character
       [chars]     Character class: One  of chars
    @@ -1486,11 +1984,15 @@ RewriteRule  ^/$                 /homepage.std.html  [L]
       \char       escape that particular char
                   (for instance to specify the chars ".[]()" etc.)
     
    -
    - -

    For more information about regular expressions either have + +

    + + +

    For more information about regular expressions either have a look at your local regex(3) manpage or its src/regex/regex.3 copy in the Apache 1.3 distribution. If you are interested in more detailed @@ -1498,15 +2000,20 @@ RewriteRule ^/$ /homepage.std.html [L] (POSIX regex, Perl regex, etc.) have a look at the following dedicated book on this topic:

    -
    - Mastering Regular Expressions
    - Jeffrey E.F. Friedl
    - Nutshell Handbook Series
    - O'Reilly & Associates, Inc. 1997
    - ISBN 1-56592-257-3
    -
    - -

    Additionally in mod_rewrite the NOT character + +

    + +Mastering Regular Expressions +
    + Jeffrey E.F. Friedl
    + Nutshell Handbook Series
    + O'Reilly & Associates, Inc. 1997
    + ISBN 1-56592-257-3
    + +
    + + +

    Additionally in mod_rewrite the NOT character ('!') is a possible pattern prefix. This gives you the ability to negate a pattern; to say, for instance: ``if the current URL does NOT match this @@ -1514,37 +2021,53 @@ RewriteRule ^/$ /homepage.std.html [L] it is easier to match the negative pattern, or as a last default rule.

    - - - + +
    Notice: When using the NOT character + +
    + + + - -
    +

    +Notice +

    +When using the NOT character to negate a pattern you cannot have grouped wildcard parts in the pattern. This is impossible because when the pattern does NOT match, there are no contents for the groups. In consequence, if negated patterns are used, you cannot use $N in the substitution - string!
    - -

    Substitution of a + string! +

    +
  • + + +

    +Substitution of a rewriting rule is the string which is substituted for (or replaces) the original URL for which Pattern matched. Beside plain text you can use

    -
      -
    1. back-references $N to the RewriteRule + +
        + +
      1. back-references $N to the RewriteRule pattern
      2. -
      3. back-references %N to the last matched + +
      4. back-references %N to the last matched RewriteCond pattern
      5. -
      6. server-variables as in rule condition test-strings + +
      7. server-variables as in rule condition test-strings (%{VARNAME})
      8. -
      9. mapping-function calls + +
      10. +mapping-function calls (${mapname:key|default})
      11. -
      + +
    Back-references are $N (N=0..9) identifiers which will be replaced by the contents of the Nth group of the @@ -1563,7 +2086,8 @@ RewriteRule ^/$ /homepage.std.html [L] unless explicitly terminated by a L flag - see below.

    -

    There is a special substitution string named + +

    There is a special substitution string named '-' which means: NO substitution! Sounds silly? No, it is useful to provide rewriting rules which only match @@ -1572,7 +2096,8 @@ RewriteRule ^/$ /homepage.std.html [L] able to have more than one pattern to be applied before a substitution occurs.

    -

    One more note: You can even create URLs in the + +

    One more note: You can even create URLs in the substitution string containing a query string part. Just use a question mark inside the substitution string to indicate that the following stuff should be re-injected into the @@ -1580,10 +2105,15 @@ RewriteRule ^/$ /homepage.std.html [L] string, end the substitution string with just the question mark.

    - - - + +
    Note: There is a special feature: + +
    + + + - -
    +

    +Note +

    +There is a special feature: When you prefix a substitution field with http://thishost[:thisport] then mod_rewrite automatically strips it @@ -1591,36 +2121,49 @@ RewriteRule ^/$ /homepage.std.html [L] URLs is a useful and important feature when used in combination with a mapping-function which generates the hostname part. Have a look at the first example in the - example section below to understand this.
    - - - - + +
    Remember: An unconditional external + example section below to understand this. +
    +
    + + +
    + + + - -
    +

    +Remember +

    + An unconditional external redirect to your own server will not work with the prefix http://thishost because of this feature. To achieve such a self-redirect, you have to use the - R-flag (see below).
    - -

    Additionally you can set special flags for + R-flag (see below). +

    +
    + + +

    Additionally you can set special flags for Substitution by appending

    -
    - [flags] -
    + +
    + +[flags] + +
    as the third argument to the RewriteRule directive. Flags is a comma-separated list of the following flags:
      -
    • + +
    • 'redirect|R - [=code]' (force redirect)
      + [=code]
      ' (force redirect)
      Prefix Substitution with http://thishost[:thisport]/ (which makes the new URL a URI) to force a external redirection. If no @@ -1633,10 +2176,12 @@ RewriteRule ^/$ /homepage.std.html [L] canonicalize the URL and give it back to the client, e.g., translate ``/~'' into ``/u/'' or always append a slash to - /u/user, etc.
      + /u/user, etc.
      -

      Note: When you use this flag, make + +

      +Note: When you use this flag, make sure that the substitution field is a valid URL! If not, you are redirecting to an invalid location! And remember that this flag itself only prefixes the URL with @@ -1644,36 +2189,38 @@ RewriteRule ^/$ /homepage.std.html [L] continues. Usually you also want to stop and do the redirection immediately. To stop the rewriting you also have to provide the 'L' flag.

      -
    • + + -
    • 'forbidden|F' (force URL - to be forbidden)
      + +
    • 'forbidden|F' (force URL + to be forbidden)
      This forces the current URL to be forbidden, i.e., it immediately sends back a HTTP response of 403 (FORBIDDEN). Use this flag in conjunction with appropriate RewriteConds to conditionally block some URLs.
    • -
    • 'gone|G' (force URL to be - gone)
      + +
    • 'gone|G' (force URL to be + gone)
      This forces the current URL to be gone, i.e., it immediately sends back a HTTP response of 410 (GONE). Use this flag to mark pages which no longer exist as gone.
    • -
    • + +
    • 'proxy|P' (force - proxy)
      + proxy)
      This flag forces the substitution part to be internally forced as a proxy request and immediately (i.e., - rewriting rule processing stops here) put through the proxy module. You have to make + rewriting rule processing stops here) put through the proxy module. You have to make sure that the substitution string is a valid URI (e.g., typically starting with http://hostname) which can be handled by the Apache proxy module. If not you get an error from the proxy module. Use this flag to achieve a - more powerful implementation of the ProxyPass directive, + more powerful implementation of the ProxyPass directive, to map some remote stuff into the namespace of the local server. @@ -1685,10 +2232,12 @@ RewriteRule ^/$ /homepage.std.html [L] available to mod_rewrite. If not, then you first have to rebuild the ``httpd'' program with mod_proxy enabled.

      -
    • + + -
    • 'last|L' - (last rule)
      + +
    • 'last|L' + (last rule)
      Stop the rewriting process here and don't apply any more rewriting rules. This corresponds to the Perl last command or the break command @@ -1698,20 +2247,24 @@ RewriteRule ^/$ /homepage.std.html [L] ('/') to a real one, e.g., '/e/www/'.
    • -
    • 'next|N' - (next round)
      + +
    • 'next|N' + (next round)
      Re-run the rewriting process (starting again with the first rewriting rule). Here the URL to match is again not the original URL but the URL from the last rewriting rule. This corresponds to the Perl next command or the continue command from the C language. Use this flag to restart the rewriting process, i.e., - to immediately go to the top of the loop.
      - But be careful not to create an infinite - loop!
    • - -
    • 'chain|C' - (chained with next rule)
      + to immediately go to the top of the loop.
      + +But be careful not to create an infinite + loop! +
    • + + +
    • 'chain|C' + (chained with next rule)
      This flag chains the current rule with the next rule (which itself can be chained with the following rule, etc.). This has the following effect: if a rule @@ -1723,9 +2276,10 @@ RewriteRule ^/$ /homepage.std.html [L] when you let an external redirect happen (where the ``.www'' part should not to occur!).
    • -
    • + +
    • 'type|T=MIME-type' - (force MIME type)
      + (force MIME type)
      Force the MIME-type of the target file to be MIME-type. For instance, this can be used to simulate the mod_alias directive @@ -1733,10 +2287,11 @@ RewriteRule ^/$ /homepage.std.html [L] inside the mapped directory to have a MIME type of ``application/x-httpd-cgi''.
    • -
    • + +
    • 'nosubreq|NS' (used only if no internal - sub-request)
      + sub-request)
      This flag forces the rewriting engine to skip a rewriting rule if the current request is an internal sub-request. For instance, sub-requests occur internally @@ -1745,35 +2300,40 @@ RewriteRule ^/$ /homepage.std.html [L] (index.xxx). On sub-requests it is not always useful and even sometimes causes a failure to if the complete set of rules are applied. Use this flag to - exclude some rules.
      + exclude some rules.
      -

      Use the following rule for your decision: whenever you + +

      Use the following rule for your decision: whenever you prefix some URLs with CGI-scripts to force them to be processed by the CGI-script, the chance is high that you will run into problems (or even overhead) on sub-requests. In these cases, use this flag.

      -
    • + + -
    • 'nocase|NC' - (no case)
      + +
    • 'nocase|NC' + (no case)
      This makes the Pattern case-insensitive, i.e., there is no difference between 'A-Z' and 'a-z' when Pattern is matched against the current URL.
    • -
    • 'qsappend|QSA' + +
    • 'qsappend|QSA' (query string - append)
      + append)
      This flag forces the rewriting engine to append a query string part in the substitution string to the existing one instead of replacing it. Use this when you want to add more data to the query string via a rewrite rule.
    • -
    • + +
    • 'noescape|NE' (no URI escaping of - output)
      + output)
      This flag keeps mod_rewrite from applying the usual URI escaping rules to the result of a rewrite. Ordinarily, special characters (such as '%', '$', ';', and so on) @@ -1781,27 +2341,25 @@ RewriteRule ^/$ /homepage.std.html [L] '%24', and '%3B', respectively); this flag prevents this from being done. This allows percent symbols to appear in the output, as in -
      +
      + + + + +
      RewriteRule /foo/(.*) /bar?arg=P1\%3d$1 [R,NE] - - +
      +
      + which would turn '/foo/zed' into a safe request for '/bar?arg=P1=zed'. - - - - - -
      Notice: The - noescape flag is only available with - Apache 1.3.20 and later versions.
    • -
    • + +
    • 'passthrough|PT' (pass through to next - handler)
      + handler)
      This flag forces the rewriting engine to set the uri field of the internal request_rec structure to the value of the @@ -1816,11 +2374,16 @@ RewriteRule ^/$ /homepage.std.html [L] engine of mod_rewrite and then /def to /ghi with mod_alias: -
      -    RewriteRule ^/abc(.*)  /def$1 [PT]
      +
      + + + + +
      + RewriteRule ^/abc(.*) /def$1 [PT]
      Alias /def /ghi - - +
      +
      If you omit the PT flag then mod_rewrite will do its job fine, i.e., it rewrites uri=/abc/... to @@ -1835,23 +2398,30 @@ RewriteRule ^/$ /homepage.std.html [L] is the use of mod_alias and mod_rewrite..

      - - - + +
      Note - For Apache - hackers:
      + +
      + + + - -
      +

      +For Apache hackers +

      If the current Apache API had a filename-to-filename hook additionally to the URI-to-filename hook then we wouldn't need this flag! But without such a hook this flag is the only solution. The Apache Group has discussed this problem and will add such a hook in - Apache version 2.0.
      - - -
    • 'skip|S=num' - (skip next rule(s))
      + Apache version 2.0. +
    • +
    + + + + +
  • 'skip|S=num' + (skip next rule(s))
    This flag forces the rewriting engine to skip the next num rules in sequence when the current rule matches. Use this to make pseudo if-then-else constructs: @@ -1860,9 +2430,10 @@ RewriteRule ^/$ /homepage.std.html [L] else-clause. (This is not the same as the 'chain|C' flag!)
  • -
  • + +
  • 'env|E=VAR:VAL' - (set environment variable)
    + (set environment variable)
    This forces an environment variable named VAR to be set to the value VAL, where VAL can contain regexp backreferences $N and @@ -1875,37 +2446,46 @@ RewriteRule ^/$ /homepage.std.html [L] it in a following RewriteCond pattern via %{ENV:VAR}. Use this to strip but remember information from URLs.
  • - - - - - + +
    - Note: Never forget that - Pattern is applied to a complete URL in - per-server configuration files. But in - per-directory configuration files, the per-directory - prefix (which always is the same for a specific - directory!) is automatically removed for the - pattern matching and automatically added after - the substitution has been done. This feature - is essential for many sorts of rewriting, because - without this prefix stripping you have to match the - parent directory which is not always possible. + + + + +
    + + + - -
    +

    +Note +

    Never forget that Pattern is +applied to a complete URL in per-server configuration +files. But in per-directory configuration files, the +per-directory prefix (which always is the same for a specific +directory!) is automatically removed for the pattern matching +and automatically added after the substitution has been +done. This feature is essential for many sorts of rewriting, +because without this prefix stripping you have to match the parent +directory which is not always possible.

    There is one exception: If a substitution string starts with ``http://'' then the directory prefix will not be added and an external redirect or proxy throughput (if flag P is used!) is forced!

    -
    - - - - + +
    Note: To enable the rewriting engine + +
    +
    + + +
    + + + - -
    +

    +Note +

    + To enable the rewriting engine for per-directory configuration files you need to set ``RewriteEngine On'' in these files and ``Options @@ -1913,23 +2493,35 @@ RewriteRule ^/$ /homepage.std.html [L] administrator has disabled override of FollowSymLinks for a user's directory, then you cannot use the rewriting engine. This restriction is - needed for security reasons.
    - -

    Here are all possible substitution combinations and their + needed for security reasons. +

    +
    + + +

    Here are all possible substitution combinations and their meanings:

    -

    Inside per-server configuration - (httpd.conf)
    + +

    +Inside per-server configuration + (httpd.conf)
    for request ``GET - /somepath/pathinfo'':

    -

    + /somepath/pathinfo
    '': +
    + +

    + + + + + + + + + + +
    - - - - -
    +
     Given Rule                                      Resulting Substitution
     ----------------------------------------------  ----------------------------------
     ^/somepath(.*) otherpath$1                      not supported, because invalid!
    @@ -1962,23 +2554,36 @@ RewriteRule  ^/$                 /homepage.std.html  [L]
     ^/somepath(.*) http://otherhost/otherpath$1 [P] http://otherhost/otherpath/pathinfo
                                                     via internal proxy
     
    -
    - -

    Inside per-directory configuration for - /somepath
    + +

    + + +

    +Inside per-directory configuration for + /somepath +
    (i.e., file .htaccess in dir /physical/path/to/somepath containing - RewriteBase /somepath)
    + RewriteBase /somepath)
    for request ``GET - /somepath/localpath/pathinfo'':

    -

    + /somepath/localpath/pathinfo
    '': +
    + +

    + + + + + + + + + + +
    - - - - -
    +
     Given Rule                                      Resulting Substitution
     ----------------------------------------------  ----------------------------------
     ^localpath(.*) otherpath$1                      /somepath/otherpath/pathinfo
    @@ -2012,85 +2617,65 @@ RewriteRule  ^/$                 /homepage.std.html  [L]
     ^localpath(.*) http://otherhost/otherpath$1 [P] http://otherhost/otherpath/pathinfo
                                                     via internal proxy
     
    -
    - -

    Example:

    - -
    - We want to rewrite URLs of the form - -
    - / Language /~ + +
    + + +

    +Example: +

    + + +

    We want to rewrite URLs of the form

    + + +
    + +/ Language /~ Realname /.../ File -
    + +
    into
    - /u/ Username /.../ + +/u/ Username /.../ File . Language -
    + + -

    We take the rewrite mapfile from above and save it under + +

    We take the rewrite mapfile from above and save it under /path/to/file/map.txt. Then we only have to add the following lines to the Apache server configuration file:

    -
    + +
    + + + + +
    +
     RewriteLog   /path/to/file/rewrite.log
     RewriteMap   real-to-user               txt:/path/to/file/map.txt
     RewriteRule  ^/([^/]+)/~([^/]+)/(.*)$   /u/${real-to-user:$2|nobody}/$3.$1
     
    - - -
    - -
    -

    Miscellaneous

    -
    -
    - -

    Environment - Variables

    - This module keeps track of two additional (non-standard) - CGI/SSI environment variables named SCRIPT_URL - and SCRIPT_URI. These contain the - logical Web-view to the current resource, while the - standard CGI/SSI variables SCRIPT_NAME and - SCRIPT_FILENAME contain the physical - System-view. - -

    Notice: These variables hold the URI/URL as they were - initially requested, i.e., before any - rewriting. This is important because the rewriting process is - primarily used to rewrite logical URLs to physical - pathnames.

    -

    Example:

    +
    +
    -
    -
    -SCRIPT_NAME=/sw/lib/w3s/tree/global/u/rse/.www/index.html
    -SCRIPT_FILENAME=/u/rse/.www/index.html
    -SCRIPT_URL=/u/rse/
    -SCRIPT_URI=http://en1.engelschall.com/u/rse/
    -
    -
    -
    -

    Practical - Solutions

    - We also have an URL - Rewriting Guide available, which provides a collection of - practical solutions for URL-based problems. There you can - find real-life rulesets and additional information about - mod_rewrite. -
    - - - + +
    +

    Apache HTTP Server Version 2.0

    +IndexHome + + - diff --git a/docs/manual/mod/mod_setenvif.html b/docs/manual/mod/mod_setenvif.html index 6716965bf7..3accd9b46a 100644 --- a/docs/manual/mod/mod_setenvif.html +++ b/docs/manual/mod/mod_setenvif.html @@ -1,338 +1,529 @@ - - - - - - - Apache module mod_setenvif - - - - - - -

    Module mod_setenvif

    - -

    This module provides the ability to set environment - variables based upon attributes of the request.

    - -

    Status: Base
    - Source File: - mod_setenvif.c
    - Module Identifier: - setenvif_module
    - Compatibility: Available in - Apache 1.3 and later.

    - -

    Summary

    - -

    The mod_setenvif module allows you to set + + + + +mod_setenvif - Apache HTTP Server + + + +

    +
    +[APACHE DOCUMENTATION]

    Apache HTTP Server Version 2.0

    +
    +

    Apache Module mod_setenvif

    + + + + +
    + + + + + + + + + + + + + +
    Description: +Allows the setting of environment variables based +on characteristics of the request +
    Status:Base
    Module Identifier:setenvif_module
    Compatibility: +Available in Apache 1.3 and later +
    +
    +

    Summary

    + + + +

    The mod_setenvif module allows you to set environment variables according to whether different aspects of the request match regular expressions you specify. These environment variables can be used by other parts of the server to make decisions about actions to be taken.

    -

    The directives are considered in the order they appear in + +

    The directives are considered in the order they appear in the configuration files. So more complex sequences can be used, such as this example, which sets netscape if the browser is mozilla but not MSIE.

    -
    -
    -  BrowserMatch ^Mozilla netscape
    -  BrowserMatch MSIE !netscape
    - 
    -
    -
    -
    -
    - - -

    For additional information, we provide a document on Environment Variables in Apache.

    - -

    Directives

    - - -
    - - -

    BrowserMatch - directive

    - -

    Syntax: BrowserMatch regex - env-variable[=value] - [env-variable[=value]] ...
    - Default: none
    - Context: server config, virtual - host, directory, .htaccess
    - Override: FileInfo
    - Status: Base
    - Module: mod_setenvif
    - Compatibility: Apache 1.2 and - above (in Apache 1.2 this directive was found in the - now-obsolete mod_browser module)

    - -

    The BrowserMatch directive defines environment variables - based on the User-Agent HTTP request header field. - The first argument should be a POSIX.2 extended regular - expression (similar to an egrep-style regex). The - rest of the arguments give the names of variables to set, and - optionally values to which they should be set. These take the - form of

    - -
      -
    1. varname, or
    2. -
    3. !varname, or
    4. - -
    5. varname=value
    6. -
    - -

    In the first form, the value will be set to "1". The second +

    + + + + +
    + BrowserMatch ^Mozilla netscape
    + BrowserMatch MSIE !netscape
    + +
    +
    + +
    +

    +See also: +

    + +

    Directives

    + +
    +

    +BrowserMatch Directive +

    + + + + +
    + + + + + + + + + + + + + + + + + + + + + + + + + +
    Description: Sets environment variables conditional on HTTP User-Agent +
    Syntax: +BrowserMatch regex env-variable[=value] +[env-variable[=value]] ... +
    Default:none
    Context:server config, virtual host, directory, .htaccess
    Override:FileInfo
    Status:Base
    Module:mod_setenvif
    Compatibility:Apache 1.2 and + above (in Apache 1.2 this directive was found in the + now-obsolete mod_browser module)
    +
    + + +

    The BrowserMatch directive defines + environment variables based on the User-Agent HTTP + request header field. The first argument should be a POSIX.2 + extended regular expression (similar to an + egrep-style regex). The rest of the arguments give + the names of variables to set, and optionally values to which they + should be set. These take the form of

    + + +
      + +
    1. +varname, or
    2. + + +
    3. +!varname, or
    4. + + +
    5. +varname=value +
    6. + +
    + + +

    In the first form, the value will be set to "1". The second will remove the given variable if already defined, and the third will set the variable to the value given by - value. If a User-Agent + value. If a User-Agent string matches more than one entry, they will be merged. Entries are processed in the order in which they appear, and later entries can override earlier ones.

    -

    For example:

    -
    -    BrowserMatch ^Mozilla forms jpeg=yes browser=netscape
    -    BrowserMatch "^Mozilla/[2-3]" tables agif frames javascript
    -    BrowserMatch MSIE !javascript
    +    
    +

    For example:

    + +
    + + + + +
    + BrowserMatch ^Mozilla forms jpeg=yes browser=netscape
    + BrowserMatch "^Mozilla/[2-3]" tables agif frames javascript
    + BrowserMatch MSIE !javascript
    + +
    +
    -
    - -

    Note that the regular expression string is + +

    Note that the regular expression string is case-sensitive. For case-INsensitive matching, - see the BrowserMatchNoCase + see the BrowserMatchNoCase directive.

    -

    The BrowserMatch and - BrowserMatchNoCase directives are special cases of - the SetEnvIf and SetEnvIfNoCase + +

    The BrowserMatch and + BrowserMatchNoCase directives are special cases of + the SetEnvIf and SetEnvIfNoCase directives. The following two lines have the same effect:

    -
    -   BrowserMatchNoCase Robot is_a_robot
    -   SetEnvIfNoCase User-Agent Robot is_a_robot
    - 
    -
    -
    - - -

    BrowserMatchNoCase directive

    - -

    Syntax: BrowserMatchNoCase - regex env-variable[=value] - [env-variable[=value]] ...
    - Default: none
    - Context: server config, virtual - host, directory, .htaccess
    - Override: FileInfo
    - Status: Base
    - Module: mod_setenvif
    - Compatibility: Apache 1.2 and - above (in Apache 1.2 this directive was found in the - now-obsolete mod_browser module)

    -

    The BrowserMatchNoCase directive is - semantically identical to the BrowserMatch directive. +

    + + + + +
    + BrowserMatchNoCase Robot is_a_robot
    + SetEnvIfNoCase User-Agent Robot is_a_robot
    + +
    +
    + +
    +
    +

    +BrowserMatchNoCase Directive +

    + + + + +
    + + + + + + + + + + + + + + + + + + + + + + + + + +
    Description: Sets environment variables conditional on User-Agent without +respect to case
    Syntax: +BrowserMatchNoCase regex env-variable[=value] + [env-variable[=value]] ... +
    Default:none
    Context:server config, virtual host, directory, .htaccess
    Override:FileInfo
    Status:Base
    Module:mod_setenvif
    Compatibility:Apache 1.2 and + above (in Apache 1.2 this directive was found in the + now-obsolete mod_browser module)
    +
    + + + +

    The BrowserMatchNoCase directive is + semantically identical to the BrowserMatch directive. However, it provides for case-insensitive matching. For example:

    -
    -    BrowserMatchNoCase mac platform=macintosh
    -    BrowserMatchNoCase win platform=windows
    - 
    -
    -

    The BrowserMatch and - BrowserMatchNoCase directives are special cases of - the SetEnvIf and SetEnvIfNoCase +

    + + + + +
    + BrowserMatchNoCase mac platform=macintosh
    + BrowserMatchNoCase win platform=windows
    + +
    +
    + + +

    The BrowserMatch and + BrowserMatchNoCase directives are special cases of + the SetEnvIf and SetEnvIfNoCase directives. The following two lines have the same effect:

    -
    -   BrowserMatchNoCase Robot is_a_robot
    -   SetEnvIfNoCase User-Agent Robot is_a_robot
    - 
    -
    -
    - - -

    SetEnvIf - directive

    -

    Syntax: SetEnvIf attribute +

    + + + + +
    + BrowserMatchNoCase Robot is_a_robot
    + SetEnvIfNoCase User-Agent Robot is_a_robot
    + +
    +
    + +
    +
    +

    +SetEnvIf Directive +

    + + + + +
    + + + + + + + + + + + + + + + + + + + + + + + + + +
    Description: Sets environment variables based on attributes of the request +
    Syntax: +SetEnvIf attribute regex env-variable[=value] - [env-variable[=value]] ...
    - Default: none
    - Context: server config, virtual - host, directory, .htaccess
    - Override: FileInfo
    - Status: Base
    - Module: mod_setenvif
    - Compatibility: Apache 1.3 and + [env-variable[=value]] ...
    +
    Default:none
    Context:server config, virtual host, directory, .htaccess
    Override:FileInfo
    Status:Base
    Module:mod_setenvif
    Compatibility:Apache 1.3 and above; the Request_Protocol keyword and environment-variable - matching are only available with 1.3.7 and later

    - -

    The SetEnvIf directive defines environment + matching are only available with 1.3.7 and later

    +
    + + +

    The SetEnvIf directive defines environment variables based on attributes of the request. These attributes - can be the values of various HTTP request header fields (see RFC2616 + can be the values of various HTTP request header fields (see RFC2616 for more information about these), or of other aspects of the request, including the following:

    -
      -
    • Remote_Host - the hostname (if available) of + +
        + +
      • +Remote_Host - the hostname (if available) of the client making the request
      • -
      • Remote_Addr - the IP address of the client + +
      • +Remote_Addr - the IP address of the client making the request
      • -
      • Remote_User - the authenticated username (if + +
      • +Remote_User - the authenticated username (if available)
      • -
      • Request_Method - the name of the method - being used (GET, POST, et + +
      • +Request_Method - the name of the method + being used (GET, POST, et cetera)
      • -
      • Request_Protocol - the name and version of + +
      • +Request_Protocol - the name and version of the protocol with which the request was made (e.g., "HTTP/0.9", "HTTP/1.1", etc.)
      • -
      • Request_URI - the portion of the URL + +
      • +Request_URI - the portion of the URL following the scheme and host portion
      • -
      + +
    -

    Some of the more commonly used request header field names - include Host, User-Agent, and - Referer.

    + +

    Some of the more commonly used request header field names + include Host, User-Agent, and + Referer.

    -

    If the attribute name doesn't match any of the + +

    If the attribute name doesn't match any of the special keywords, nor any of the request's header field names, it is tested as the name of an environment variable in the list of those associated with the request. This allows - SetEnvIf directives to test against the result of + SetEnvIf directives to test against the result of prior matches.

    -
    + +
    + + + + +
    Only those environment variables defined by earlier SetEnvIf[NoCase] directives are available for testing in this manner. 'Earlier' means that they were defined at a broader scope (such as server-wide) or previously in the current directive's scope. - - -

    attribute may be a regular expression when used to +

    +
    + + +

    +attribute may be a regular expression when used to match a request header. If attribute is a regular expression and it doesn't match any of the request's header names, then attribute is not tested against the request's environment variable list.

    -

    Example:

    -
    -   SetEnvIf Request_URI "\.gif$" object_is_image=gif
    -   SetEnvIf Request_URI "\.jpg$" object_is_image=jpg
    -   SetEnvIf Request_URI "\.xbm$" object_is_image=xbm
    -        :
    -   SetEnvIf Referer www\.mydomain\.com intra_site_referral
    -        :
    -   SetEnvIf object_is_image xbm XBIT_PROCESSING=1
    -        :
    -   SetEnvIf ^TS*  ^[a-z].*  HAVE_TS
    - 
    -
    -

    The first three will set the environment variable - object_is_image if the request was for an image - file, and the fourth sets intra_site_referral if +

    + + + + +
    +

    +Example: +

    + + + SetEnvIf Request_URI "\.gif$" object_is_image=gif
    + SetEnvIf Request_URI "\.jpg$" object_is_image=jpg
    + SetEnvIf Request_URI "\.xbm$" object_is_image=xbm
    + :
    + SetEnvIf Referer www\.mydomain\.com intra_site_referral
    + :
    + SetEnvIf object_is_image xbm XBIT_PROCESSING=1
    + :
    + SetEnvIf ^TS* ^[a-z].* HAVE_TS
    + +
    +
    + + +

    The first three will set the environment variable + object_is_image if the request was for an image + file, and the fourth sets intra_site_referral if the referring page was somewhere on the - www.mydomain.com Web site.

    + www.mydomain.com Web site.

    -

    The last example will set environment variable - HAVE_TS if the request contains any headers that + +

    The last example will set environment variable + HAVE_TS if the request contains any headers that begin with "TS" whose values begins with any character in the set [a-z].

    -
    - - -

    SetEnvIfNoCase - directive

    - -

    Syntax: SetEnvIfNoCase - attribute regex env-variable[=value] - [env-variable[=value]] ...
    - Default: none
    - Context: server config, virtual - host, directory, .htaccess
    - Override: FileInfo
    - Status: Base
    - Module: mod_setenvif
    - Compatibility: Apache 1.3 and - above

    - -

    The SetEnvIfNoCase is semantically identical to - the SetEnvIf directive, + + +


    +

    +SetEnvIfNoCase Directive +

    + + + + +
    + + + + + + + + + + + + + + + + + + + + + + + + + +
    Description: Sets environment variables based on attributes of the request +without respect to case
    Syntax: +SetEnvIfNoCase attribute regex env-variable[=value] + [env-variable[=value]] ... +
    Default:none
    Context:server config, virtual host, directory, .htaccess
    Override:FileInfo
    Status:Base
    Module:mod_setenvif
    Compatibility:Apache 1.3 and above
    +
    + + + +

    The SetEnvIfNoCase is semantically identical to + the SetEnvIf directive, and differs only in that the regular expression matching is performed in a case-insensitive manner. For example:

    -
    -   SetEnvIfNoCase Host Apache\.Org site=apache
    - 
    -
    -

    This will cause the site environment variable - to be set to "apache" if the HTTP request header - field Host: was included and contained - Apache.Org, apache.org, or any other +

    + + + + +
    + SetEnvIfNoCase Host Apache\.Org site=apache +
    +
    + + +

    This will cause the site environment variable + to be set to "apache" if the HTTP request header + field Host: was included and contained + Apache.Org, apache.org, or any other combination.

    - - - +
    +
    +

    Apache HTTP Server Version 2.0

    +IndexHome +
    + + diff --git a/docs/manual/mod/mod_status.html b/docs/manual/mod/mod_status.html index 5e07273384..0c18271b95 100644 --- a/docs/manual/mod/mod_status.html +++ b/docs/manual/mod/mod_status.html @@ -1,114 +1,170 @@ - - - - - - - Apache module mod_status - - - - - - -
    - Warning: This document has not been updated - to take into account changes made in the 2.0 version of the - Apache HTTP Server. Some of the information may still be - relevant, but please use it with care. -
    - -

    Module mod_status

    - -

    This module provides information on server activity and - performance.

    - -

    Status: Base
    - Source File: mod_status.c
    - Module Identifier: - status_module
    - Compatibility: Available in - Apache 1.1 and later.

    - -

    Summary

    - -

    The Status module allows a server administrator to find out + + + + +mod_status - Apache HTTP Server + + + +

    +
    +[APACHE DOCUMENTATION]

    Apache HTTP Server Version 2.0

    +
    +

    Apache Module mod_status

    + + + + +
    + + + + + + + + + + + + + +
    Description: +This module provides information on server activity and +performance. +
    Status:Base
    Module Identifier:status_module
    Compatibility: +Available in Apache 1.1 and later +
    +
    +

    Summary

    + + + +
    + + + + +
    + Warning: This document has not been updated + to take into account changes made in the 2.0 version of the + Apache HTTP Server. Some of the information may still be + relevant, but please use it with care. +
    +
    + + +

    The Status module allows a server administrator to find out how well their server is performing. A HTML page is presented that gives the current server statistics in an easily readable form. If required this page can be made to automatically refresh (given a compatible browser). Another page gives a simple machine-readable list of the current server state.

    -

    The details given are:

    + +

    The details given are:

    -
      -
    • The number of children serving requests
    • + +
        + +
      • The number of children serving requests
      • -
      • The number of idle children
      • + +
      • The number of idle children
      • -
      • The status of each child, the number of requests that + +
      • The status of each child, the number of requests that child has performed and the total number of bytes served by the child (*)
      • -
      • A total number of accesses and byte count served (*)
      • + +
      • A total number of accesses and byte count served (*)
      • -
      • The time the server was started/restarted and the time it + +
      • The time the server was started/restarted and the time it has been running for
      • -
      • Averages giving the number of requests per second, the + +
      • Averages giving the number of requests per second, the number of bytes served per second and the average number of bytes per request (*)
      • -
      • The current percentage CPU used by each child and in + +
      • The current percentage CPU used by each child and in total by Apache (*)
      • -
      • The current hosts and requests being processed (*)
      • -
      + +
    • The current hosts and requests being processed (*)
    • + +
    + A compile-time option must be used to display the details marked "(*)" as the instrumentation required for obtaining these statistics does not exist within standard Apache. +
    +

    Directives

    + +

    Enabling Status Support

    + -

    Directives

    - - - -

    Enabling Status Support

    To enable status reports only for browsers from the foo.com domain add this code to your httpd.conf configuration file -
    -    <Location /server-status>
    -    SetHandler server-status
    -
    -    Order Deny,Allow
    -    Deny from all
    -    Allow from .foo.com
    +
    + + + + +
    + <Location /server-status>
    + SetHandler server-status
    + +
    + Order Deny,Allow
    + Deny from all
    + Allow from .foo.com
    </Location> - +
    +
    -

    You can now access server statistics by using a Web browser + +

    You can now access server statistics by using a Web browser to access the page - http://your.server.name/server-status

    - -

    Note that mod_status will only work when you are running - Apache in standalone mode - and not inetd mode.

    - -

    Automatic Updates

    + http://your.server.name/server-status +

    + + +
    + + + + +
    +

    Note that mod_status will only work + when you are running Apache in standalone mode and not + inetd mode.

    +
    +
    + +

    Automatic Updates

    + + You can get the status page to update itself automatically if you have a browser that supports "refresh". Access the page http://your.server.name/server-status?refresh=N to refresh the page every N seconds. -

    Machine Readable Status File

    +

    Machine Readable Status File

    + + A machine-readable version of the status file is available by accessing the page http://your.server.name/server-status?auto. This @@ -117,41 +173,68 @@ log_server_status.
    - It should be noted that if mod_status is + + + + +
    + It should be noted that if mod_status is compiled into the server, its handler capability is available in all configuration files, including per-directory files (e.g., - .htaccess). This may have security-related + .htaccess). This may have security-related ramifications for your site. - -
    - -

    ExtendedStatus - directive

    - - Syntax: ExtendedStatus - On|Off
    - Default: ExtendedStatus - Off
    - Context: server config
    - Status: Base
    - Module: mod_status
    - Compatibility: ExtendedStatus - is only available in Apache 1.3.2 and later. - -

    This directive controls whether the server keeps track of - extended status information for each request. This is only - useful if the status module is enabled on the server.

    - -

    This setting applies to the entire server, and cannot be +

    +
    + + +
    +

    +ExtendedStatus Directive +

    + + + + +
    + + + + + + + + + + + + + + + + + + + + + + +
    Description: This directive controls whether the server keeps track of +extended status information for each request. This is only +useful if the status module is enabled on the server.
    Syntax: +ExtendedStatus On|Off +
    Default:ExtendedStatus Off
    Context:server config
    Status:Base
    Module:mod_status
    Compatibility:ExtendedStatus is only available in Apache 1.3.2 and +later.
    +
    + + +

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

    - - - +
    +
    +

    Apache HTTP Server Version 2.0

    +IndexHome +
    + + diff --git a/docs/manual/mod/mod_suexec.html b/docs/manual/mod/mod_suexec.html index 862a9a6fec..d9435e0092 100644 --- a/docs/manual/mod/mod_suexec.html +++ b/docs/manual/mod/mod_suexec.html @@ -1,75 +1,107 @@ - - - - - - - Apache module mod_suexec - - - - - - -

    Module mod_suexec

    - -

    This module provides support for running CGI scripts as a specified User - and Group.

    - -

    Status: Extension
    - Source File: mod_suexec.c
    - Module Identifier: - suexec_module
    - Compatibility: Available in - Apache 2.0 and later.

    - -

    Summary

    - -

    This module allows CGI scripts to run as a specified user + + + + +mod_suexec - Apache HTTP Server + + + +

    +
    +[APACHE DOCUMENTATION]

    Apache HTTP Server Version 2.0

    +
    +

    Apache Module mod_suexec

    + + + + +
    + + + + + + + + + + + + + +
    Description: +This module allows CGI scripts to run as a specified user +and Group. +
    Status:Extension
    Module Identifier:suexec_module
    Compatibility: +Available in Apache 2.0 and later +
    +
    +

    Summary

    + + +

    This module allows CGI scripts to run as a specified user and Group.

    -

    Directives

    - - - -

    SuexecUserGroup directive

    - -

    Syntax: SuexecUserGroup - User Group
    - Default: None
    - Context: server config, virtual - host
    - Status: Extension
    - Module: mod_suexec
    - Compatibility: SuexecUserGroup - is only available in 2.0 and later.

    - -

    The SuexecUserGroup directive allows you to +

    +

    Directives

    + +
    +

    +SuexecUserGroup Directive +

    + + + + +
    + + + + + + + + + + + + + + + + + + + + + + +
    Description:
    Syntax: +SuexecUserGroup User Group + +
    Default:None
    Context:server config, virtual host
    Status:Extension
    Module:mod_suexec
    Compatibility:SuexecUserGroup is only available in 2.0 and +later.
    +
    + + +

    The SuexecUserGroup directive allows you to specify a user and group for CGI programs to run as. Non-CGI requests are still processes with the user specified in the User directive. This directive replaces using the User and Group directives inside of VirtualHosts.

    -
    -

    Apache HTTP Server Version 2.0

    - Index - Home - +
    +
    +

    Apache HTTP Server Version 2.0

    +IndexHome +
    + - diff --git a/docs/manual/mod/mod_unique_id.html b/docs/manual/mod/mod_unique_id.html index edc9611193..4bec0ea316 100644 --- a/docs/manual/mod/mod_unique_id.html +++ b/docs/manual/mod/mod_unique_id.html @@ -1,38 +1,50 @@ - - - - - - - Apache module mod_unique_id - - - - - - -

    Module mod_unique_id

    - -

    This module provides an environment variable with a unique - identifier for each request.

    - -

    Status: Extension
    - Source File: - mod_unique_id.c
    - Module Identifier: - unique_id_module
    - Compatibility: Available in - Apache 1.3 and later.

    - -

    Summary

    - -

    This module provides a magic token for each request which is + + + + +mod_unique_id - Apache HTTP Server + + + +

    +
    +[APACHE DOCUMENTATION]

    Apache HTTP Server Version 2.0

    +
    +

    Apache Module mod_unique_id

    + + + + +
    + + + + + + + + + + + + + +
    Description: +This module provides an environment variable with a unique +identifier for each request. +
    Status:Extension
    Module Identifier:unique_id_module
    Compatibility: +Available in Apache 1.3 and later. +
    +
    +

    Summary

    + + + +

    This module provides a magic token for each request which is guaranteed to be unique across "all" requests under very specific conditions. The unique identifier is even unique across multiple machines in a properly configured cluster of @@ -41,13 +53,14 @@ useful for various reasons which are beyond the scope of this document.

    -

    Directives

    - -

    This module has no directives.

    +
    +

    Directives

    +

    This module provides no directives.

    +

    Theory

    + -

    Theory

    - -

    First a brief recap of how the Apache server works on Unix + +

    First a brief recap of how the Apache server works on Unix machines. This feature currently isn't supported on Windows NT. On Unix machines, Apache creates several children, the children process requests one at a time. Each child can serve multiple @@ -55,7 +68,8 @@ the children don't share any data with each other. We'll refer to the children as httpd processes.

    -

    Your website has one or more machines under your + +

    Your website has one or more machines under your administrative control, together we'll call them a cluster of machines. Each machine can possibly run multiple instances of Apache. All of these collectively are considered "the @@ -64,32 +78,40 @@ without extensive communication between machines in the cluster.

    -

    The machines in your cluster should satisfy these + +

    The machines in your cluster should satisfy these requirements. (Even if you have only one machine you should synchronize its clock with NTP.)

    -
      -
    • The machines' times are synchronized via NTP or other + +
        + +
      • The machines' times are synchronized via NTP or other network time protocol.
      • -
      • The machines' hostnames all differ, such that the module + +
      • The machines' hostnames all differ, such that the module can do a hostname lookup on the hostname and receive a different IP address for each machine in the cluster.
      • -
      + +
    -

    As far as operating system assumptions go, we assume that + +

    As far as operating system assumptions go, we assume that pids (process ids) fit in 32-bits. If the operating system uses more than 32-bits for a pid, the fix is trivial but must be performed in the code.

    -

    Given those assumptions, at a single point in time we can + +

    Given those assumptions, at a single point in time we can identify any httpd process on any machine in the cluster from all other httpd processes. The machine's IP address and the pid of the httpd process are sufficient to do this. So in order to generate unique identifiers for requests we need only distinguish between different points in time.

    -

    To distinguish time we will use a Unix timestamp (seconds + +

    To distinguish time we will use a Unix timestamp (seconds since January 1, 1970 UTC), and a 16-bit counter. The timestamp has only one second granularity, so the counter is used to represent up to 65536 values during a single second. The @@ -98,7 +120,8 @@ process. There are issues however with pid reuse over time, and the counter is used to alleviate this issue.

    -

    When an httpd child is created, the counter is initialized + +

    When an httpd child is created, the counter is initialized with ( current microseconds divided by 10 ) modulo 65536 (this formula was chosen to eliminate some variance problems with the low order bits of the microsecond timers on some systems). When @@ -107,7 +130,8 @@ incremented every time an identifier is generated (and allowed to roll over).

    -

    The kernel generates a pid for each process as it forks the + +

    The kernel generates a pid for each process as it forks the process, and pids are allowed to roll over (they're 16-bits on many Unixes, but newer systems have expanded to 32-bits). So over time the same pid will be reused. However unless it is @@ -117,7 +141,8 @@ be 32768 processes on some Unixes, but even this isn't likely to happen).

    -

    Suppose that time repeats itself for some reason. That is, + +

    Suppose that time repeats itself for some reason. That is, suppose that the system's clock is screwed up and it revisits a past time (or it is too far forward, is reset correctly, and then revisits the future time). In this case we can easily show @@ -130,7 +155,8 @@ time, at least at one second resolution, has repeated itself). This is not a perfect defense.

    -

    How good a defense is it? Suppose that one of your machines + +

    How good a defense is it? Suppose that one of your machines serves at most 500 requests per second (which is a very reasonable upper bound at this writing, because systems generally do more than just shovel out static files). To do @@ -146,7 +172,8 @@ such that it's still likely to occur, then perhaps you should make the counter 32 bits (by editing the code).

    -

    You may be concerned about the clock being "set back" during + +

    You may be concerned about the clock being "set back" during summer daylight savings. However this isn't an issue because the times used here are UTC, which "always" go forward. Note that x86 based Unixes may need proper configuration for this to @@ -155,7 +182,8 @@ even still, if you're running NTP then your UTC time will be correct very shortly after reboot.

    -

    The UNIQUE_ID environment variable is + +

    The UNIQUE_ID environment variable is constructed by encoding the 112-bit (32-bit IP address, 32 bit pid, 32 bit time stamp, 16 bit counter) quadruple using the alphabet [A-Za-z0-9@-] in a manner similar to MIME @@ -173,7 +201,8 @@ compared against other UNIQUE_IDs for equality only.

    -

    The ordering was chosen such that it's possible to change + +

    The ordering was chosen such that it's possible to change the encoding in the future without worrying about collision with an existing database of UNIQUE_IDs. The new encodings should also keep the time stamp as the first element, @@ -184,7 +213,8 @@ encoding format. Afterwards they can resume requests and begin issuing the new encodings.

    -

    This we believe is a relatively portable solution to this + +

    This we believe is a relatively portable solution to this problem. It can be extended to multithreaded systems like Windows NT, and can grow with future needs. The identifiers generated have essentially an infinite life-time because future @@ -196,9 +226,11 @@ kernel). In very specific situations the identifier can be shortened, but more information needs to be assumed (for example the 32-bit IP address is overkill for any site, but - there is no portable shorter replacement for it). - -

    - - + there is no portable shorter replacement for it).

    +
    +

    Apache HTTP Server Version 2.0

    +IndexHome +
    + + diff --git a/docs/manual/mod/mod_userdir.html b/docs/manual/mod/mod_userdir.html index 68f398d4f3..7dd4ece574 100644 --- a/docs/manual/mod/mod_userdir.html +++ b/docs/manual/mod/mod_userdir.html @@ -1,122 +1,212 @@ - - - - - - - Apache module mod_userdir - - - - - - -

    Module mod_userdir

    - -

    This module provides for user-specific directories.

    - -

    Status: Base
    - Source File: - mod_userdir.c
    - Module Identifier: - userdir_module

    - -

    Directives

    - - -
    - -

    UserDir directive

    - - Syntax: UserDir - directory-filename
    - Default: UserDir - public_html
    - Context: server config, virtual - host
    - Status: Base
    - Module: mod_userdir
    - Compatibility: All forms except - the UserDir public_html form are only available in - Apache 1.1 or above. Use of the enabled keyword, - or disabled with a list of usernames, is only - available in Apache 1.3 and above. - -

    The UserDir directive sets the real directory in a user's - home directory to use when a request for a document for a user - is received. Directory-filename is one of the - following:

    - -
      -
    • The name of a directory or a pattern such as those shown + + + + +mod_userdir - Apache HTTP Server + + + +
      +
      +[APACHE DOCUMENTATION]

      Apache HTTP Server Version 2.0

      +
      +

      Apache Module mod_userdir

      + + + + +
      + + + + + + + + + + +
      Description: +This module provides for user-specific +directories. +
      Status:Base
      Module Identifier:userdir_module
      +
      +

      Summary

      + + + +

      Directives

      + +
      +

      +UserDir Directive +

      + + + + +
      + + + + + + + + + + + + + + + + + + + + + + +
      Description: Sets the directory from which to serve files when requests +for a particular user are received, denoted by requests containing +~username, such as +http://server.example.com/~bob/
      Syntax: +UserDir directory-filename + +
      Default:UserDir public_html
      Context:server config, virtual +host
      Status:Base
      Module:mod_userdir
      Compatibility:All forms except the UserDir public_html +form are only available in Apache 1.1 or above. Use of the +enabled keyword, or disabled with a +list of usernames, is only available in Apache 1.3 and +above.
      +
      + + + +

      The UserDir directive sets the real + directory in a user's home directory to use when a request for a + document for a user is received. Directory-filename is + one of the following:

      + + +
        + +
      • The name of a directory or a pattern such as those shown below.
      • -
      • The keyword disabled. This turns off + +
      • The keyword disabled. This turns off all username-to-directory translations except those - explicitly named with the enabled keyword (see + explicitly named with the enabled keyword (see below).
      • -
      • The keyword disabled followed by a + +
      • The keyword disabled followed by a space-delimited list of usernames. Usernames that appear in such a list will never have directory translation - performed, even if they appear in an enabled + performed, even if they appear in an enabled clause.
      • -
      • The keyword enabled followed by a + +
      • The keyword enabled followed by a space-delimited list of usernames. These usernames will have directory translation performed even if a global disable is in effect, but not if they also appear in a - disabled clause.
      • -
      - -

      If neither the enabled nor the - disabled keywords appear in the - Userdir directive, the argument is treated as a + disabled clause.

    • + +
    + + +

    If neither the enabled nor the + disabled keywords appear in the + Userdir directive, the argument is treated as a filename pattern, and is used to turn the name into a directory specification. A request for http://www.foo.com/~bob/one/two.html will be translated to:

    -
    -UserDir public_html     -> ~bob/public_html/one/two.html
    -UserDir /usr/web        -> /usr/web/bob/one/two.html
    -UserDir /home/*/www     -> /home/bob/www/one/two.html
    -
    - The following directives will send redirects to the client: -
    -UserDir http://www.foo.com/users -> http://www.foo.com/users/bob/one/two.html
    -UserDir http://www.foo.com/*/usr -> http://www.foo.com/bob/usr/one/two.html
    -UserDir http://www.foo.com/~*/   -> http://www.foo.com/~bob/one/two.html
    -
    -
    -
    - - -
    + + + + + + + + + + + + + + + + + + + + + +
    UserDir directive usedTranslated path
    UserDir public_html~bob/public_html/one/two.html
    UserDir /usr/web/usr/web/bob/one/two.html
    UserDir /home/*/www/home/bob/www/one/two.html
    + + +

    The following directives will send redirects to the client:

    + + + + + + + + + + + + + + + + + + + + + +
    UserDir directive usedTranslated path
    UserDir http://www.foo.com/usershttp://www.foo.com/users/bob/one/two.html
    UserDir +http://www.foo.com/*/usrhttp://www.foo.com/bob/usr/one/two.html
    UserDir +http://www.foo.com/~*/http://www.foo.com/~bob/one/two.html
    + + +
    + + + + +
    Be careful when using this directive; for instance, - "UserDir ./" would map - "/~root" to "/" - which is probably + "UserDir ./" would map + "/~root" to "/" - which is probably undesirable. If you are running Apache 1.3 or above, it is strongly recommended that your configuration include a - "UserDir disabled root" declaration. - See also the <Directory> directive - and the Security + "UserDir disabled root" declaration. + See also the Directory + directive and the Security Tips page for more information. - - - +
    +
    + + + +
    +

    Apache HTTP Server Version 2.0

    +IndexHome +
    + -