Each Apache configuration directive is described using a common format that looks like this:
Each of the directive's attributes, complete with possible values where possible, are described in this document.
This indicates the format of the directive as it would appear in a configuration file. This syntax is extremely directive-specific, and is described in detail in the directive's definition. Generally, the directive name is followed by a series of one or more space-separated arguments. If an argument contains a space, the argument must be enclosed in double quotes. Optional arguments are enclosed in square brackets. Where an argument can take on more than one possible value, the possible values are separated by vertical bars "|". Literal text is presented in the default font, while argument-types for which substitution is necessary are emphasized. Directives which can take a variable number of arguments will end in "..." indicating that the last argument is repeated.
Directives use a great number of different argument types. A few common ones are defined below.
/path/to/file.html. The url-path represents a web-view of a resource, as opposed to a file-system view.
/usr/local/apache/htdocs/path/to/file.html. Unless otherwise specified, a file-path which does not begin with a slash will be treated as relative to the ServerRoot.
file.html.encontains two extensions:
.en. For Apache directives, you may specify extensions with or without the leading dot. In addition, extensions are not case sensitive.
If the directive has a default value (i.e., if you omit it from your configuration entirely, the Apache Web server will behave as though you set it to a particular value), it is described here. If there is no default value, this section should say "None". Note that the default listed here is not necessarily the same as the value the directive takes in the default httpd.conf distributed with the server.
This indicates where in the server's configuration files the directive is legal. It's a comma-separated list of one or more of the following values:
The directive is only allowed within the designated context; if you try to use it elsewhere, you'll get a configuration error that will either prevent the server from handling requests in that context correctly, or will keep the server from operating at all -- i.e., the server won't even start.
The valid locations for the directive are actually the result of a Boolean OR of all of the listed contexts. In other words, a directive that is marked as being valid in "server config, .htaccess" can be used in the httpd.conf file and in .htaccess files, but not within any <Directory> or <VirtualHost> containers.
This directive attribute indicates which configuration override must be active in order for the directive to be processed when it appears in a .htaccess file. If the directive's context doesn't permit it to appear in .htaccess files, this attribute should say "Not applicable".
Overrides are activated by the AllowOverride directive, and apply to a particular scope (such as a directory) and all descendants, unless further modified by other AllowOverride directives at lower levels. The documentation for that directive also lists the possible override names available.
This indicates how tightly bound into the Apache Web server the directive is; in other words, you may need to recompile the server with an enhanced set of modules in order to gain access to the directive and its functionality. Possible values for this attribute are:
This quite simply lists the name of the source module which defines the directive.
If the directive wasn't part of the original Apache version 1 distribution, the version in which it was introduced should be listed here. If the directive has the same name as one from the NCSA HTTPd server, any inconsistencies in behavior between the two should also be mentioned. Otherwise, this attribute should say "No compatibility issues."
If this directive is eliminated since the Apache version 1 distribution, the directive or option that replaces the behavior should be cited here. In general, directives, features, and options are only deprecated to minimize debugging of conflicting features, or if the feature can only continue to be supported in an alternate manner.