Apache Core Features 3
Syntax:
BindAddress *|IP-address|domain-name
Default:
BindAddress *
Context:
server config
Status:
core
Compatibility:
BindAddress is deprecated and will be eliminated in Apache 2.0.
A Unix® http server can either listen for connections to every IP address of the server
machine, or just one IP address of the server machine. If the argument to this directive is *,
then the server will listen for connections on every IP address. Otherwise, the server can
listen to only a specific IP-address or a fully-qualified Internet domain-name.
For example:
BindAddress 192.168.15.48
Only one BindAddress directive can be used.
This directive is deprecated and will be eliminated in Apache 2.0. Equivalent functionality
and more control over the address and ports Apache listens to is available using the Listen directive.
BindAddress can be used as an alternative method for supporting
virtual hosts using multiple independent
servers, instead of using <VirtualHost>
sections.
See Also:
DNS
Issues
See Also:
Setting which
addresses and ports Apache uses
Syntax:
BS2000Account account
Default:
none
Context:
server config
Status:
core
Compatibility:
BS2000Account is only available for BS2000 machines, as of Apache 1.3 and later.
The BS2000Account directive is available for BS2000 hosts only. It must be
used to define the account number for the non-privileged apache server user (which was
configured using the User directive). This is required by the BS2000 POSIX
subsystem (to change the underlying BS2000 task environment by performing a sub-LOGON) to
prevent CGI scripts from accessing resources of the privileged account which started the
server, usually SYSROOT.
Only one BS2000Account directive can be used.
See Also:
Apache EBCDIC
port
Syntax:
CGICommandArgs On|Off
Default:
CGICommandArgs On
Context:
directory, .htaccess
Override:
Options
Status:
core
Compatibility:
Available in Apache 1.3.24 and later.
Way back when the internet was a safer, more naive place, it was convenient for the server
to take a query string that did not contain an '=' sign and to parse and pass it to a CGI
program as command line args. For example, <IsIndex> generated searches
often work in this way. The default behavior in Apache is to maintain this behavior for
backwards compatibility, although it is generally regarded as unsafe practice today. Most CGI
programs do not take command line parameters, but among those that do, many are unaware of
this method of passing arguments and are therefore vulnerable to malicious clients passing
unsafe material in this way. Setting CGICommandArgs Off is recommended to protect
such scripts with little loss in functionality.
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.
See also: AddModule and
LoadModule
Syntax:
ContentDigest on|off
Default:
ContentDigest off
Context:
server config, virtual host, directory, .htaccess
Override:
Options
Status:
experimental
Compatibility:
ContentDigest is only available in Apache 1.1 and later
This directive enables the generation of Content-MD5 headers as defined in
RFC1864 respectively RFC2068.
MD5 is an algorithm for computing a "message digest" (sometimes called
"fingerprint") of arbitrary-length data, with a high degree of confidence that any
alterations in the data will be reflected in alterations in the message digest.
The Content-MD5 header provides an end-to-end message integrity check (MIC) of
the entity-body. A proxy or client may check this header for detecting accidental modification
of the entity-body in transit. Example header:
Content-MD5: AuLb7Dp1rqtRtxz2m9kRpA==
Note that this can cause performance problems on your server since the message digest is
computed on every request (the values are not cached).
Content-MD5 is only sent for documents served by the core, and not by any
module. For example, SSI documents, output from CGI scripts, and byte range responses do not
have this header.
Syntax:
CoreDumpDirectory directory-path
Default:
the same location as ServerRoot
Context:
server config
Status:
core
This controls the directory to which Apache attempts to switch before dumping core. The
default is in the ServerRoot directory, however since this should
not be writable by the user the server runs as, core dumps won't normally get written. If you
want a core dump for debugging, you can use this directive to place it in a different
location.
For example:
CoreDumpDirectory /tmp
Syntax:
DefaultType MIME-type
Default:
DefaultType text/plain
Context:
server config, virtual host, directory, .htaccess
Override:
FileInfo
Status:
core
There will be times when the server is asked to provide a document whose type cannot be
determined by its MIME types mappings.
The server must inform the client of the content-type of the document, so in the event of
an unknown type it uses the DefaultType. For example:
DefaultType image/gif
would be appropriate for a directory which contained many gif images with filenames missing
the .gif extension.
See also:
AddType
and TypesConfig.
Syntax:
<Directory directory-path|proxy:url-path> ... </Directory>
Context:
server config, virtual host
Status:
Core.
<Directory> and </Directory> are used to enclose a group of directives which
will apply only to the named directory and sub-directories of that directory. Any directive
which is allowed in a directory context may be used. Directory-path is either the
full path to a directory, or a wild-card string. In a wild-card string, `?' matches any single
character, and `*' matches any sequences of characters. As of Apache 1.3, you may also use `[
]' character ranges like in the shell. Also as of Apache 1.3 none of the wildcards match a `/'
character, which more closely mimics the behavior of Unix shells. Example:
<Directory /usr/local/httpd/htdocs>
Options Indexes FollowSymLinks
</Directory>
Apache 1.2 and above: Extended regular expressions can also be used, with
the addition of the ~ character. For example:
<Directory ~ "^/www/.*/[0-9]{3}">
would match directories in /www/ that consisted of three numbers.
If multiple (non-regular expression) directory sections match the directory (or its
parents) containing a document, then the directives are applied in the order of shortest match
first, interspersed with the directives from the .htaccess
files. For example, with
<Directory />
AllowOverride None
</Directory>
<Directory /home/*>
AllowOverride FileInfo
</Directory>
for access to the document /home/web/dir/doc.html the steps are:
- Apply directive
AllowOverride None (disabling .htaccess
files).
- Apply directive
AllowOverride FileInfo (for directory /home/web).
- Apply any FileInfo directives in
/home/web/.htaccess
Regular expression directory sections are handled slightly differently by Apache 1.2 and
1.3. In Apache 1.2 they are interspersed with the normal directory sections and applied in the
order they appear in the configuration file. They are applied only once, and apply when the
shortest match possible occurs. In Apache 1.3 regular expressions are not considered until
after all of the normal sections have been applied. Then all of the regular expressions are
tested in the order they appeared in the configuration file. For example, with
<Directory ~ abc$>
... directives here ...
</Directory>
Suppose that the filename being accessed is /home/abc/public_html/abc/index.html.
The server considers each of /, /home, /home/abc, /home/abc/public_html,
and /home/abc/public_html/abc in that order. In Apache 1.2, when /home/abc
is considered, the regular expression will match and be applied. In Apache 1.3 the regular
expression isn't considered at all at that point in the tree. It won't be considered until
after all normal <Directory>s and .htaccess files have been applied. Then
the regular expression will match on /home/abc/public_html/abc and be applied.
Note that the default Apache access for <Directory /> is Allow from All.
This means that Apache will serve any file mapped from an URL. It is recommended that you
change this with a block such as
<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.
<Directory> directives cannot nest, and cannot appear in a
<Limit>
or <LimitExcept> section.
If you have mod_proxy
enabled, you can use the proxy: syntax to apply configuration directives to
proxied content. The syntax for this is to specify the proxied URLs to which you wish to apply
the configuration, or to specify * to apply to all proxied content:
To apply to all proxied content:
<Directory proxy:*>
... directives here ...
</Directory>
To apply to just a subset of proxied content:
<Directory proxy:http://www.example.com/>
... directives here ...
</Directory>
See also:
How
Directory, Location and Files sections work for an explanation of how these different
sections are combined when a request is received
See also: DirectoryMatch
Syntax:
<DirectoryMatch regex> ... </DirectoryMatch>
Context:
server config, virtual host
Status:
Core.
Compatibility:
Available in Apache 1.3 and later
<DirectoryMatch> and </DirectoryMatch> are used to enclose a group of
directives which will apply only to the named directory and sub-directories of that directory,
the same as <Directory>. However, it takes as an argument a
regular expression. For example:
<DirectoryMatch "^/www/.*/[0-9]{3}">
would match directories in /www/ that consisted of three numbers.
See Also: <Directory> for a description of
how regular expressions are mixed in with normal <Directory>s.
See also:
How Directory,
Location and Files sections work for an explanation of how these different sections are
combined when a request is received
Syntax:
DocumentRoot directory-path
Default:
DocumentRoot /usr/local/apache/htdocs
Context:
server config, virtual host
Status:
core
This directive sets the directory from which httpd will serve files. Unless matched by a
directive like Alias, the server appends the path from the requested URL to the document root
to make the path to the document. Example:
DocumentRoot /usr/web
then an access to http://www.my.host.com/index.html refers to /usr/web/index.html.
There appears to be a bug in mod_dir which causes problems when the DocumentRoot has a
trailing slash (i.e., "DocumentRoot /usr/web/") so please avoid that.
|
