Документ взят из кэша поисковой машины. Адрес
оригинального документа
: http://old.master.cmc.msu.ru/manual/mod/core.html
Дата изменения: Sat Mar 10 20:38:05 2001 Дата индексирования: Tue Oct 2 14:41:34 2012 Кодировка: Поисковые слова: transit |
These configuration parameters control the core Apache features, and are always available.
AccessConfig conf/access.conf
The server will read this file for more directives after reading the ResourceConfig file. Filename is relative to the ServerRoot. This feature can be disabled using:
AccessConfig /dev/null
Or, on Win32 servers,
AccessConfig nul
Historically, this file only contained
<Directory> sections; in fact it can now
contain any server directive allowed in the server config context.
New in Apache 1.3.13 is the feature that if AccessConfig
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.
See also ResourceConfig.
AccessFileName .htaccess
When returning a document to the client the server looks for the first existing access control file from this list of names in every directory of the path to the document, if access control files are enabled for that directory. For example:
AccessFileName .acl
before returning the document /usr/local/web/index.html, the
server will read /.acl, /usr/.acl, /usr/local/.acl and /usr/local/web/.acl
for directives, unless they have been disabled with
<Directory />
AllowOverride None
</Directory>
See Also: AllowOverride
AddDefaultCharset Off
This directive specifies the name of the character set that will be added
to any response that does not have any parameter on the content
type in the HTTP headers. This will override any character set specified
in the body of the document via a META
tag. A setting
of AddDefaultCharset Off
disables this functionality.
AddDefaultCharset On
enables Apache's internal
default charset of iso-8859-1
as required by the
directive. You can also specify an alternate charset to be used;
e.g. AddDefaultCharset utf-8
.
The server can have modules compiled in which are not actively in use. This directive can be used to enable the use of those modules. The server comes with a pre-loaded list of active modules; this list can be cleared with the ClearModuleList directive.
AllowOverride All
When the server finds an .htaccess file (as specified by AccessFileName) it needs to know which directives declared in that file can override earlier access information.
When this directive is set to None
, then
.htaccess files are completely ignored. In this case, the server
will not even attempt to read .htaccess files in the filesystem.
When this directive is set to All
, then any directive
which has the .htaccess Context is allowed in .htaccess
files.
The directive-type can be one of the following groupings of directives.
See Also: AccessFileName
This directive sets the name of the authorization realm for a directory. This realm is given to the client so that the user knows which username and password to send. AuthName takes a single argument; if the realm name contains spaces, it must be enclosed in quotation marks. It must be accompanied by AuthType and Require directives, and directives such as AuthUserFile and AuthGroupFile to work.
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.
BindAddress *
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.
Only one BindAddress
directive can be used. For more
control over which address and ports Apache listens to, use the
Listen
directive instead of
BindAddress
.
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
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
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 off
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.
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.
DefaultType text/html
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.<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 is either the full path to a directory, or a wild-card string. In a wild-card string, `?' matches any single character, and `*' matches any sequences of characters. As of Apache 1.3, you may also use `[]' character ranges like in the shell. Also as of Apache 1.3 none of the wildcards match a `/' character, which more closely mimics the behaviour of Unix shells. Example:
<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:
Regular expression directory sections are handled slightly differently by Apache 1.2 and 1.3. In Apache 1.2 they are interspersed with the normal directory sections and applied in the order they appear in the configuration file. They are applied only once, and apply when the shortest match possible occurs. In Apache 1.3 regular expressions are not considered until after all of the normal sections have been applied. Then all of the regular expressions are tested in the order they appeared in the configuration file. For example, with
<Directory ~ abc$>
... directives here ...
</Directory>
Suppose that the filename being accessed is
/home/abc/public_html/abc/index.html
. The server
considers each of /
, /home
, /home/abc
,
/home/abc/public_html
, and /home/abc/public_html/abc
in that order. In Apache 1.2, when
/home/abc
is considered, the regular expression will match
and be applied. In Apache 1.3 the regular expression isn't considered
at all at that point in the tree. It won't be considered until after
all normal <Directory>s and .htaccess
files have
been applied. Then the regular expression will
match on /home/abc/public_html/abc
and be applied.
Note that the default Apache access for <Directory /> is Allow from All. This means that Apache will serve any file mapped from an URL. It is recommended that you change this with a block such as
<Directory /> Order Deny,Allow Deny from All </Directory>
and then override this for directories you want accessible. See the Security Tips page for more details.
The directory sections typically occur in the access.conf file, but they may appear in any configuration file. <Directory> directives cannot nest, and cannot appear in a <Limit> or <LimitExcept> section.See also: How Directory, Location and Files sections work for an explanation of how these different sections are combined when a request is received
<DirectoryMatch> and </DirectoryMatch> are used to enclose a group of directives which will apply only to the named directory and sub-directories of that directory, the same as <Directory>. However, it takes as an argument a regular expression. For example:
<DirectoryMatch "^/www/.*/[0-9]{3}">
would match directories in /www/ that consisted of three numbers.
See Also:
<Directory> for a description of how
regular expressions are mixed in with normal <Directory>s.
See also: How Directory,
Location and Files sections work for an explanation of how these
different sections are combined when a request is received
DocumentRoot
/usr/local/apache/htdocs
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.
In the event of a problem or error, Apache can be configured to do one of four things,
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 message or URL.
Messages in this context begin with a single double-quote
character ("
), which does not form part of the message itself.
Apache will sometimes offer additional information regarding the
problem/error.
URLs can begin with a slash (/) for local URLs, or be a full URL which the client can resolve. Examples:
ErrorDocument 500 http://foo.example.com/cgi-bin/tester
ErrorDocument 404 /cgi-bin/bad_urls.pl
ErrorDocument 401 /subscription_info.html
ErrorDocument 403 "Sorry can't allow you access today
Note that when you specify an ErrorDocument
that
points to a remote URL (ie. anything with a method such as "http" in
front of it), Apache will send a redirect to the client to tell it
where to find the document, even if the document ends up being on the
same server. This has several implications, the most important being
that the client will not receive the original error status code, but
instead will receive a redirect status code. This in turn can confuse
web robots and other clients which try to determine if a URL is valid
using the status code. In addition, if you use a remote URL in an
ErrorDocument 401
, the client will not know to prompt the
user for a password since it will not receive the 401 status
code. Therefore, if you use an "ErrorDocument 401" directive
then it must refer to a local document.
See Also: documentation of customizable responses.