mirror of
https://github.com/apache/httpd.git
synced 2025-10-31 19:10:37 +03:00
a4a0cba5f5
PR: 5075 git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@90520 13f79535-47bb-0310-9956-ffa450edef68
2702 lines
96 KiB
HTML
2702 lines
96 KiB
HTML
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
|
|
<HTML>
|
|
<HEAD>
|
|
<TITLE>Apache Core Features</TITLE>
|
|
</HEAD>
|
|
|
|
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
|
|
<BODY
|
|
BGCOLOR="#FFFFFF"
|
|
TEXT="#000000"
|
|
LINK="#0000FF"
|
|
VLINK="#000080"
|
|
ALINK="#FF0000"
|
|
>
|
|
<!--#include virtual="header.html" -->
|
|
|
|
<H1 ALIGN="CENTER">Apache Core Features</H1>
|
|
<P>
|
|
These configuration parameters control the core Apache features, and are
|
|
always available.
|
|
</P>
|
|
<H2>Directives</H2>
|
|
<UL>
|
|
<LI><A HREF="#accessfilename">AccessFileName</A>
|
|
<LI><A HREF="#adddefaultcharset">AddDefaultCharset</A>
|
|
<LI><A HREF="#addmodule">AddModule</A>
|
|
<LI><A HREF="#allowoverride">AllowOverride</A>
|
|
<LI><A HREF="#authname">AuthName</A>
|
|
<LI><A HREF="#authtype">AuthType</A>
|
|
<LI><A HREF="#clearmodulelist">ClearModuleList</A>
|
|
<LI><A HREF="#contentdigest">ContentDigest</A>
|
|
<LI><A HREF="#coredumpdirectory">CoreDumpDirectory</A>
|
|
<LI><A HREF="#defaulttype">DefaultType</A>
|
|
<LI><A HREF="#directory"><Directory></A>
|
|
<LI><A HREF="#directorymatch"><DirectoryMatch></A>
|
|
<LI><A HREF="#documentroot">DocumentRoot</A>
|
|
<LI><A HREF="#errordocument">ErrorDocument</A>
|
|
<LI><A HREF="#errorlog">ErrorLog</A>
|
|
<LI><A HREF="#files"><Files></A>
|
|
<LI><A HREF="#filesmatch"><FilesMatch></A>
|
|
<LI><A HREF="#hostnamelookups">HostNameLookups</A>
|
|
<LI><A HREF="#identitycheck">IdentityCheck</A>
|
|
<LI><A HREF="#ifdefine"><IfDefine></A>
|
|
<LI><A HREF="#ifmodule"><IfModule></A>
|
|
<LI><A HREF="#include">Include</A>
|
|
<LI><A HREF="#keepalive">KeepAlive</A>
|
|
<LI><A HREF="#keepalivetimeout">KeepAliveTimeout</A>
|
|
<LI><A HREF="#limit"><Limit></A>
|
|
<LI><A HREF="#limitexcept"><LimitExcept></A>
|
|
<LI><A HREF="#limitrequestbody">LimitRequestBody</A>
|
|
<LI><A HREF="#limitrequestfields">LimitRequestFields</A>
|
|
<LI><A HREF="#limitrequestfieldsize">LimitRequestFieldsize</A>
|
|
<LI><A HREF="#limitrequestline">LimitRequestLine</A>
|
|
<LI><A HREF="#limitxmlrequestbody">LimitXMLRequestBody</A>
|
|
<LI><A HREF="#location"><Location></A>
|
|
<LI><A HREF="#locationmatch"><LocationMatch></A>
|
|
<LI><A HREF="#loglevel">LogLevel</A>
|
|
<LI><A HREF="#maxkeepaliverequests">MaxKeepAliveRequests</A>
|
|
<LI><A HREF="#namevirtualhost">NameVirtualHost</A>
|
|
<LI><A HREF="#options">Options</A>
|
|
<LI><A HREF="#port">Port</A>
|
|
<LI><A HREF="#require">Require</A>
|
|
<LI><A HREF="#rlimitcpu">RLimitCPU</A>
|
|
<LI><A HREF="#rlimitmem">RLimitMEM</A>
|
|
<LI><A HREF="#rlimitnproc">RLimitNPROC</A>
|
|
<LI><A HREF="#satisfy">Satisfy</A>
|
|
<LI><A HREF="#scriptinterpretersource">ScriptInterpreterSource</A>
|
|
<LI><A HREF="#serveradmin">ServerAdmin</A>
|
|
<LI><A HREF="#serveralias">ServerAlias</A>
|
|
<LI><A HREF="#servername">ServerName</A>
|
|
<LI><A HREF="#serverpath">ServerPath</A>
|
|
<LI><A HREF="#serverroot">ServerRoot</A>
|
|
<LI><A HREF="#serversignature">ServerSignature</A>
|
|
<LI><A HREF="#servertokens">ServerTokens</A>
|
|
<LI><A HREF="#setinputfilter">SetInputFilter</A>
|
|
<LI><A HREF="#setoutputfilter">SetOutputFilter</A>
|
|
<LI><A HREF="#timeout">TimeOut</A>
|
|
<LI><A HREF="#usecanonicalname">UseCanonicalName</A>
|
|
<LI><A HREF="#virtualhost"><VirtualHost></A>
|
|
</UL>
|
|
<HR>
|
|
|
|
<H2><A NAME="accessfilename">AccessFileName directive</A></H2>
|
|
<!--%plaintext <?INDEX {\tt AccessFileName} directive> -->
|
|
<A
|
|
HREF="directive-dict.html#Syntax"
|
|
REL="Help"
|
|
><STRONG>Syntax:</STRONG></A> AccessFileName <EM>filename</em>
|
|
[<em>filename</em>] ...<BR>
|
|
<A
|
|
HREF="directive-dict.html#Default"
|
|
REL="Help"
|
|
><STRONG>Default:</STRONG></A> <CODE>AccessFileName .htaccess</CODE><BR>
|
|
<A
|
|
HREF="directive-dict.html#Context"
|
|
REL="Help"
|
|
><STRONG>Context:</STRONG></A> server config, virtual host<BR>
|
|
<A
|
|
HREF="directive-dict.html#Status"
|
|
REL="Help"
|
|
><STRONG>Status:</STRONG></A> core<BR>
|
|
<A
|
|
HREF="directive-dict.html#Compatibility"
|
|
REL="Help"
|
|
><STRONG>Compatibility:</STRONG></A> AccessFileName can accept more than
|
|
one filename only in Apache 1.3 and later<P>
|
|
|
|
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:
|
|
<BLOCKQUOTE><CODE>AccessFileName .acl</CODE></BLOCKQUOTE>
|
|
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
|
|
<BLOCKQUOTE><CODE>
|
|
<Directory /><BR>
|
|
AllowOverride None<BR>
|
|
</Directory></CODE>
|
|
</BLOCKQUOTE><P>
|
|
|
|
<P><STRONG>See Also:</STRONG>
|
|
<A HREF="#allowoverride">AllowOverride</a></P>
|
|
<HR>
|
|
|
|
<H2><A NAME="adddefaultcharset">AddDefaultCharset directive</A></H2>
|
|
<A HREF="directive-dict.html#Syntax" REL="Help"><STRONG>Syntax:</STRONG></A>
|
|
AddDefaultCharset On|Off|<em>charset</em><BR>
|
|
<A HREF="directive-dict.html#Context" REL="Help" ><STRONG>Context:</STRONG></A>
|
|
all<BR>
|
|
<A HREF="directive-dict.html#Status" REL="Help" ><STRONG>Status:</STRONG></A>
|
|
core<BR>
|
|
<A HREF="directive-dict.html#Default" REL="Help"><STRONG>Default:</STRONG></A>
|
|
<CODE>AddDefaultCharset Off</CODE><BR>
|
|
<A HREF="directive-dict.html#Compatibility" REL="Help"><STRONG>Compatibility:
|
|
</STRONG></A> AddDefaultCharset is only available in Apache 1.3.12 and
|
|
later<P>
|
|
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 <CODE>META</CODE> tag. A setting
|
|
of <CODE>AddDefaultCharset Off</CODE> disables this functionality.
|
|
<CODE>AddDefaultCharset On</CODE> enables Apache's internal
|
|
default charset of <code>iso-8859-1</code> as required by the
|
|
directive. You can also specify an alternate <em>charset</em> to be used;
|
|
e.g. <code>AddDefaultCharset utf-8</code>.
|
|
<P><HR>
|
|
|
|
<H2><A NAME="addmodule">AddModule directive</A></H2>
|
|
<!--%plaintext <?INDEX {\tt AddModule} directive> -->
|
|
<A
|
|
HREF="directive-dict.html#Syntax"
|
|
REL="Help"
|
|
><STRONG>Syntax:</STRONG></A> AddModule <EM>module</em> [<em>module</em>] ...<BR>
|
|
<A
|
|
HREF="directive-dict.html#Context"
|
|
REL="Help"
|
|
><STRONG>Context:</STRONG></A> server config <BR>
|
|
<A
|
|
HREF="directive-dict.html#Status"
|
|
REL="Help"
|
|
><STRONG>Status:</STRONG></A> core<BR>
|
|
<A
|
|
HREF="directive-dict.html#Compatibility"
|
|
REL="Help"
|
|
><STRONG>Compatibility:</STRONG></A> AddModule is only available in
|
|
Apache 1.2 and later<P>
|
|
|
|
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 <A HREF="#clearmodulelist">ClearModuleList</A>
|
|
directive.<P><HR>
|
|
|
|
<H2><A NAME="allowoverride">AllowOverride directive</A></H2>
|
|
<!--%plaintext <?INDEX {\tt AllowOverride} directive> -->
|
|
<A
|
|
HREF="directive-dict.html#Syntax"
|
|
REL="Help"
|
|
><STRONG>Syntax:</STRONG></A> AllowOverride All|None|<EM>directive-type</em>
|
|
[<em>directive-type</em>] ...<BR>
|
|
<A
|
|
HREF="directive-dict.html#Default"
|
|
REL="Help"
|
|
><STRONG>Default:</STRONG></A> <CODE>AllowOverride All</CODE><BR>
|
|
<A
|
|
HREF="directive-dict.html#Context"
|
|
REL="Help"
|
|
><STRONG>Context:</STRONG></A> directory<BR>
|
|
<A
|
|
HREF="directive-dict.html#Status"
|
|
REL="Help"
|
|
><STRONG>Status:</STRONG></A> core<P>
|
|
|
|
<p>When the server finds an .htaccess file (as specified by
|
|
<A HREF="#accessfilename">AccessFileName</A>) it needs to know which
|
|
directives declared in that file can override earlier access information.</p>
|
|
|
|
<p>When this directive is set to <code>None</code>, then
|
|
.htaccess files are completely ignored. In this case, the server
|
|
will not even attempt to read .htaccess files in the filesystem.</p>
|
|
|
|
<p>When this directive is set to <code>All</code>, then any directive
|
|
which has the .htaccess <a
|
|
href="directive-dict.html#Context">Context</a> is allowed in .htaccess
|
|
files.</p>
|
|
|
|
<p>The <em>directive-type</em> can be one of the following groupings
|
|
of directives.</p>
|
|
<DL>
|
|
<DT>AuthConfig
|
|
<DD>
|
|
<!--%plaintext <?INDEX {\tt AuthConfig} override> -->
|
|
Allow use of the authorization directives
|
|
(<A HREF="mod_auth_dbm.html#authdbmgroupfile">AuthDBMGroupFile</A>,
|
|
<A HREF="mod_auth_dbm.html#authdbmuserfile">AuthDBMUserFile</A>,
|
|
<A HREF="mod_auth.html#authgroupfile">AuthGroupFile</A>,
|
|
<A HREF="#authname">AuthName</A>, <A HREF="#authtype">AuthType</A>,
|
|
<A HREF="mod_auth.html#authuserfile">AuthUserFile</A>,
|
|
<A HREF="#require">Require</A>, <EM>etc.</EM>).
|
|
<DT>FileInfo
|
|
<DD>
|
|
<!--%plaintext <?INDEX {\tt FileInfo} override> -->
|
|
Allow use of the directives controlling document types
|
|
(<A HREF="mod_mime.html#addencoding">AddEncoding</A>,
|
|
<A HREF="mod_mime.html#addlanguage">AddLanguage</A>,
|
|
<A HREF="mod_mime.html#addtype">AddType</A>,
|
|
<A HREF="#defaulttype">DefaultType</A>,
|
|
<A HREF="#errordocument">ErrorDocument</A>,
|
|
<A HREF="mod_negotiation.html#languagepriority">LanguagePriority</A>, <EM>etc.</EM>).
|
|
<DT>Indexes
|
|
<DD>
|
|
<!--%plaintext <?INDEX {\tt Indexes} override> -->
|
|
Allow use of the directives controlling directory indexing
|
|
(<A HREF="mod_autoindex.html#adddescription">AddDescription</A>,
|
|
<A HREF="mod_autoindex.html#addicon">AddIcon</A>,
|
|
<A HREF="mod_autoindex.html#addiconbyencoding">AddIconByEncoding</A>,
|
|
<A HREF="mod_autoindex.html#addiconbytype">AddIconByType</A>,
|
|
<A HREF="mod_autoindex.html#defaulticon">DefaultIcon</A>,
|
|
<A HREF="mod_dir.html#directoryindex">DirectoryIndex</A>,
|
|
<A HREF="mod_autoindex.html#fancyindexing">FancyIndexing</A>,
|
|
<A HREF="mod_autoindex.html#headername">HeaderName</A>,
|
|
<A HREF="mod_autoindex.html#indexignore">IndexIgnore</A>,
|
|
<A HREF="mod_autoindex.html#indexoptions">IndexOptions</A>,
|
|
<A HREF="mod_autoindex.html#readmename">ReadmeName</A>, <EM>etc.</EM>).
|
|
<DT>Limit
|
|
<DD>
|
|
<!--%plaintext <?INDEX {\tt Limit} override> -->
|
|
Allow use of the directives controlling host access (Allow, Deny and Order).
|
|
<DT>Options
|
|
<DD>
|
|
<!--%plaintext <?INDEX {\tt Options} override> -->
|
|
Allow use of the directives controlling specific directory features
|
|
(<A HREF="#options">Options</A> and
|
|
<A HREF="mod_include.html#xbithack">XBitHack</A>).
|
|
</DL><P>
|
|
|
|
<P><STRONG>See Also:</STRONG>
|
|
<A HREF="#accessfilename">AccessFileName</A></P>
|
|
<HR>
|
|
|
|
<H2><A NAME="authname">AuthName directive</A></H2>
|
|
<!--%plaintext <?INDEX {\tt AuthName} directive> -->
|
|
<A
|
|
HREF="directive-dict.html#Syntax"
|
|
REL="Help"
|
|
><STRONG>Syntax:</STRONG></A> AuthName <EM>auth-domain</EM><BR>
|
|
<A
|
|
HREF="directive-dict.html#Context"
|
|
REL="Help"
|
|
><STRONG>Context:</STRONG></A> directory, .htaccess<BR>
|
|
<A
|
|
HREF="directive-dict.html#Override"
|
|
REL="Help"
|
|
><STRONG>Override:</STRONG></A> AuthConfig<BR>
|
|
<A
|
|
HREF="directive-dict.html#Status"
|
|
REL="Help"
|
|
><STRONG>Status:</STRONG></A> core<P>
|
|
|
|
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. <SAMP>AuthName</SAMP> takes a single argument;
|
|
if the realm name contains spaces, it must be enclosed in quotation marks.
|
|
It must be accompanied by <A HREF="#authtype">AuthType</A> and
|
|
<A HREF="#require">Require</A> directives, and directives such as
|
|
<A HREF="mod_auth.html#authuserfile">AuthUserFile</A> and
|
|
<A HREF="mod_auth.html#authgroupfile">AuthGroupFile</A> to work.<P><HR>
|
|
|
|
<H2><A NAME="authtype">AuthType directive</A></H2>
|
|
<!--%plaintext <?INDEX {\tt AuthType} directive> -->
|
|
<A
|
|
HREF="directive-dict.html#Syntax"
|
|
REL="Help"
|
|
><STRONG>Syntax:</STRONG></A> AuthType Basic|Digest<BR>
|
|
<A
|
|
HREF="directive-dict.html#Context"
|
|
REL="Help"
|
|
><STRONG>Context:</STRONG></A> directory, .htaccess<BR>
|
|
<A
|
|
HREF="directive-dict.html#Override"
|
|
REL="Help"
|
|
><STRONG>Override:</STRONG></A> AuthConfig<BR>
|
|
<A
|
|
HREF="directive-dict.html#Status"
|
|
REL="Help"
|
|
><STRONG>Status:</STRONG></A> core<P>
|
|
|
|
This directive selects the type of user authentication for a directory.
|
|
Only <CODE>Basic</CODE> and <CODE>Digest</CODE> are currently implemented.
|
|
<!--%plaintext <?INDEX {\tt Basic} authentication scheme> -->
|
|
It must be accompanied by <A HREF="#authname">AuthName</A> and
|
|
<A HREF="#require">Require</A> directives, and directives such as
|
|
<A HREF="mod_auth.html#authuserfile">AuthUserFile</A> and
|
|
<A HREF="mod_auth.html#authgroupfile">AuthGroupFile</A> to work.<P><HR>
|
|
|
|
<H2><A NAME="clearmodulelist">ClearModuleList directive</A></H2>
|
|
<!--%plaintext <?INDEX {\tt ClearModuleList} directive> -->
|
|
<A
|
|
HREF="directive-dict.html#Syntax"
|
|
REL="Help"
|
|
><STRONG>Syntax:</STRONG></A> ClearModuleList<BR>
|
|
<A
|
|
HREF="directive-dict.html#Context"
|
|
REL="Help"
|
|
><STRONG>Context:</STRONG></A> server config<BR>
|
|
<A
|
|
HREF="directive-dict.html#Status"
|
|
REL="Help"
|
|
><STRONG>Status:</STRONG></A> core<BR>
|
|
<A
|
|
HREF="directive-dict.html#Compatibility"
|
|
REL="Help"
|
|
><STRONG>Compatibility:</STRONG></A> ClearModuleList is only available in
|
|
Apache 1.2 and later<P>
|
|
|
|
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 <A HREF="#addmodule">AddModule</A> directive.<P><HR>
|
|
|
|
<H2><A NAME="contentdigest">ContentDigest directive</A></H2>
|
|
<!--%plaintext <?INDEX {\tt ContentDigest} directive> -->
|
|
<A
|
|
HREF="directive-dict.html#Syntax"
|
|
REL="Help"
|
|
><STRONG>Syntax:</STRONG></A> ContentDigest on|off<BR>
|
|
<A
|
|
HREF="directive-dict.html#Default"
|
|
REL="Help"
|
|
><STRONG>Default:</STRONG></A> <CODE>ContentDigest off</CODE><BR>
|
|
<A
|
|
HREF="directive-dict.html#Context"
|
|
REL="Help"
|
|
><STRONG>Context:</STRONG></A> server config, virtual host, directory,
|
|
.htaccess<BR>
|
|
<A
|
|
HREF="directive-dict.html#Override"
|
|
REL="Help"
|
|
><STRONG>Override:</STRONG></A> Options<BR>
|
|
<A
|
|
HREF="directive-dict.html#Status"
|
|
REL="Help"
|
|
><STRONG>Status:</STRONG></A> experimental<BR>
|
|
<A
|
|
HREF="directive-dict.html#Compatibility"
|
|
REL="Help"
|
|
><STRONG>Compatibility:</STRONG></A> ContentDigest is only available in
|
|
Apache 1.1 and later<P>
|
|
|
|
This directive enables the generation of <CODE>Content-MD5</CODE> headers
|
|
as defined in RFC1864 respectively RFC2068.<P>
|
|
|
|
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.<P>
|
|
|
|
The <CODE>Content-MD5</CODE> 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:
|
|
<PRE> Content-MD5: AuLb7Dp1rqtRtxz2m9kRpA==</PRE><P>
|
|
|
|
Note that this can cause performance problems on your server
|
|
since the message digest is computed on every request
|
|
(the values are not cached).<P>
|
|
|
|
<CODE>Content-MD5</CODE> 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.
|
|
|
|
<HR>
|
|
|
|
<H2><A NAME="defaulttype">DefaultType directive</A></H2>
|
|
<!--%plaintext <?INDEX {\tt DefaultType} directive> -->
|
|
<A
|
|
HREF="directive-dict.html#Syntax"
|
|
REL="Help"
|
|
><STRONG>Syntax:</STRONG></A> DefaultType <EM>MIME-type</EM><BR>
|
|
<A
|
|
HREF="directive-dict.html#Default"
|
|
REL="Help"
|
|
><STRONG>Default:</STRONG></A> <CODE>DefaultType text/html</CODE><BR>
|
|
<A
|
|
HREF="directive-dict.html#Context"
|
|
REL="Help"
|
|
><STRONG>Context:</STRONG></A> server config, virtual host, directory,
|
|
.htaccess<BR>
|
|
<A
|
|
HREF="directive-dict.html#Override"
|
|
REL="Help"
|
|
><STRONG>Override:</STRONG></A> FileInfo<BR>
|
|
<A
|
|
HREF="directive-dict.html#Status"
|
|
REL="Help"
|
|
><STRONG>Status:</STRONG></A> core<P>
|
|
|
|
There will be times when the server is asked to provide a document
|
|
whose type cannot be determined by its MIME types mappings.<P>
|
|
|
|
The server must inform the client of the content-type of the document, so in
|
|
the event of an unknown type it uses the <CODE>DefaultType</CODE>. For
|
|
example:
|
|
<BLOCKQUOTE><CODE>DefaultType image/gif</CODE></BLOCKQUOTE>
|
|
would be appropriate for a directory which contained many gif images
|
|
with filenames missing the .gif extension.<P><HR>
|
|
|
|
<H2><A NAME="directory"><Directory> directive</A></H2>
|
|
<!--%plaintext <?INDEX {\tt Directory} section directive> -->
|
|
<A
|
|
HREF="directive-dict.html#Syntax"
|
|
REL="Help"
|
|
><STRONG>Syntax:</STRONG></A> <Directory <EM>directory-path</EM>>
|
|
... </Directory> <BR>
|
|
<A
|
|
HREF="directive-dict.html#Context"
|
|
REL="Help"
|
|
><STRONG>Context:</STRONG></A> server config, virtual host<BR>
|
|
<A
|
|
HREF="directive-dict.html#Status"
|
|
REL="Help"
|
|
><STRONG>Status:</STRONG></A> Core. <P>
|
|
|
|
<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. <EM>Directory-path</EM> 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: <PRE>
|
|
<Directory /usr/local/httpd/htdocs>
|
|
Options Indexes FollowSymLinks
|
|
</Directory>
|
|
</PRE>
|
|
|
|
<P><STRONG>Apache 1.2 and above:</STRONG>
|
|
Extended regular expressions can also be used, with the addition of the
|
|
<CODE>~</CODE> character. For example:</P>
|
|
|
|
<PRE>
|
|
<Directory ~ "^/www/.*/[0-9]{3}">
|
|
</PRE>
|
|
|
|
would match directories in /www/ that consisted of three numbers.
|
|
|
|
<P>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
|
|
<A HREF="#accessfilename">.htaccess</A> files. For example, with
|
|
<BLOCKQUOTE><CODE>
|
|
<Directory /><BR>
|
|
AllowOverride None<BR>
|
|
</Directory><BR><BR>
|
|
<Directory /home/*><BR>
|
|
AllowOverride FileInfo<BR>
|
|
</Directory></CODE></BLOCKQUOTE>
|
|
for access to the document <CODE>/home/web/dir/doc.html</CODE> the
|
|
steps are:
|
|
<MENU>
|
|
<LI>Apply directive <CODE>AllowOverride None</CODE> (disabling
|
|
<CODE>.htaccess</CODE> files).
|
|
<LI>Apply directive <CODE>AllowOverride FileInfo</CODE> (for directory
|
|
<CODE>/home/web</CODE>).
|
|
<LI>Apply any FileInfo directives in <CODE>/home/web/.htaccess</CODE>
|
|
</MENU>
|
|
|
|
<P>
|
|
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
|
|
<BLOCKQUOTE><CODE>
|
|
<Directory ~ abc$><BR>
|
|
... directives here ...<BR>
|
|
</Directory><BR>
|
|
</CODE></BLOCKQUOTE>
|
|
Suppose that the filename being accessed is
|
|
<CODE>/home/abc/public_html/abc/index.html</CODE>. The server
|
|
considers each of <CODE>/</CODE>, <CODE>/home</CODE>, <CODE>/home/abc</CODE>,
|
|
<CODE>/home/abc/public_html</CODE>, and <CODE>/home/abc/public_html/abc</CODE>
|
|
in that order. In Apache 1.2, when
|
|
<CODE>/home/abc</CODE> 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 <CODE>.htaccess</CODE> files have
|
|
been applied. Then the regular expression will
|
|
match on <CODE>/home/abc/public_html/abc</CODE> and be applied.
|
|
|
|
<P>
|
|
|
|
<STRONG>
|
|
Note that the default Apache access for <Directory /> is
|
|
<SAMP>Allow from All</SAMP>. This means that Apache will serve any file
|
|
mapped from an URL. It is recommended that you change this with a block
|
|
such as
|
|
</STRONG>
|
|
<PRE>
|
|
<Directory />
|
|
Order Deny,Allow
|
|
Deny from All
|
|
</Directory>
|
|
</PRE>
|
|
<P>
|
|
<STRONG>
|
|
and then override this for directories you <EM>want</EM> accessible.
|
|
See the
|
|
<A
|
|
HREF="../misc/security_tips.html"
|
|
>Security Tips</A>
|
|
page for more details.
|
|
</STRONG>
|
|
</P>
|
|
|
|
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 <A HREF="#limit"><Limit></A> or
|
|
<A HREF="#limitexcept"><LimitExcept></A> section.
|
|
<P>
|
|
|
|
<STRONG>See also</STRONG>: <A HREF="../sections.html">How Directory,
|
|
Location and Files sections work</A> for an explanation of how these
|
|
different sections are combined when a request is received
|
|
|
|
<HR>
|
|
|
|
<H2><A NAME="directorymatch"><DirectoryMatch></A></H2>
|
|
<A
|
|
HREF="directive-dict.html#Syntax"
|
|
REL="Help"
|
|
><STRONG>Syntax:</STRONG></A> <DirectoryMatch <EM>regex</EM>>
|
|
... </DirectoryMatch> <BR>
|
|
<A
|
|
HREF="directive-dict.html#Context"
|
|
REL="Help"
|
|
><STRONG>Context:</STRONG></A> server config, virtual host<BR>
|
|
<A
|
|
HREF="directive-dict.html#Status"
|
|
REL="Help"
|
|
><STRONG>Status:</STRONG></A> Core.<BR>
|
|
<A
|
|
HREF="directive-dict.html#Compatibility"
|
|
REL="Help"
|
|
><STRONG>Compatibility:</STRONG></A> Available in Apache 1.3 and later
|
|
|
|
<P><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 <A
|
|
HREF="#directory"><Directory></A>. However, it takes as an
|
|
argument a regular expression. For example:</P>
|
|
|
|
<PRE>
|
|
<DirectoryMatch "^/www/.*/[0-9]{3}">
|
|
</PRE>
|
|
|
|
<P>would match directories in /www/ that consisted of three numbers.</P>
|
|
|
|
<P><STRONG>See Also:</STRONG>
|
|
<A HREF="#directory"><Directory></A> for a description of how
|
|
regular expressions are mixed in with normal <Directory>s.
|
|
<BR>
|
|
<STRONG>See also</STRONG>: <A HREF="../sections.html">How Directory,
|
|
Location and Files sections work</A> for an explanation of how these
|
|
different sections are combined when a request is received
|
|
|
|
<HR>
|
|
|
|
<H2><A NAME="documentroot">DocumentRoot directive</A></H2>
|
|
<!--%plaintext <?INDEX {\tt DocumentRoot} directive> -->
|
|
<A
|
|
HREF="directive-dict.html#Syntax"
|
|
REL="Help"
|
|
><STRONG>Syntax:</STRONG></A> DocumentRoot <EM>directory-path</EM><BR>
|
|
<A
|
|
HREF="directive-dict.html#Default"
|
|
REL="Help"
|
|
><STRONG>Default:</STRONG></A> <CODE>DocumentRoot
|
|
/usr/local/apache/htdocs</CODE><BR>
|
|
<A
|
|
HREF="directive-dict.html#Context"
|
|
REL="Help"
|
|
><STRONG>Context:</STRONG></A> server config, virtual host<BR>
|
|
<A
|
|
HREF="directive-dict.html#Status"
|
|
REL="Help"
|
|
><STRONG>Status:</STRONG></A> core<P>
|
|
|
|
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:
|
|
<BLOCKQUOTE><CODE>DocumentRoot /usr/web</CODE></BLOCKQUOTE>
|
|
then an access to <CODE>http://www.my.host.com/index.html</CODE> refers
|
|
to <CODE>/usr/web/index.html</CODE>.
|
|
|
|
<P>There appears to be a bug in mod_dir which causes problems when the
|
|
DocumentRoot has a trailing slash (<EM>i.e.</EM>, "DocumentRoot /usr/web/") so
|
|
please avoid that.
|
|
|
|
<P><HR>
|
|
|
|
<H2><A NAME="errordocument">ErrorDocument directive</A></H2>
|
|
<!--%plaintext <?INDEX {\tt ErrorDocument} directive> -->
|
|
<A
|
|
HREF="directive-dict.html#Syntax"
|
|
REL="Help"
|
|
><STRONG>Syntax:</STRONG></A> ErrorDocument <EM>error-code document</EM><BR>
|
|
<A
|
|
HREF="directive-dict.html#Context"
|
|
REL="Help"
|
|
><STRONG>Context:</STRONG></A> server config, virtual host, directory,
|
|
.htaccess<BR>
|
|
<A
|
|
HREF="directive-dict.html#Status"
|
|
REL="Help"
|
|
><STRONG>Status:</STRONG></A> core<BR>
|
|
<A
|
|
HREF="directive-dict.html#Override"
|
|
REL="Help"
|
|
><STRONG>Override:</STRONG></A> FileInfo<BR>
|
|
<A
|
|
HREF="directive-dict.html#Compatibility"
|
|
REL="Help"
|
|
><STRONG>Compatibility:</STRONG></A> The directory and .htaccess contexts
|
|
are only available in Apache 1.1 and later. The quoting syntax prior to
|
|
Apache 2.0 was different.<P>
|
|
|
|
In the event of a problem or error, Apache can be configured to do
|
|
one of four things,
|
|
|
|
<OL>
|
|
<LI>output a simple hardcoded error message
|
|
<LI>output a customized message
|
|
<LI>redirect to a local <em>URL-path</em> to handle the problem/error
|
|
<LI>redirect to an external <em>URL</em> to handle the problem/error
|
|
</OL>
|
|
|
|
<P>The first option is the default, while options 2-4 are configured
|
|
using the <CODE>ErrorDocument</CODE> 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.
|
|
|
|
<P>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:
|
|
<BLOCKQUOTE><CODE>
|
|
ErrorDocument 500 http://foo.example.com/cgi-bin/tester<BR>
|
|
ErrorDocument 404 /cgi-bin/bad_urls.pl<BR>
|
|
ErrorDocument 401 /subscription_info.html<BR>
|
|
ErrorDocument 403 "Sorry can't allow you access today"
|
|
</CODE></BLOCKQUOTE>
|
|
|
|
<P>Note that when you specify an <CODE>ErrorDocument</CODE> 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
|
|
<code>ErrorDocument 401</code>, the client will not know to prompt the
|
|
user for a password since it will not receive the 401 status
|
|
code. Therefore, <STRONG>if you use an "ErrorDocument 401" directive
|
|
then it must refer to a local document.</STRONG>
|
|
|
|
|
|
<P>Prior to version 2.0, messages were indicated by prefixing them
|
|
with a single unmatched double quote character.
|
|
|
|
<P>See Also: <A HREF="../custom-error.html">documentation of customizable
|
|
responses.</A><P><HR>
|
|
|
|
<H2><A NAME="errorlog">ErrorLog directive</A></H2>
|
|
<!--%plaintext <?INDEX {\tt ErrorLog} directive> -->
|
|
<A
|
|
HREF="directive-dict.html#Syntax"
|
|
REL="Help"
|
|
><STRONG>Syntax:</STRONG></A> ErrorLog <EM>file-path</EM>|syslog[:<em>facility</em>]
|
|
<BR>
|
|
<A
|
|
HREF="directive-dict.html#Default"
|
|
REL="Help"
|
|
><STRONG>Default:</STRONG></A> <CODE>ErrorLog logs/error_log</CODE> (Unix)<BR>
|
|
<A
|
|
HREF="directive-dict.html#Default"
|
|
REL="Help"
|
|
><STRONG>Default:</STRONG></A> <CODE>ErrorLog logs/error.log</CODE>
|
|
(Windows and OS/2)<BR>
|
|
<A
|
|
HREF="directive-dict.html#Context"
|
|
REL="Help"
|
|
><STRONG>Context:</STRONG></A> server config, virtual host<BR>
|
|
<A
|
|
HREF="directive-dict.html#Status"
|
|
REL="Help"
|
|
><STRONG>Status:</STRONG></A> core<P>
|
|
|
|
The error log directive sets the name of the file to which the server
|
|
will log any errors it encounters. If the <em>file-path</em> does not
|
|
begin with a slash (/) then it is assumed to be relative to the <A
|
|
HREF="#serverroot">ServerRoot</A>. If the <em>file-path</em> begins
|
|
with a pipe (|) then it is assumed to be a command to spawn to handle
|
|
the error log.
|
|
|
|
<P><STRONG>Apache 1.3 and above:</STRONG>
|
|
Using <CODE>syslog</CODE> instead of a filename enables logging via syslogd(8)
|
|
if the system supports it. The default is to use syslog facility
|
|
<CODE>local7</CODE>, but you can override this by using the
|
|
<CODE>syslog:</CODE><EM>facility</EM> syntax where <EM>facility</EM> can be
|
|
one of the names usually documented in syslog(1).
|
|
|
|
<P>
|
|
SECURITY: See the
|
|
<A HREF="../misc/security_tips.html#serverroot">security tips</A>
|
|
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.
|
|
|
|
<P><STRONG>See also:</STRONG> <A HREF="#loglevel">LogLevel</A> and
|
|
<a href="../logs.html">Apache Log Files</a>
|
|
<P><HR>
|
|
|
|
<H2><A NAME="files"><Files> directive</A></H2>
|
|
<A
|
|
HREF="directive-dict.html#Syntax"
|
|
REL="Help"
|
|
><STRONG>Syntax:</STRONG></A> <Files <EM>filename</EM>>
|
|
... </Files><BR>
|
|
<A
|
|
HREF="directive-dict.html#Context"
|
|
REL="Help"
|
|
><STRONG>Context:</STRONG></A> server config, virtual host, .htaccess<BR>
|
|
<A
|
|
HREF="directive-dict.html#Status"
|
|
REL="Help"
|
|
><STRONG>Status:</STRONG></A> core<BR>
|
|
<A
|
|
HREF="directive-dict.html#Compatibility"
|
|
REL="Help"
|
|
><STRONG>Compatibility:</STRONG></A> only available in Apache
|
|
1.2 and above.<P>
|
|
|
|
<P>The <Files> directive provides for access control by
|
|
filename. It is comparable to the <A
|
|
HREF="#directory"><Directory></A> directive and
|
|
<A HREF="#location"><Location></A> 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.
|
|
<CODE><Files></CODE> sections are processed in the
|
|
order they appear in the configuration file, after the
|
|
<Directory> sections and <CODE>.htaccess</CODE> 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.</P>
|
|
|
|
<P>The <EM>filename</EM> 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 <CODE>~</CODE> character. For example:</P>
|
|
|
|
<PRE>
|
|
<Files ~ "\.(gif|jpe?g|png)$">
|
|
</PRE>
|
|
|
|
would match most common Internet graphics formats. In Apache 1.3 and
|
|
later, <A HREF="#filesmatch"><FilesMatch></A> is preferred,
|
|
however.
|
|
|
|
<P>Note that unlike <A
|
|
HREF="#directory"><CODE><Directory></CODE></A> and <A
|
|
HREF="#location"><CODE><Location></CODE></A> sections,
|
|
<CODE><Files></CODE> sections can be used inside .htaccess
|
|
files. This allows users to control access to their own files, at a
|
|
file-by-file level.
|
|
|
|
<P>
|
|
|
|
<STRONG>See also</STRONG>: <A HREF="../sections.html">How Directory,
|
|
Location and Files sections work</A> for an explanation of how these
|
|
different sections are combined when a request is received
|
|
|
|
<HR>
|
|
|
|
<H2><A NAME="filesmatch"><FilesMatch></A></H2>
|
|
<A
|
|
HREF="directive-dict.html#Syntax"
|
|
REL="Help"
|
|
><STRONG>Syntax:</STRONG></A> <FilesMatch <EM>regex</EM>>
|
|
... </FilesMatch><BR>
|
|
<A
|
|
HREF="directive-dict.html#Context"
|
|
REL="Help"
|
|
><STRONG>Context:</STRONG></A> server config, virtual host, .htaccess<BR>
|
|
<A
|
|
HREF="directive-dict.html#Status"
|
|
REL="Help"
|
|
><STRONG>Status:</STRONG></A> core<BR>
|
|
<A
|
|
HREF="directive-dict.html#Compatibility"
|
|
REL="Help"
|
|
><STRONG>Compatibility:</STRONG></A> only available in Apache
|
|
1.3 and above.<P>
|
|
|
|
<P>The <FilesMatch> directive provides for access control by
|
|
filename, just as the <A HREF="#files"><Files></A> directive
|
|
does. However, it accepts a regular expression. For example:</P>
|
|
|
|
<PRE>
|
|
<FilesMatch "\.(gif|jpe?g|png)$">
|
|
</PRE>
|
|
|
|
<P>would match most common Internet graphics formats.</P>
|
|
|
|
<STRONG>See also</STRONG>: <A HREF="../sections.html">How Directory,
|
|
Location and Files sections work</A> for an explanation of how these
|
|
different sections are combined when a request is received
|
|
|
|
<HR>
|
|
|
|
<H2><A NAME="hostnamelookups">HostNameLookups directive</A></H2>
|
|
<!--%plaintext <?INDEX {\tt HostNameLookups} directive> -->
|
|
<A
|
|
HREF="directive-dict.html#Syntax"
|
|
REL="Help"
|
|
><STRONG>Syntax:</STRONG></A> HostNameLookups on|off|double<BR>
|
|
<A
|
|
HREF="directive-dict.html#Default"
|
|
REL="Help"
|
|
><STRONG>Default:</STRONG></A> <CODE>HostNameLookups off</CODE><BR>
|
|
<A
|
|
HREF="directive-dict.html#Context"
|
|
REL="Help"
|
|
><STRONG>Context:</STRONG></A> server config, virtual host, directory<BR>
|
|
<A
|
|
HREF="directive-dict.html#Status"
|
|
REL="Help"
|
|
><STRONG>Status:</STRONG></A> core<BR>
|
|
<A
|
|
HREF="directive-dict.html#Compatibility"
|
|
REL="Help"
|
|
><STRONG>Compatibility:</STRONG></A> <CODE>double</CODE> available only in
|
|
Apache
|
|
1.3 and above.<BR>
|
|
<A
|
|
HREF="directive-dict.html#Compatibility"
|
|
REL="Help"
|
|
><STRONG>Compatibility:</STRONG></A> Default was <CODE>on</CODE> prior to
|
|
Apache 1.3.<P>
|
|
|
|
This directive enables DNS lookups so that host names can be logged (and
|
|
passed to CGIs/SSIs in <CODE>REMOTE_HOST</CODE>).
|
|
The value <CODE>double</CODE> refers to doing double-reverse DNS.
|
|
That is, after a reverse lookup is performed, a forward lookup is then
|
|
performed on that result. At least one of the ip addresses in the forward
|
|
lookup must match the original address. (In "tcpwrappers" terminology
|
|
this is called <CODE>PARANOID</CODE>.)<P>
|
|
|
|
Regardless of the setting, when <A HREF="mod_access.html">mod_access</A>
|
|
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 <CODE>HostnameLookups double</CODE>. For example, if only
|
|
<CODE>HostnameLookups on</CODE> 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 <CODE>REMOTE_HOST</CODE>.<P>
|
|
|
|
The default for this directive was previously <CODE>on</CODE> in
|
|
versions of Apache prior to 1.3. It was changed to <CODE>off</CODE>
|
|
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
|
|
<CODE>off</CODE>, since DNS lookups can take considerable amounts of
|
|
time. The utility <a
|
|
href="../programs/logresolve.html">logresolve</a>, provided in the
|
|
<EM>/support</EM> directory, can be used to look up host names from
|
|
logged IP addresses offline.<P><HR>
|
|
|
|
<H2><A NAME="identitycheck">IdentityCheck directive</A></H2>
|
|
<!--%plaintext <?INDEX {\tt IdentityCheck} directive> -->
|
|
<A
|
|
HREF="directive-dict.html#Syntax"
|
|
REL="Help"
|
|
><STRONG>Syntax:</STRONG></A> IdentityCheck on|off<BR>
|
|
<A
|
|
HREF="directive-dict.html#Default"
|
|
REL="Help"
|
|
><STRONG>Default:</STRONG></A> <CODE>IdentityCheck off</CODE><BR>
|
|
<A
|
|
HREF="directive-dict.html#Context"
|
|
REL="Help"
|
|
><STRONG>Context:</STRONG></A> server config, virtual host, directory<BR>
|
|
<A
|
|
HREF="directive-dict.html#Status"
|
|
REL="Help"
|
|
><STRONG>Status:</STRONG></A> core<P>
|
|
|
|
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. <EM>Boolean</EM> is either
|
|
<CODE>on</CODE> or <CODE>off</CODE>.<P>
|
|
|
|
The information should not be trusted in any way except for rudimentary usage
|
|
tracking.<P>
|
|
|
|
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.
|
|
<P><HR>
|
|
|
|
<H2><A NAME="ifdefine"><IfDefine> directive</A></H2>
|
|
<A
|
|
HREF="directive-dict.html#Syntax"
|
|
REL="Help"
|
|
><STRONG>Syntax:</STRONG></A> <IfDefine [!]<EM>parameter-name</EM>> <EM>...</EM>
|
|
</IfDefine><BR>
|
|
<A
|
|
HREF="directive-dict.html#Default"
|
|
REL="Help"
|
|
><STRONG>Default:</STRONG></A> None<BR>
|
|
<A
|
|
HREF="directive-dict.html#Context"
|
|
REL="Help"
|
|
><STRONG>Context:</STRONG></A> all<BR>
|
|
<A
|
|
HREF="directive-dict.html#Status"
|
|
REL="Help"
|
|
><STRONG>Status:</STRONG></A> Core<BR>
|
|
<A
|
|
HREF="directive-dict.html#Compatibility"
|
|
REL="Help"
|
|
><STRONG>Compatibility:</STRONG></A> <IfDefine> is only available in
|
|
1.3.1 and later.<P>
|
|
|
|
<P>
|
|
|
|
The <IfDefine <EM>test</EM>>...</IfDefine>
|
|
section is used to mark directives that are conditional. The
|
|
directives within an IfDefine section are only
|
|
processed if the <EM>test</EM> is true. If <EM>test</EM>
|
|
is false, everything between the start and end markers
|
|
is ignored.<P>
|
|
|
|
The <EM>test</EM> in the <IfDefine> section directive
|
|
can be one of two forms:
|
|
|
|
<UL>
|
|
<LI><EM>parameter-name</EM>
|
|
<LI><CODE>!</CODE><EM>parameter-name</EM>
|
|
</UL>
|
|
|
|
<P>In the former case, the directives between the start and end markers are
|
|
only processed if the parameter named <EM>parameter-name</EM> is defined.
|
|
The second format reverses the test, and only processes the directives if
|
|
<EM>parameter-name</EM> is <STRONG>not</STRONG> defined.
|
|
|
|
<P>The <EM>parameter-name</EM> argument is a define as given on the
|
|
<CODE>httpd</CODE> command line via <CODE>-D</CODE><EM>parameter-</EM>, at the
|
|
time the server was started.
|
|
|
|
<P><IfDefine> sections are nest-able, which can be used to implement
|
|
simple multiple-parameter tests.
|
|
|
|
Example:
|
|
|
|
<PRE>
|
|
$ httpd -DReverseProxy ...
|
|
|
|
# httpd.conf
|
|
<IfDefine ReverseProxy>
|
|
LoadModule rewrite_module modules/mod_rewrite.so
|
|
LoadModule proxy_module modules/libproxy.so
|
|
</IfDefine>
|
|
</PRE>
|
|
|
|
<P> <HR>
|
|
|
|
<H2><A NAME="ifmodule"><IfModule> directive</A></H2>
|
|
<A
|
|
HREF="directive-dict.html#Syntax"
|
|
REL="Help"
|
|
><STRONG>Syntax:</STRONG></A> <IfModule [!]<EM>module-name</EM>>
|
|
<EM>...</EM>
|
|
</IfModule><BR>
|
|
<A
|
|
HREF="directive-dict.html#Default"
|
|
REL="Help"
|
|
><STRONG>Default:</STRONG></A> None<BR>
|
|
<A
|
|
HREF="directive-dict.html#Context"
|
|
REL="Help"
|
|
><STRONG>Context:</STRONG></A> all<BR>
|
|
<A
|
|
HREF="directive-dict.html#Status"
|
|
REL="Help"
|
|
><STRONG>Status:</STRONG></A> Core<BR>
|
|
<A
|
|
HREF="directive-dict.html#Compatibility"
|
|
REL="Help"
|
|
><STRONG>Compatibility:</STRONG></A> IfModule is only available in 1.2 and
|
|
later.<P>
|
|
|
|
<P>
|
|
|
|
The <IfModule <EM>test</EM>>...</IfModule>
|
|
section is used to mark directives that are conditional. The
|
|
directives within an IfModule section are only
|
|
processed if the <EM>test</EM> is true. If <EM>test</EM>
|
|
is false, everything between the start and end markers
|
|
is ignored.<P>
|
|
|
|
The <EM>test</EM> in the <IfModule> section directive
|
|
can be one of two forms:
|
|
|
|
<UL>
|
|
<LI><EM>module name</EM>
|
|
<LI>!<EM>module name</EM>
|
|
</UL>
|
|
|
|
<P>In the former case, the directives between the start and end markers
|
|
are only processed if the module named <EM>module name</EM> is compiled
|
|
in to Apache. The second format reverses the test, and only processes
|
|
the directives if <EM>module name</EM> is <STRONG>not</STRONG> compiled in.
|
|
|
|
<P>The <EM>module name</EM> argument is a module name as given as the file
|
|
name of the module, at the time it was compiled. For example,
|
|
<CODE>mod_rewrite.c</CODE>.
|
|
|
|
<P><IfModule> sections are nest-able, which can be used to implement
|
|
simple multiple-module tests.
|
|
|
|
<P> <HR>
|
|
|
|
<H2><A NAME="include">Include directive</A></H2>
|
|
<STRONG>Syntax:</STRONG> Include <EM>file-path</EM>|<em>directory-path</em><BR>
|
|
<A
|
|
HREF="directive-dict.html#Context"
|
|
REL="Help"
|
|
><STRONG>Context:</STRONG></A> server config<BR>
|
|
<A
|
|
HREF="directive-dict.html#Status"
|
|
REL="Help"
|
|
><STRONG>Status:</STRONG></A> Core<BR>
|
|
<A
|
|
HREF="directive-dict.html#Compatibility"
|
|
REL="Help"
|
|
><STRONG>Compatibility:</STRONG></A> Include is only available in Apache 1.3
|
|
and later.
|
|
<P>
|
|
This directive allows inclusion of other configuration files from within the
|
|
server configuration files.
|
|
|
|
<P>If <CODE>Include</CODE> 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.
|
|
|
|
<P> <HR>
|
|
|
|
<H2><A NAME="keepalive">KeepAlive directive</A></H2>
|
|
<STRONG>Syntax:</STRONG> KeepAlive on/off<BR>
|
|
<STRONG>Default:</STRONG> <CODE>KeepAlive On</CODE><BR>
|
|
<A
|
|
HREF="directive-dict.html#Context"
|
|
REL="Help"
|
|
><STRONG>Context:</STRONG></A> server config<BR>
|
|
<A
|
|
HREF="directive-dict.html#Status"
|
|
REL="Help"
|
|
><STRONG>Status:</STRONG></A> Core<BR>
|
|
<A
|
|
HREF="directive-dict.html#Compatibility"
|
|
REL="Help"
|
|
><STRONG>Compatibility:</STRONG></A> KeepAlive is only available in Apache
|
|
1.1 and later.<P>
|
|
|
|
<p>The Keep-Alive extension to HTTP/1.0 and the persistent connection
|
|
feature of HTTP/1.1 provide long-lived HTTP sessions which allow
|
|
multiple requests to be sent over the same TCP connection. In some
|
|
cases this has been shown to result in an almost 50% speedup in
|
|
latency times for HTML documents with many images. To enable
|
|
Keep-Alive connections in Apache 1.2 and later, set <code>KeepAlive
|
|
On</code>.</p>
|
|
|
|
<p>For HTTP/1.0 clients, Keep-Alive connections will only be used if
|
|
they are specifically requested by a client. In addition, a
|
|
Keep-Alive connection with an HTTP/1.0 client can only be used when
|
|
the length of the content is known in advance. This implies that
|
|
dynamic content such as CGI output, SSI pages, and server-generated
|
|
directory listings will generally not use Keep-Alive connections to
|
|
HTTP/1.0 clients. For HTTP/1.1 clients, persistent connections are
|
|
the default unless otherwise specified. If the client requests it,
|
|
chunked encoding will be used in order to send content of unknown
|
|
length over persistent connections.</p>
|
|
|
|
<p>See also <A
|
|
HREF="#maxkeepaliverequests">MaxKeepAliveRequests</A>.</P>
|
|
|
|
<HR>
|
|
|
|
<H2><A NAME="keepalivetimeout">KeepAliveTimeout directive</A></H2>
|
|
<A
|
|
HREF="directive-dict.html#Syntax"
|
|
REL="Help"
|
|
><STRONG>Syntax:</STRONG></A> KeepAliveTimeout <EM>seconds</EM><BR>
|
|
<A
|
|
HREF="directive-dict.html#Default"
|
|
REL="Help"
|
|
><STRONG>Default:</STRONG></A> <CODE>KeepAliveTimeout 15</CODE><BR>
|
|
<A
|
|
HREF="directive-dict.html#Context"
|
|
REL="Help"
|
|
><STRONG>Context:</STRONG></A> server config<BR>
|
|
<A
|
|
HREF="directive-dict.html#Status"
|
|
REL="Help"
|
|
><STRONG>Status:</STRONG></A> Core<BR>
|
|
<A
|
|
HREF="directive-dict.html#Compatibility"
|
|
REL="Help"
|
|
><STRONG>Compatibility:</STRONG></A> KeepAliveTimeout is only available in
|
|
Apache 1.1 and later.<P>
|
|
|
|
<p>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 <A
|
|
HREF="#timeout"><CODE>Timeout</CODE></A> directive applies.</p>
|
|
|
|
<p>Setting <code>KeepAliveTimeout</code> 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.</p>
|
|
|
|
|
|
<HR>
|
|
|
|
<H2><A NAME="limit"><Limit> directive</A></H2>
|
|
<!--%plaintext <?INDEX {\tt Limit} section directive> -->
|
|
<A
|
|
HREF="directive-dict.html#Syntax"
|
|
REL="Help"
|
|
><STRONG>Syntax:</STRONG></A>
|
|
<Limit <EM>method</em> [<em>method</EM>] ... > ... </Limit><BR>
|
|
<A
|
|
HREF="directive-dict.html#Context"
|
|
REL="Help"
|
|
><STRONG>Context:</STRONG></A> any<BR>
|
|
<A
|
|
HREF="directive-dict.html#Status"
|
|
REL="Help"
|
|
><STRONG>Status:</STRONG></A> core<P>
|
|
|
|
Access controls are normally effective for <STRONG>all</STRONG> access
|
|
methods, and this is the usual desired behaviour. <STRONG>In the
|
|
general case, access control directives should not be placed within a
|
|
<CODE><limit></CODE> section.</STRONG>
|
|
|
|
<P>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 <STRONG>will have no effect</STRONG>. The
|
|
following example applies the access control only to the methods POST,
|
|
PUT, and DELETE, leaving all other methods unprotected:
|
|
|
|
<BLOCKQUOTE><CODE>
|
|
<Limit POST PUT DELETE><BR>
|
|
Require valid-user<BR>
|
|
</Limit></CODE></BLOCKQUOTE>
|
|
|
|
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. <STRONG>The method name is
|
|
case-sensitive.</STRONG> If GET is used it will also restrict HEAD
|
|
requests.
|
|
|
|
<P><HR>
|
|
|
|
<H2><A NAME="limitexcept"><LimitExcept> directive</A></H2>
|
|
<!--%plaintext <?INDEX {\tt LimitExcept} section directive> -->
|
|
<A
|
|
HREF="directive-dict.html#Syntax"
|
|
REL="Help"
|
|
><STRONG>Syntax:</STRONG></A>
|
|
<LimitExcept <EM>method</em> [<em>method</EM>] ... > ... </LimitExcept><BR>
|
|
<A
|
|
HREF="directive-dict.html#Context"
|
|
REL="Help"
|
|
><STRONG>Context:</STRONG></A> any<BR>
|
|
<A
|
|
HREF="directive-dict.html#Status"
|
|
REL="Help"
|
|
><STRONG>Status:</STRONG></A> core<BR>
|
|
<A
|
|
HREF="directive-dict.html#Compatibility"
|
|
REL="Help"
|
|
><STRONG>Compatibility:</STRONG></A> Available in Apache 1.3.5 and later<P>
|
|
|
|
<LimitExcept> and </LimitExcept> are used to enclose a group of
|
|
access control directives which will then apply to any HTTP access method
|
|
<STRONG>not</STRONG> listed in the arguments; i.e., it is the opposite of a
|
|
<A HREF="#limit"><Limit></A> section and can be used to control both
|
|
standard and nonstandard/unrecognized methods. See the documentation for
|
|
<A HREF="#limit"><Limit></A> for more details.
|
|
|
|
<P><HR>
|
|
|
|
<H2><A NAME="limitrequestbody">LimitRequestBody directive</A></H2>
|
|
<!--%plaintext <?INDEX {\tt LimitRequestBody} directive> -->
|
|
<A
|
|
HREF="directive-dict.html#Syntax"
|
|
REL="Help"
|
|
><STRONG>Syntax:</STRONG></A> LimitRequestBody <EM>bytes</EM><BR>
|
|
<A
|
|
HREF="directive-dict.html#Default"
|
|
REL="Help"
|
|
><STRONG>Default:</STRONG></A> <CODE>LimitRequestBody 0</CODE><BR>
|
|
<A
|
|
HREF="directive-dict.html#Context"
|
|
REL="Help"
|
|
><STRONG>Context:</STRONG></A> server config, virtual host, directory,
|
|
.htaccess<BR>
|
|
<A
|
|
HREF="directive-dict.html#Status"
|
|
REL="Help"
|
|
><STRONG>Status:</STRONG></A> core<BR>
|
|
<A
|
|
HREF="directive-dict.html#Compatibility"
|
|
REL="Help"
|
|
><STRONG>Compatibility:</STRONG></A> LimitRequestBody is only available in
|
|
Apache 1.3.2 and later.
|
|
<P>
|
|
|
|
<p>This directive specifies the number of <em>bytes</em> from 0
|
|
(meaning unlimited) to 2147483647 (2GB) that are allowed in a request
|
|
body. The default value is defined by the compile-time constant
|
|
<CODE>DEFAULT_LIMIT_REQUEST_BODY</CODE> (0 as distributed).
|
|
<P>
|
|
|
|
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.
|
|
<P>
|
|
|
|
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.
|
|
<P>
|
|
|
|
<P><HR>
|
|
|
|
<H2><A NAME="limitrequestfields">LimitRequestFields directive</A></H2>
|
|
<!--%plaintext <?INDEX {\tt LimitRequestFields} directive> -->
|
|
<A
|
|
HREF="directive-dict.html#Syntax"
|
|
REL="Help"
|
|
><STRONG>Syntax:</STRONG></A> LimitRequestFields <EM>number</EM><BR>
|
|
<A
|
|
HREF="directive-dict.html#Default"
|
|
REL="Help"
|
|
><STRONG>Default:</STRONG></A> <CODE>LimitRequestFields 100</CODE><BR>
|
|
<A
|
|
HREF="directive-dict.html#Context"
|
|
REL="Help"
|
|
><STRONG>Context:</STRONG></A> server config<BR>
|
|
<A
|
|
HREF="directive-dict.html#Status"
|
|
REL="Help"
|
|
><STRONG>Status:</STRONG></A> core<BR>
|
|
<A
|
|
HREF="directive-dict.html#Compatibility"
|
|
REL="Help"
|
|
><STRONG>Compatibility:</STRONG></A> LimitRequestFields is only available in
|
|
Apache 1.3.2 and later.
|
|
<P>
|
|
|
|
<p><em>Number</em> is an integer from 0 (meaning unlimited) to 32767.
|
|
The default value is defined by the compile-time constant
|
|
<CODE>DEFAULT_LIMIT_REQUEST_FIELDS</CODE> (100 as distributed).
|
|
<P>
|
|
|
|
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.
|
|
<P>
|
|
|
|
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.<P>
|
|
|
|
<P><HR>
|
|
|
|
<H2><A NAME="limitrequestfieldsize">LimitRequestFieldsize directive</A></H2>
|
|
<!--%plaintext <?INDEX {\tt LimitRequestFieldsize} directive> -->
|
|
<A
|
|
HREF="directive-dict.html#Syntax"
|
|
REL="Help"
|
|
><STRONG>Syntax:</STRONG></A> LimitRequestFieldsize <EM>bytes</EM><BR>
|
|
<A
|
|
HREF="directive-dict.html#Default"
|
|
REL="Help"
|
|
><STRONG>Default:</STRONG></A> <CODE>LimitRequestFieldsize 8190</CODE><BR>
|
|
<A
|
|
HREF="directive-dict.html#Context"
|
|
REL="Help"
|
|
><STRONG>Context:</STRONG></A> server config<BR>
|
|
<A
|
|
HREF="directive-dict.html#Status"
|
|
REL="Help"
|
|
><STRONG>Status:</STRONG></A> core<BR>
|
|
<A
|
|
HREF="directive-dict.html#Compatibility"
|
|
REL="Help"
|
|
><STRONG>Compatibility:</STRONG></A> LimitRequestFieldsize is only available in
|
|
Apache 1.3.2 and later.
|
|
<P>
|
|
|
|
This directive specifies the number of <em>bytes</em> from 0 to the
|
|
value of the compile-time constant
|
|
<CODE>DEFAULT_LIMIT_REQUEST_FIELDSIZE</CODE> (8190 as distributed)
|
|
that will be allowed in an HTTP request header.
|
|
<P>
|
|
|
|
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.
|
|
<P>
|
|
|
|
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.<P>
|
|
|
|
<P><HR>
|
|
|
|
<H2><A NAME="limitrequestline">LimitRequestLine directive</A></H2>
|
|
<!--%plaintext <?INDEX {\tt LimitRequestLine} directive> -->
|
|
<A
|
|
HREF="directive-dict.html#Syntax"
|
|
REL="Help"
|
|
><STRONG>Syntax:</STRONG></A> LimitRequestLine <EM>bytes</EM><BR>
|
|
<A
|
|
HREF="directive-dict.html#Default"
|
|
REL="Help"
|
|
><STRONG>Default:</STRONG></A> <CODE>LimitRequestLine 8190</CODE><BR>
|
|
<A
|
|
HREF="directive-dict.html#Context"
|
|
REL="Help"
|
|
><STRONG>Context:</STRONG></A> server config<BR>
|
|
<A
|
|
HREF="directive-dict.html#Status"
|
|
REL="Help"
|
|
><STRONG>Status:</STRONG></A> core<BR>
|
|
<A
|
|
HREF="directive-dict.html#Compatibility"
|
|
REL="Help"
|
|
><STRONG>Compatibility:</STRONG></A> LimitRequestLine is only available in
|
|
Apache 1.3.2 and later.
|
|
<P>
|
|
|
|
This directive sets the number of <em>bytes</em> from 0 to the value
|
|
of the compile-time constant <CODE>DEFAULT_LIMIT_REQUEST_LINE</CODE>
|
|
(8190 as distributed) that will be allowed on the HTTP request-line.
|
|
<P>
|
|
|
|
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.
|
|
<P>
|
|
|
|
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.<P>
|
|
|
|
<P><HR>
|
|
|
|
|
|
<H2><A NAME="limitxmlrequestbody">LimitXMLRequestBody directive</A></H2>
|
|
<A
|
|
HREF="directive-dict.html#Syntax"
|
|
REL="Help"
|
|
><STRONG>Syntax:</STRONG></A> LimitXMLRequestBody <EM>number</EM><BR>
|
|
<A
|
|
HREF="directive-dict.html#Default"
|
|
REL="Help"
|
|
><STRONG>Default:</STRONG></A> <CODE>LimitXMLRequestBody 1000000</CODE><BR>
|
|
<A
|
|
HREF="directive-dict.html#Context"
|
|
REL="Help"
|
|
><STRONG>Context:</STRONG></A> server config<BR>
|
|
<A
|
|
HREF="directive-dict.html#Status"
|
|
REL="Help"
|
|
><STRONG>Status:</STRONG></A> core<BR>
|
|
|
|
<P>Limit (in bytes) on maximum size of an XML-based request body.</p>
|
|
|
|
<P><HR>
|
|
|
|
<H2><A NAME="location"><Location> directive</A></H2>
|
|
|
|
<A
|
|
HREF="directive-dict.html#Syntax"
|
|
REL="Help"
|
|
><STRONG>Syntax:</STRONG></A> <Location <EM>URL-path</EM>|<em>URL</em>>
|
|
... </Location><BR>
|
|
<A
|
|
HREF="directive-dict.html#Context"
|
|
REL="Help"
|
|
><STRONG>Context:</STRONG></A> server config, virtual host<BR>
|
|
<A
|
|
HREF="directive-dict.html#Status"
|
|
REL="Help"
|
|
><STRONG>Status:</STRONG></A> core<BR>
|
|
<A
|
|
HREF="directive-dict.html#Compatibility"
|
|
REL="Help"
|
|
><STRONG>Compatibility:</STRONG></A> Location is only available in Apache
|
|
1.1 and later.<P>
|
|
|
|
<P>The <Location> directive provides for access control by
|
|
URL. It is similar to the <A
|
|
HREF="#directory"><Directory></A> directive, and
|
|
starts a subsection which is terminated with a </Location>
|
|
directive. <CODE><Location></CODE> sections are processed in the
|
|
order they appear in the configuration file, after the
|
|
<Directory> sections and <CODE>.htaccess</CODE> files are
|
|
read, and after the <Files> sections.</P>
|
|
|
|
<P>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.
|
|
|
|
<P>For all origin (non-proxy) requests, the URL to be matched is
|
|
of the form <CODE>/path/</CODE>, and you should not include any
|
|
<CODE>http://servername</CODE> prefix. For proxy requests, the URL
|
|
to be matched is of the form <CODE>scheme://servername/path</CODE>,
|
|
and you must include the prefix.
|
|
|
|
<P>The URL may use wildcards In a wild-card string, `?' matches any
|
|
single character, and `*' matches any sequences of characters.
|
|
|
|
<P><STRONG>Apache 1.2 and above:</STRONG>
|
|
Extended regular expressions can also be used, with the addition of
|
|
the <CODE>~</CODE> character.
|
|
|
|
For example:</P>
|
|
|
|
<PRE>
|
|
<Location ~ "/(extra|special)/data">
|
|
</PRE>
|
|
|
|
<P>would match URLs that contained the substring "/extra/data" or
|
|
"/special/data". In Apache 1.3 and above, a new directive
|
|
<A HREF="#locationmatch"><LocationMatch></A> exists which
|
|
behaves identical to the regex version of
|
|
<CODE><Location></CODE>.
|
|
|
|
<P>The <CODE>Location</CODE> functionality is especially useful when
|
|
combined with the <CODE><A
|
|
HREF="mod_mime.html#sethandler">SetHandler</A></CODE> directive. For example,
|
|
to enable status requests, but allow them only
|
|
from browsers at foo.com, you might use:
|
|
|
|
<PRE>
|
|
<Location /status>
|
|
SetHandler server-status
|
|
Order Deny,Allow
|
|
Deny from all
|
|
Allow from .foo.com
|
|
</Location>
|
|
</PRE>
|
|
|
|
<P><STRONG>Apache 1.3 and above note about / (slash)</STRONG>: The slash
|
|
character has special
|
|
meaning depending on where in a URL it appears. People may be used
|
|
to its behaviour in the filesystem where multiple adjacent slashes are
|
|
frequently collapsed to a single slash (<EM>i.e.</EM>, <CODE>/home///foo</CODE>
|
|
is the same as <CODE>/home/foo</CODE>). In URL-space this is not
|
|
necessarily true. The <CODE><LocationMatch></CODE> directive
|
|
and the regex version of <CODE><Location></CODE> require you
|
|
to explicitly specify multiple slashes if that is your intention.
|
|
For example, <CODE><LocationMatch ^/abc></CODE> would match the
|
|
request URL <CODE>/abc</CODE> but not the request URL <CODE>//abc</CODE>.
|
|
The (non-regex) <CODE><Location></CODE> directive behaves
|
|
similarly when used for proxy requests. But when (non-regex)
|
|
<CODE><Location></CODE> is used for non-proxy requests it will
|
|
implicitly match multiple slashes with a single slash. For example,
|
|
if you specify <CODE><Location /abc/def></CODE> and the request
|
|
is to <CODE>/abc//def</CODE> then it will match.
|
|
|
|
<P>
|
|
<STRONG>See also</STRONG>: <A HREF="../sections.html">How Directory,
|
|
Location and Files sections work</A> for an explanation of how these
|
|
different sections are combined when a request is received
|
|
|
|
<HR>
|
|
|
|
<H2><A NAME="locationmatch"><LocationMatch></A></H2>
|
|
|
|
<A
|
|
HREF="directive-dict.html#Syntax"
|
|
REL="Help"
|
|
><STRONG>Syntax:</STRONG></A> <LocationMatch <EM>regex</EM>>
|
|
... </LocationMatch><BR>
|
|
<A
|
|
HREF="directive-dict.html#Context"
|
|
REL="Help"
|
|
><STRONG>Context:</STRONG></A> server config, virtual host<BR>
|
|
<A
|
|
HREF="directive-dict.html#Status"
|
|
REL="Help"
|
|
><STRONG>Status:</STRONG></A> core<BR>
|
|
<A
|
|
HREF="directive-dict.html#Compatibility"
|
|
REL="Help"
|
|
><STRONG>Compatibility:</STRONG></A> LocationMatch is only available in
|
|
Apache 1.3 and later.<P>
|
|
|
|
<P>The <LocationMatch> directive provides for access control by
|
|
URL, in an identical manner to <A
|
|
HREF="#location"><Location></A>. However, it takes a regular
|
|
expression as an argument instead of a simple string. For example:</P>
|
|
|
|
<PRE>
|
|
<LocationMatch "/(extra|special)/data">
|
|
</PRE>
|
|
|
|
<P>would match URLs that contained the substring "/extra/data" or
|
|
"/special/data".</P>
|
|
|
|
<STRONG>See also</STRONG>: <A HREF="../sections.html">How Directory,
|
|
Location and Files sections work</A> for an explanation of how these
|
|
different sections are combined when a request is received
|
|
|
|
<HR>
|
|
|
|
<H2><A NAME="loglevel">LogLevel directive</A></H2>
|
|
<A
|
|
HREF="directive-dict.html#Syntax"
|
|
REL="Help"
|
|
><STRONG>Syntax:</STRONG></A> LogLevel <EM>level</EM><BR>
|
|
<A
|
|
HREF="directive-dict.html#Default"
|
|
REL="Help"
|
|
><STRONG>Default:</STRONG></A> <CODE>LogLevel warn</CODE><BR>
|
|
<A
|
|
HREF="directive-dict.html#Context"
|
|
REL="Help"
|
|
><STRONG>Context:</STRONG></A> server config, virtual host<BR>
|
|
<A
|
|
HREF="directive-dict.html#Status"
|
|
REL="Help"
|
|
><STRONG>Status:</STRONG></A> core<BR>
|
|
<A
|
|
HREF="directive-dict.html#Compatibility"
|
|
REL="Help"
|
|
><STRONG>Compatibility:</STRONG></A> LogLevel is only available in 1.3 or
|
|
later.
|
|
|
|
<P>LogLevel adjusts the verbosity of the messages recorded in the
|
|
error logs (see <A HREF="#errorlog">ErrorLog</A> directive).
|
|
The following <EM>level</EM>s are available, in order of
|
|
decreasing significance:
|
|
|
|
<P><TABLE>
|
|
<TR><TH ALIGN="LEFT"><STRONG>Level</STRONG>
|
|
<TH ALIGN="LEFT"><STRONG>Description</STRONG>
|
|
<TR><TH><TH ALIGN="LEFT"><STRONG>Example</STRONG>
|
|
<TR><TD><CODE>emerg</CODE>
|
|
<TD>Emergencies - system is unusable.
|
|
<TR><TD><TD>"Child cannot open lock file. Exiting"
|
|
<TR><TD><CODE>alert</CODE>
|
|
<TD>Action must be taken immediately.
|
|
<TR><TD><TD>"getpwuid: couldn't determine user name from uid"
|
|
<TR><TD><CODE>crit</CODE>
|
|
<TD>Critical Conditions.
|
|
<TR><TD><TD>"socket: Failed to get a socket, exiting child"
|
|
<TR><TD><CODE>error</CODE>
|
|
<TD>Error conditions.
|
|
<TR><TD><TD>"Premature end of script headers"
|
|
<TR><TD><CODE>warn</CODE>
|
|
<TD>Warning conditions.
|
|
<TR><TD><TD>"child process 1234 did not exit, sending another SIGHUP"
|
|
<TR><TD><CODE>notice</CODE>
|
|
<TD>Normal but significant condition.
|
|
<TR><TD><TD>"httpd: caught SIGBUS, attempting to dump core in ..."
|
|
<TR><TD><CODE>info</CODE>
|
|
<TD>Informational.
|
|
<TR><TD><TD>"Server seems busy, (you may need to increase StartServers, or
|
|
Min/MaxSpareServers)..."
|
|
<TR><TD><CODE>debug</CODE>
|
|
<TD>Debug-level messages
|
|
<TR><TD><TD>"Opening config file ..."
|
|
</TABLE>
|
|
|
|
<P>When a particular level is specified, messages from all other levels
|
|
of higher significance will be reported as well. <EM>E.g.</EM>, when
|
|
<CODE>LogLevel info</CODE> is specified, then messages with log levels of
|
|
<CODE>notice</CODE> and <CODE>warn</CODE> will also be posted.
|
|
<P>
|
|
Using a level of at least <CODE>crit</CODE> is recommended.
|
|
<P><HR>
|
|
|
|
<H2><A NAME="maxkeepaliverequests">MaxKeepAliveRequests directive</A></H2>
|
|
<A
|
|
HREF="directive-dict.html#Syntax"
|
|
REL="Help"
|
|
><STRONG>Syntax:</STRONG></A> MaxKeepAliveRequests <EM>number</EM><BR>
|
|
<A
|
|
HREF="directive-dict.html#Default"
|
|
REL="Help"
|
|
><STRONG>Default:</STRONG></A> <CODE>MaxKeepAliveRequests 100</CODE><BR>
|
|
<A
|
|
HREF="directive-dict.html#Context"
|
|
REL="Help"
|
|
><STRONG>Context:</STRONG></A> server config<BR>
|
|
<A
|
|
HREF="directive-dict.html#Status"
|
|
REL="Help"
|
|
><STRONG>Status:</STRONG></A> core<BR>
|
|
<A
|
|
HREF="directive-dict.html#Compatibility"
|
|
REL="Help"
|
|
><STRONG>Compatibility:</STRONG></A> Only available in Apache
|
|
1.2 and later.
|
|
|
|
<P>The MaxKeepAliveRequests directive limits the number of requests
|
|
allowed per connection when <A HREF="#keepalive">KeepAlive</A> is
|
|
on. If it is set to "<CODE>0</CODE>", unlimited requests will be
|
|
allowed. We recommend that this setting be kept to a high value for
|
|
maximum server performance.</P><HR>
|
|
|
|
<H2><A NAME="namevirtualhost">NameVirtualHost directive</A></H2>
|
|
<!--%plaintext <?INDEX {\tt NameVirtualHost} directive> -->
|
|
<A
|
|
HREF="directive-dict.html#Syntax"
|
|
REL="Help"
|
|
><STRONG>Syntax:</STRONG></A> NameVirtualHost <EM>addr</EM>[:<EM>port</EM>]<BR>
|
|
<A
|
|
HREF="directive-dict.html#Context"
|
|
REL="Help"
|
|
><STRONG>Context:</STRONG></A> server config<BR>
|
|
<A
|
|
HREF="directive-dict.html#Status"
|
|
REL="Help"
|
|
><STRONG>Status:</STRONG></A> core<BR>
|
|
<A
|
|
HREF="directive-dict.html#Compatibility"
|
|
REL="Help"
|
|
><STRONG>Compatibility:</STRONG></A> NameVirtualHost is only available in
|
|
Apache 1.3 and later<P>
|
|
|
|
The NameVirtualHost directive is a required directive if you want to configure
|
|
<A HREF="../vhosts/">name-based virtual hosts</A>.<P>
|
|
|
|
Although <EM>addr</EM> can be hostname it is recommended that you always use
|
|
an IP address, <EM>e.g.</EM>
|
|
|
|
<BLOCKQUOTE><CODE>NameVirtualHost 111.22.33.44</CODE></BLOCKQUOTE>
|
|
|
|
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.<P>
|
|
|
|
Note: the "main server" and any _default_ servers will <STRONG>never</STRONG>
|
|
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).<P>
|
|
|
|
Optionally you can specify a port number on which the name-based
|
|
virtual hosts should be used, <EM>e.g.</EM>
|
|
|
|
<BLOCKQUOTE><CODE>NameVirtualHost 111.22.33.44:8080</CODE></BLOCKQUOTE>
|
|
|
|
<STRONG>See also:</STRONG>
|
|
<A HREF="../vhosts/">Apache Virtual Host documentation</A>
|
|
<HR>
|
|
|
|
<H2><A NAME="options">Options directive</A></H2>
|
|
<!--%plaintext <?INDEX {\tt Options} directive> -->
|
|
<A
|
|
HREF="directive-dict.html#Syntax"
|
|
REL="Help"
|
|
><STRONG>Syntax:</STRONG></A> Options [+|-]<em>option</em> [[+|-]<em>option</em>] ...</EM><BR>
|
|
<A
|
|
HREF="directive-dict.html#Context"
|
|
REL="Help"
|
|
><STRONG>Context:</STRONG></A> server config, virtual host, directory,
|
|
.htaccess<BR>
|
|
<A
|
|
HREF="directive-dict.html#Override"
|
|
REL="Help"
|
|
><STRONG>Override:</STRONG></A> Options<BR>
|
|
<A
|
|
HREF="directive-dict.html#Status"
|
|
REL="Help"
|
|
><STRONG>Status:</STRONG></A> core<P>
|
|
|
|
The Options directive controls which server features are available in
|
|
a particular directory.
|
|
<P>
|
|
<EM>option</EM> can be set to <CODE>None</CODE>, in which case none of
|
|
the extra features are enabled, or one or more of the following:
|
|
<DL>
|
|
<DT>All
|
|
<DD>All options except for MultiViews. This is the default setting.
|
|
<DT>ExecCGI
|
|
<DD>
|
|
<!--%plaintext <?INDEX {\tt ExecCGI} option> -->
|
|
Execution of CGI scripts is permitted.
|
|
<DT>FollowSymLinks
|
|
<DD>
|
|
<!--%plaintext <?INDEX {\tt FollowSymLinks} option> -->
|
|
The server will follow symbolic links in this directory.
|
|
<BR>
|
|
<STRONG>Note</STRONG>: even though the server follows the symlink it
|
|
does <EM>not</EM>
|
|
change the pathname used to match against <CODE><Directory></CODE>
|
|
sections.
|
|
<BR>
|
|
<STRONG>Note</STRONG>: this option gets ignored if set inside a
|
|
<Location> section.
|
|
|
|
<DT>Includes
|
|
<DD>
|
|
<!--%plaintext <?INDEX {\tt Includes} option> -->
|
|
Server-side includes are permitted.
|
|
<DT>IncludesNOEXEC
|
|
<DD>
|
|
<!--%plaintext <?INDEX {\tt IncludesNOEXEC} option> -->
|
|
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.
|
|
<DT>Indexes
|
|
<DD>
|
|
<!--%plaintext <?INDEX {\tt Indexes} option> -->
|
|
If a URL which maps to a directory is requested, and the there is no
|
|
DirectoryIndex (<EM>e.g.</EM>, index.html) in that directory, then the server will
|
|
return a formatted listing of the directory.
|
|
<DT>MultiViews
|
|
<DD>
|
|
<!--%plaintext <?INDEX {\tt MultiViews} option> -->
|
|
<A HREF="../content-negotiation.html">Content negotiated</A> MultiViews are
|
|
allowed.
|
|
<DT>SymLinksIfOwnerMatch
|
|
<DD>
|
|
<!--%plaintext <?INDEX {\tt SymLinksIfOwnerMatch} option> -->
|
|
The server will only follow symbolic links for which the target
|
|
file or directory is owned by the same user id as the link.
|
|
<BR>
|
|
<STRONG>Note</STRONG>: this option gets ignored if set inside a
|
|
<Location> section.
|
|
</DL>
|
|
|
|
Normally, if multiple <CODE>Options</CODE> could apply to a directory,
|
|
then the most specific one is taken complete; the options are not
|
|
merged. However if <EM>all</EM> the options on the <CODE>Options</CODE>
|
|
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. <P>
|
|
|
|
For example, without any + and - symbols:
|
|
|
|
<BLOCKQUOTE><CODE>
|
|
<Directory /web/docs> <BR>
|
|
Options Indexes FollowSymLinks<BR>
|
|
</Directory><BR>
|
|
<Directory /web/docs/spec> <BR>
|
|
Options Includes<BR>
|
|
</Directory>
|
|
</CODE></BLOCKQUOTE>
|
|
then only <CODE>Includes</CODE> will be set for the /web/docs/spec
|
|
directory. However if the second <CODE>Options</CODE> directive uses the +
|
|
and - symbols:<P>
|
|
|
|
<BLOCKQUOTE><CODE>
|
|
<Directory /web/docs> <BR>
|
|
Options Indexes FollowSymLinks<BR>
|
|
</Directory><BR>
|
|
<Directory /web/docs/spec> <BR>
|
|
Options +Includes -Indexes<BR>
|
|
</Directory>
|
|
</CODE></BLOCKQUOTE>
|
|
then the options <CODE>FollowSymLinks</CODE> and <CODE>Includes</CODE>
|
|
are set for the /web/docs/spec directory.<P>
|
|
|
|
<STRONG>Note:</STRONG> Using <CODE>-IncludesNOEXEC</CODE> or
|
|
<CODE>-Includes</CODE>
|
|
disables server-side includes completely regardless of the previous setting.<P>
|
|
|
|
The default in the absence of any other settings is <CODE>All</CODE>.<P>
|
|
<HR>
|
|
|
|
|
|
|
|
<H2><A NAME="port">Port directive</A></H2>
|
|
<!--%plaintext <?INDEX {\tt Port} directive> -->
|
|
<A
|
|
HREF="directive-dict.html#Syntax"
|
|
REL="Help"
|
|
><STRONG>Syntax:</STRONG></A> Port <EM>number</EM><BR>
|
|
<A
|
|
HREF="directive-dict.html#Default"
|
|
REL="Help"
|
|
><STRONG>Default:</STRONG></A> <CODE>Port 80</CODE><BR>
|
|
<A
|
|
HREF="directive-dict.html#Context"
|
|
REL="Help"
|
|
><STRONG>Context:</STRONG></A> server config<BR>
|
|
<A
|
|
HREF="directive-dict.html#Status"
|
|
REL="Help"
|
|
><STRONG>Status:</STRONG></A> core<P>
|
|
|
|
<EM>Number</EM> is a number from 0 to 65535; some port numbers
|
|
(especially below
|
|
1024) are reserved for particular protocols. See <CODE>/etc/services</CODE>
|
|
for a list of some defined ports; the standard port for the http protocol
|
|
is 80.<P>
|
|
|
|
The Port directive has two behaviors, the first of which is necessary for
|
|
NCSA backwards compatibility (and which is confusing in the context of
|
|
Apache).<P>
|
|
|
|
<UL>
|
|
<LI>
|
|
In the absence of any <A HREF="mpm_common.html#listen">Listen</A>
|
|
directives specifying a port number,
|
|
a Port directive given in the "main server"
|
|
(<EM>i.e.</EM>, outside any <A HREF="#virtualhost"><VirtualHost></A> section)
|
|
sets the network port on which the server listens.
|
|
If there are any Listen directives specifying
|
|
<CODE>:number</CODE> then Port has no effect on what address the server
|
|
listens at.
|
|
|
|
<LI>The Port directive
|
|
sets the <CODE>SERVER_PORT</CODE> environment variable (for
|
|
<A HREF="mod_cgi.html">CGI</A> and <A HREF="mod_include.html">SSI</A>),
|
|
and is used when the server must generate a URL that refers to itself
|
|
(for example when creating an external redirect to itself). This
|
|
behaviour is modified by
|
|
<A HREF="#usecanonicalname">UseCanonicalName</A>.
|
|
</UL>
|
|
|
|
The primary behaviour of Port should be considered to be similar to that of
|
|
the <A HREF="#servername">ServerName</A> directive. The ServerName
|
|
and Port together specify what you consider to be the <EM>canonical</EM>
|
|
address of the server.
|
|
(See also <A HREF="#usecanonicalname">UseCanonicalName</A>.)<P>
|
|
|
|
Port 80 is one of Unix's special ports. All ports numbered below 1024
|
|
are reserved for system use, <EM>i.e.</EM>, regular (non-root) users
|
|
cannot make use of them; instead they can only use higher port
|
|
numbers. To use port 80, you must start the server from the root
|
|
account. After binding to the port and before accepting requests,
|
|
Apache will change to a low privileged user as set by the <A
|
|
HREF="mpm_common.html#user">User directive</A>.<P>
|
|
|
|
If you cannot use port 80, choose any other unused port. Non-root users
|
|
will have to choose a port number higher than 1023, such as 8000.<P>
|
|
|
|
SECURITY: if you do start the server as root, be sure not to set <A
|
|
HREF="mpm_common.html#user">User</A> to root. If you run the server as
|
|
root whilst handling connections, your site may be open to a major
|
|
security attack.<P><HR>
|
|
|
|
<H2><A NAME="require">Require directive</A></H2>
|
|
<!--%plaintext <?INDEX {\tt Require} directive> -->
|
|
<A
|
|
HREF="directive-dict.html#Syntax"
|
|
REL="Help"
|
|
><STRONG>Syntax:</STRONG></A> Require <EM>entity-name</em> [<em>entity-name</em>] ...</EM><BR>
|
|
<A
|
|
HREF="directive-dict.html#Context"
|
|
REL="Help"
|
|
><STRONG>Context:</STRONG></A> directory, .htaccess<BR>
|
|
<A
|
|
HREF="directive-dict.html#Override"
|
|
REL="Help"
|
|
><STRONG>Override:</STRONG></A> AuthConfig<BR>
|
|
<A
|
|
HREF="directive-dict.html#Status"
|
|
REL="Help"
|
|
><STRONG>Status:</STRONG></A> core<P>
|
|
|
|
This directive selects which authenticated users can access a directory.
|
|
The allowed syntaxes are:
|
|
<UL>
|
|
<LI>Require user <EM>userid</em> [<em>userid</em>] ...<P>
|
|
Only the named users can access the directory.<P>
|
|
<LI>Require group <EM>group-name</em> [<em>group-name</em>] ...<P>
|
|
Only users in the named groups can access the directory.<P>
|
|
<LI>Require valid-user<P>
|
|
All valid users can access the directory.
|
|
</UL>
|
|
<P>
|
|
Require must be accompanied by <A HREF="#authname">AuthName</A> and
|
|
<A HREF="#authtype">AuthType</A> directives, and directives such as
|
|
<A HREF="mod_auth.html#authuserfile">AuthUserFile</A> and
|
|
<A HREF="mod_auth.html#authgroupfile">AuthGroupFile</A> (to define users and
|
|
groups) in order to work correctly. Example:
|
|
<BLOCKQUOTE><CODE>
|
|
AuthType Basic<BR>
|
|
AuthName "Restricted Directory"<BR>
|
|
AuthUserFile /web/users<BR>
|
|
AuthGroupFile /web/groups<BR>
|
|
Require group admin<BR>
|
|
</CODE></BLOCKQUOTE>
|
|
|
|
Access controls which are applied in this way are effective for
|
|
<STRONG>all</STRONG> methods. <STRONG>This is what is normally
|
|
desired.</STRONG> If you wish to apply access controls only to
|
|
specific methods, while leaving other methods unprotected, then place
|
|
the <CODE>Require</CODE> statement into a <A
|
|
HREF="#limit"><Limit></A> section<P>
|
|
<P>See also <A HREF="#satisfy">Satisfy</A> and <A HREF="mod_access.html">mod_access</A>.
|
|
<HR>
|
|
|
|
<H2><A NAME="rlimit">RLimitCPU</A> <A NAME="rlimitcpu">directive</A></H2>
|
|
<!--%plaintext <?INDEX {\tt RLimitCPU} directive> -->
|
|
<A
|
|
HREF="directive-dict.html#Syntax"
|
|
REL="Help"
|
|
><STRONG>Syntax:</STRONG></A> RLimitCPU <EM>number</EM>|max
|
|
[<em>number</em>|max]
|
|
<BR>
|
|
<A
|
|
HREF="directive-dict.html#Default"
|
|
REL="Help"
|
|
><STRONG>Default:</STRONG></A> <EM>Unset; uses operating system defaults</EM>
|
|
<BR>
|
|
<A
|
|
HREF="directive-dict.html#Context"
|
|
REL="Help"
|
|
><STRONG>Context:</STRONG></A> server config, virtual host<BR>
|
|
<A
|
|
HREF="directive-dict.html#Status"
|
|
REL="Help"
|
|
><STRONG>Status:</STRONG></A> core<BR>
|
|
<A
|
|
HREF="directive-dict.html#Compatibility"
|
|
REL="Help"
|
|
><STRONG>Compatibility:</STRONG></A> RLimitCPU is only available in Apache 1.2
|
|
and later. Moved in version 2.0 to the <A HREF="../mpm.html">MPMs</A>.<P>
|
|
|
|
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 <EM>max</EM> to indicate to the server
|
|
that the limit should be set to the maximum allowed by the operating system
|
|
configuration. Raising the maximum resource limit requires that the server
|
|
is running as root, or in the initial startup phase.<P>
|
|
|
|
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.<P>
|
|
|
|
CPU resource limits are expressed in seconds per process.<P>
|
|
|
|
See also <A HREF="#rlimitmem">RLimitMEM</A> or
|
|
<A HREF="#rlimitnproc">RLimitNPROC</A>.<P><HR>
|
|
|
|
<H2><A NAME="rlimitmem">RLimitMEM directive</A></H2>
|
|
<!--%plaintext <?INDEX {\tt RLimitMEM} directive> -->
|
|
<A
|
|
HREF="directive-dict.html#Syntax"
|
|
REL="Help"
|
|
><STRONG>Syntax:</STRONG></A> RLimitMEM <em>number</em>|max
|
|
[<em>number</em>|max]<br>
|
|
<A
|
|
HREF="directive-dict.html#Default"
|
|
REL="Help"
|
|
><STRONG>Default:</STRONG></A> <EM>Unset; uses operating system defaults</EM>
|
|
<BR>
|
|
<A
|
|
HREF="directive-dict.html#Context"
|
|
REL="Help"
|
|
><STRONG>Context:</STRONG></A> server config, virtual host<BR>
|
|
<A
|
|
HREF="directive-dict.html#Status"
|
|
REL="Help"
|
|
><STRONG>Status:</STRONG></A> core<BR>
|
|
<A
|
|
HREF="directive-dict.html#Compatibility"
|
|
REL="Help"
|
|
><STRONG>Compatibility:</STRONG></A> RLimitMEM is only available in Apache 1.2
|
|
and later. Moved in version 2.0 to the <A HREF="../mpm.html">MPMs</A>.<P>
|
|
|
|
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 <EM>max</EM> to indicate to the server that the
|
|
limit should be set to the maximum allowed by the operating system
|
|
configuration. Raising the maximum resource limit requires that the
|
|
server is running as root, or in the initial startup phase.<P>
|
|
|
|
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.<P>
|
|
|
|
Memory resource limits are expressed in bytes per process.<P>
|
|
|
|
See also <A HREF="#rlimitcpu">RLimitCPU</A> or
|
|
<A HREF="#rlimitnproc">RLimitNPROC</A>.<P><HR>
|
|
|
|
<H2><A NAME="rlimitnproc">RLimitNPROC directive</A></H2>
|
|
<!--%plaintext <?INDEX {\tt RLimitNPROC} directive> -->
|
|
<A
|
|
HREF="directive-dict.html#Syntax"
|
|
REL="Help"
|
|
><STRONG>Syntax:</STRONG></A> RLimitNPROC <em>number</em>|max
|
|
[<em>number</em>|max]<BR>
|
|
<A
|
|
HREF="directive-dict.html#Default"
|
|
REL="Help"
|
|
><STRONG>Default:</STRONG></A> <EM>Unset; uses operating system defaults</EM>
|
|
<BR>
|
|
<A
|
|
HREF="directive-dict.html#Context"
|
|
REL="Help"
|
|
><STRONG>Context:</STRONG></A> server config, virtual host<BR>
|
|
<A
|
|
HREF="directive-dict.html#Status"
|
|
REL="Help"
|
|
><STRONG>Status:</STRONG></A> core<BR>
|
|
<A
|
|
HREF="directive-dict.html#Compatibility"
|
|
REL="Help"
|
|
><STRONG>Compatibility:</STRONG></A> RLimitNPROC is only available in Apache
|
|
1.2 and later. Moved in version 2.0 to the <A HREF="../mpm.html">MPMs</A>.<P>
|
|
|
|
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 <code>max</code> to indicate to the server
|
|
that the limit should be set to the maximum allowed by the operating system
|
|
configuration. Raising the maximum resource limit requires that the server
|
|
is running as root, or in the initial startup phase.<P>
|
|
|
|
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.<P>
|
|
|
|
Process limits control the number of processes per user.<P>
|
|
|
|
Note: If CGI processes are <STRONG>not</STRONG> 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
|
|
<STRONG><EM>cannot fork</EM></STRONG> messages in the error_log.<P>
|
|
|
|
See also <A HREF="#rlimitmem">RLimitMEM</A> or
|
|
<A HREF="#rlimitcpu">RLimitCPU</A>.
|
|
|
|
<P><HR>
|
|
|
|
<H2><A NAME="satisfy">Satisfy directive</A></H2>
|
|
<!--%plaintext <?INDEX {\tt Satisfy} directive> -->
|
|
<A
|
|
HREF="directive-dict.html#Syntax"
|
|
REL="Help"
|
|
><STRONG>Syntax:</STRONG></A> Satisfy any|all<BR>
|
|
<A
|
|
HREF="directive-dict.html#Default"
|
|
REL="Help"
|
|
><STRONG>Default:</STRONG></A> Satisfy all<BR>
|
|
<A
|
|
HREF="directive-dict.html#Context"
|
|
REL="Help"
|
|
><STRONG>Context:</STRONG></A> directory, .htaccess<BR>
|
|
<A
|
|
HREF="directive-dict.html#Status"
|
|
REL="Help"
|
|
><STRONG>Status:</STRONG></A> core<BR>
|
|
<A
|
|
HREF="directive-dict.html#Compatibility"
|
|
REL="Help"
|
|
><STRONG>Compatibility:</STRONG></A> Satisfy is only available in Apache 1.2
|
|
and later<P>
|
|
|
|
Access policy if both <CODE>Allow</CODE> and <CODE>Require</CODE>
|
|
used. The parameter can be
|
|
either <EM>'all'</EM> or <EM>'any'</EM>. This directive is only useful
|
|
if access to a particular area is being restricted by both
|
|
username/password <EM>and</EM> client host address. In this case the
|
|
default behavior ("all") is to require that the client passes the
|
|
address access restriction <EM>and</EM> 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.
|
|
<P>
|
|
See also <A HREF="#require">Require</A> and
|
|
<A HREF="mod_access.html">mod_access</A>.
|
|
|
|
<P><HR>
|
|
|
|
<H2><A NAME="scriptinterpretersource">ScriptInterpreterSource directive</A></H2>
|
|
<!--%plaintext <?INDEX {\tt ScriptInterpreterSource} directive> -->
|
|
<A
|
|
HREF="directive-dict.html#Syntax"
|
|
REL="Help"
|
|
><STRONG>Syntax:</STRONG></A> ScriptInterpreterSource registry|script<BR>
|
|
<A
|
|
HREF="directive-dict.html#Default"
|
|
REL="Help"
|
|
><STRONG>Default:</STRONG></A> <CODE>ScriptInterpreterSource script</CODE>
|
|
<BR>
|
|
<A
|
|
HREF="directive-dict.html#Context"
|
|
REL="Help"
|
|
><STRONG>Context:</STRONG></A> directory, .htaccess<BR>
|
|
<A
|
|
HREF="directive-dict.html#Status"
|
|
REL="Help"
|
|
><STRONG>Status:</STRONG></A> core (Windows only)<P>
|
|
|
|
This directive is used to control how Apache 1.3.5 and later finds the interpreter
|
|
used to run CGI scripts. The default technique is to use the interpreter pointed to by
|
|
the #! line in the script. Setting ScriptInterpreterSource registry will cause the
|
|
Windows Registry to be searched using the script file extension (e.g., .pl) as a search key.
|
|
<P><HR>
|
|
|
|
<H2><A NAME="serveradmin">ServerAdmin directive</A></H2>
|
|
<!--%plaintext <?INDEX {\tt ServerAdmin} directive> -->
|
|
<A
|
|
HREF="directive-dict.html#Syntax"
|
|
REL="Help"
|
|
><STRONG>Syntax:</STRONG></A> ServerAdmin <EM>email-address</EM><BR>
|
|
<A
|
|
HREF="directive-dict.html#Context"
|
|
REL="Help"
|
|
><STRONG>Context:</STRONG></A> server config, virtual host<BR>
|
|
<A
|
|
HREF="directive-dict.html#Status"
|
|
REL="Help"
|
|
><STRONG>Status:</STRONG></A> core<P>
|
|
|
|
The ServerAdmin sets the e-mail address that the server includes in any
|
|
error messages it returns to the client.<P>
|
|
|
|
It may be worth setting up a dedicated address for this, <EM>e.g.</EM>
|
|
<BLOCKQUOTE><CODE>ServerAdmin www-admin@foo.bar.com</CODE></BLOCKQUOTE>
|
|
as users do not always mention that they are talking about the server!<P><HR>
|
|
|
|
<H2><A NAME="serveralias">ServerAlias directive</A></H2>
|
|
|
|
<A
|
|
HREF="directive-dict.html#Syntax"
|
|
REL="Help"
|
|
><STRONG>Syntax:</STRONG></A> ServerAlias <EM>hostname</em> [<em>hostname</em>] ...<BR>
|
|
<A
|
|
HREF="directive-dict.html#Context"
|
|
REL="Help"
|
|
><STRONG>Context:</STRONG></A> virtual host<BR>
|
|
<A
|
|
HREF="directive-dict.html#Status"
|
|
REL="Help"
|
|
><STRONG>Status:</STRONG></A> core<BR>
|
|
<A
|
|
HREF="directive-dict.html#Compatibility"
|
|
REL="Help"
|
|
><STRONG>Compatibility:</STRONG></A> ServerAlias is only available in Apache
|
|
1.1 and later.<P>
|
|
|
|
The ServerAlias directive sets the alternate names for a host, for use
|
|
with
|
|
<A HREF="../vhosts/name-based.html">name-based virtual hosts</A>.
|
|
|
|
<P><STRONG>See also:</STRONG>
|
|
<A HREF="../vhosts/">Apache Virtual Host documentation</A>
|
|
|
|
<HR>
|
|
|
|
<H2><A NAME="servername">ServerName directive</A></H2>
|
|
<!--%plaintext <?INDEX {\tt ServerName} directive> -->
|
|
<A
|
|
HREF="directive-dict.html#Syntax"
|
|
REL="Help"
|
|
><STRONG>Syntax:</STRONG></A> ServerName <EM>fully-qualified-domain-name</EM>
|
|
<BR>
|
|
<A
|
|
HREF="directive-dict.html#Context"
|
|
REL="Help"
|
|
><STRONG>Context:</STRONG></A> server config, virtual host<BR>
|
|
<A
|
|
HREF="directive-dict.html#Status"
|
|
REL="Help"
|
|
><STRONG>Status:</STRONG></A> core<P>
|
|
|
|
The ServerName directive sets the hostname of the server; this is
|
|
used when creating redirection URLs. If it is not specified, then the
|
|
server attempts to deduce it from its own IP address; however this may
|
|
not work reliably, or may not return the preferred hostname. For example:
|
|
<BLOCKQUOTE><CODE>ServerName www.example.com</CODE></BLOCKQUOTE>
|
|
would be used if the canonical (main) name of the actual machine
|
|
were <CODE>simple.example.com</CODE>.<P>
|
|
|
|
If you are using <A HREF="../vhosts/name-based.html">name-based
|
|
virtual hosts</A>, the <CODE>ServerName</CODE> inside a
|
|
<A HREF="#virtualhost"><CODE><VirtualHost></CODE></A>
|
|
section specifies what hostname must appear in the request's
|
|
<CODE>Host:</CODE> header to match this virtual host.<P>
|
|
|
|
<P><STRONG>See Also</STRONG>:<BR>
|
|
<A HREF="../dns-caveats.html">DNS Issues</A><BR>
|
|
<A HREF="../vhosts/">Apache virtual host documentation</A><BR>
|
|
<A HREF="#usecanonicalname">UseCanonicalName</A><BR>
|
|
<A HREF="#namevirtualhost">NameVirtualHost</A><BR>
|
|
<A HREF="#serveralias">ServerAlias</A><BR>
|
|
</P>
|
|
<HR>
|
|
|
|
<H2><A NAME="serverpath">ServerPath directive</A></H2>
|
|
|
|
<A
|
|
HREF="directive-dict.html#Syntax"
|
|
REL="Help"
|
|
><STRONG>Syntax:</STRONG></A> ServerPath <EM>directory-path</EM><BR>
|
|
<A
|
|
HREF="directive-dict.html#Context"
|
|
REL="Help"
|
|
><STRONG>Context:</STRONG></A> virtual host<BR>
|
|
<A
|
|
HREF="directive-dict.html#Status"
|
|
REL="Help"
|
|
><STRONG>Status:</STRONG></A> core<BR>
|
|
<A
|
|
HREF="directive-dict.html#Compatibility"
|
|
REL="Help"
|
|
><STRONG>Compatibility:</STRONG></A> ServerPath is only available in Apache
|
|
1.1 and later.<P>
|
|
|
|
The ServerPath directive sets the legacy URL pathname for a host, for
|
|
use with <A HREF="../vhosts/">name-based virtual hosts</A>.
|
|
|
|
<P><STRONG>See also:</STRONG>
|
|
<A HREF="../vhosts/">Apache Virtual Host documentation</A>
|
|
|
|
<HR>
|
|
|
|
<H2><A NAME="serverroot">ServerRoot directive</A></H2>
|
|
<!--%plaintext <?INDEX {\tt ServerRoot} directive> -->
|
|
<A
|
|
HREF="directive-dict.html#Syntax"
|
|
REL="Help"
|
|
><STRONG>Syntax:</STRONG></A> ServerRoot <EM>directory-path</EM><BR>
|
|
<A
|
|
HREF="directive-dict.html#Default"
|
|
REL="Help"
|
|
><STRONG>Default:</STRONG></A> <CODE>ServerRoot /usr/local/apache</CODE><BR>
|
|
<A
|
|
HREF="directive-dict.html#Context"
|
|
REL="Help"
|
|
><STRONG>Context:</STRONG></A> server config<BR>
|
|
<A
|
|
HREF="directive-dict.html#Status"
|
|
REL="Help"
|
|
><STRONG>Status:</STRONG></A> core<P>
|
|
|
|
The ServerRoot directive sets the directory in which the server lives.
|
|
Typically it will contain the subdirectories <CODE>conf/</CODE> and
|
|
<CODE>logs/</CODE>. Relative paths for other configuration files are taken
|
|
as relative to this directory.<P>
|
|
|
|
See also <A HREF="../invoking.html">the <CODE>-d</CODE> option to httpd</A>.<P>
|
|
See also <A HREF="../misc/security_tips.html#serverroot">the security tips</A>
|
|
for information on how to properly set permissions on the ServerRoot.<P>
|
|
|
|
<HR>
|
|
|
|
<H2><A NAME="serversignature">ServerSignature directive</A></H2>
|
|
<!--%plaintext <?INDEX {\tt ServerSignature} directive> -->
|
|
<A
|
|
HREF="directive-dict.html#Syntax"
|
|
REL="Help"
|
|
><STRONG>Syntax:</STRONG></A> ServerSignature On|Off|EMail<BR>
|
|
<A
|
|
HREF="directive-dict.html#Default"
|
|
REL="Help"
|
|
><STRONG>Default:</STRONG></A> <CODE>ServerSignature Off</CODE><BR>
|
|
<A
|
|
HREF="directive-dict.html#Context"
|
|
REL="Help"
|
|
><STRONG>Context:</STRONG></A> server config, virtual host, directory,
|
|
.htaccess<BR>
|
|
<A
|
|
HREF="directive-dict.html#Status"
|
|
REL="Help"
|
|
><STRONG>Status:</STRONG></A> core<BR>
|
|
<A
|
|
HREF="directive-dict.html#Compatibility"
|
|
REL="Help"
|
|
><STRONG>Compatibility:</STRONG></A> ServerSignature is only available in
|
|
Apache
|
|
1.3 and later.<P>
|
|
|
|
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.<BR>
|
|
The <SAMP>Off</SAMP> setting, which is the default, suppresses the
|
|
error line (and is therefore compatible with the behavior of
|
|
Apache-1.2 and below). The <SAMP>On</SAMP> setting simply adds a
|
|
line with the server version number and <A
|
|
HREF="#servername">ServerName</A> of the serving virtual host, and
|
|
the <SAMP>EMail</SAMP> setting additionally creates a "mailto:"
|
|
reference to the <A HREF="#serveradmin">ServerAdmin</A> of the
|
|
referenced document.
|
|
|
|
<HR>
|
|
|
|
<H2><A NAME="servertokens">ServerTokens directive</A></H2>
|
|
<!--%plaintext <?INDEX {\tt ServerTokens} directive> -->
|
|
<A
|
|
HREF="directive-dict.html#Syntax"
|
|
REL="Help"
|
|
><STRONG>Syntax:</STRONG></A> ServerTokens Minimal|ProductOnly|OS|Full<BR>
|
|
<A
|
|
HREF="directive-dict.html#Default"
|
|
REL="Help"
|
|
><STRONG>Default:</STRONG></A> <CODE>ServerTokens Full</CODE><BR>
|
|
<A
|
|
HREF="directive-dict.html#Context"
|
|
REL="Help"
|
|
><STRONG>Context:</STRONG></A> server config <BR>
|
|
<A
|
|
HREF="directive-dict.html#Status"
|
|
REL="Help"
|
|
><STRONG>Status:</STRONG></A> core<BR>
|
|
<A
|
|
HREF="directive-dict.html#Compatibility"
|
|
REL="Help"
|
|
><STRONG>Compatibility:</STRONG></A> ServerTokens is only available
|
|
in Apache 1.3 and later; the <code>ProductOnly</code> keyword is
|
|
only available in versions later than 1.3.12
|
|
|
|
<P>
|
|
This directive controls whether <SAMP>Server</SAMP> 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.
|
|
</P>
|
|
<DL>
|
|
<DT><CODE>ServerTokens Prod[uctOnly]</CODE>
|
|
</DT>
|
|
<DD>Server sends (<EM>e.g.</EM>): <SAMP>Server: Apache</SAMP>
|
|
</DD>
|
|
<DT><CODE>ServerTokens Min[imal]</CODE>
|
|
</DT>
|
|
<DD>Server sends (<EM>e.g.</EM>): <SAMP>Server: Apache/1.3.0</SAMP>
|
|
</DD>
|
|
<DT><CODE>ServerTokens OS</CODE>
|
|
</DT>
|
|
<DD>Server sends (<EM>e.g.</EM>): <SAMP>Server: Apache/1.3.0 (Unix)</SAMP>
|
|
</DD>
|
|
<DT><CODE>ServerTokens Full</CODE> (or not specified)
|
|
</DT>
|
|
<DD>Server sends (<EM>e.g.</EM>): <SAMP>Server: Apache/1.3.0 (Unix) PHP/3.0
|
|
MyMod/1.2</SAMP>
|
|
</DD>
|
|
</DL>
|
|
<P>
|
|
This setting applies to the entire server, and cannot be enabled or
|
|
disabled on a virtualhost-by-virtualhost basis.
|
|
</P>
|
|
|
|
<HR>
|
|
|
|
<H2><A NAME="setinputfilter">SetInputFilter directive</A></H2>
|
|
<P><A
|
|
HREF="directive-dict.html#Syntax"
|
|
REL="Help"
|
|
><STRONG>Syntax:</STRONG></A> SetInputFilter <EM>filter</EM>
|
|
[<EM>filter</EM>] ...<BR>
|
|
<A
|
|
HREF="directive-dict.html#Default"
|
|
REL="Help"
|
|
><STRONG>Default:</STRONG></A> none<BR>
|
|
<A
|
|
HREF="directive-dict.html#Context"
|
|
REL="Help"
|
|
><STRONG>Context:</STRONG></A> directory<BR>
|
|
<A
|
|
HREF="directive-dict.html#Status"
|
|
REL="Help"
|
|
><STRONG>Status:</STRONG></A> core</P>
|
|
|
|
<p>The <code>SetInputFilter</code> directive sets the filters
|
|
which will process client requests when they are received by the
|
|
server.</p>
|
|
|
|
<p>The order of the arguments determines the order in which the
|
|
filters will process the content.</p>
|
|
|
|
<p>See also the <a href="../filter.html">Filters</a> documentation.</p>
|
|
|
|
|
|
<P><HR>
|
|
<H2><A NAME="setoutputfilter">SetOutputFilter directive</A></H2>
|
|
<P><A
|
|
HREF="directive-dict.html#Syntax"
|
|
REL="Help"
|
|
><STRONG>Syntax:</STRONG></A> SetOutputFilter <EM>filter</EM>
|
|
[<EM>filter</EM>] ...<BR>
|
|
<A
|
|
HREF="directive-dict.html#Default"
|
|
REL="Help"
|
|
><STRONG>Default:</STRONG></A> none<BR>
|
|
<A
|
|
HREF="directive-dict.html#Context"
|
|
REL="Help"
|
|
><STRONG>Context:</STRONG></A> directory<BR>
|
|
<A
|
|
HREF="directive-dict.html#Status"
|
|
REL="Help"
|
|
><STRONG>Status:</STRONG></A> core</P>
|
|
|
|
<P>The <code>SetOutputFilter</code> directive sets the filters which
|
|
will process responses from the server before they are sent to the
|
|
client. For example, the following configuration will process
|
|
all files in the <code>/www/data/</code> directory for
|
|
server-side includes.</P>
|
|
|
|
<BLOCKQUOTE><CODE>
|
|
<Directory /www/data/><BR>
|
|
SetOutputFilter INCLUDES<BR>
|
|
</Directory>
|
|
</CODE></BLOCKQUOTE>
|
|
|
|
<p>The order of the arguments determines the order in which the
|
|
filters will process the content.</p>
|
|
|
|
<p>See also the <a href="../filter.html">Filters</a> documentation.</p>
|
|
|
|
<P><HR>
|
|
<H2><A NAME="timeout">TimeOut directive</A></H2>
|
|
<!--%plaintext <?INDEX {\tt TimeOut} directive> -->
|
|
<A
|
|
HREF="directive-dict.html#Syntax"
|
|
REL="Help"
|
|
><STRONG>Syntax:</STRONG></A> TimeOut <EM>number</EM><BR>
|
|
<A
|
|
HREF="directive-dict.html#Default"
|
|
REL="Help"
|
|
><STRONG>Default:</STRONG></A> <CODE>TimeOut 300</CODE><BR>
|
|
<A
|
|
HREF="directive-dict.html#Context"
|
|
REL="Help"
|
|
><STRONG>Context:</STRONG></A> server config<BR>
|
|
<A
|
|
HREF="directive-dict.html#Status"
|
|
REL="Help"
|
|
><STRONG>Status:</STRONG></A> core<P>
|
|
|
|
The TimeOut directive currently defines the amount of time Apache will
|
|
wait for three things:
|
|
|
|
<OL>
|
|
<LI>The total amount of time it takes to receive a GET request.
|
|
<LI>The amount of time between receipt of TCP packets on a POST or
|
|
PUT request.
|
|
<LI>The amount of time between ACKs on transmissions of TCP packets
|
|
in responses.
|
|
</OL>
|
|
|
|
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.
|
|
|
|
<P><HR>
|
|
|
|
<H2><A NAME="usecanonicalname">UseCanonicalName directive</A></H2>
|
|
<!--%plaintext <?INDEX {\tt UseCanonicalName} directive> -->
|
|
<A HREF="directive-dict.html#Syntax" REL="Help">
|
|
<STRONG>Syntax:</STRONG></A> UseCanonicalName on|off|dns<BR>
|
|
<A HREF="directive-dict.html#Default" REL="Help">
|
|
<STRONG>Default:</STRONG></A> <CODE>UseCanonicalName on</CODE><BR>
|
|
<A HREF="directive-dict.html#Context" REL="Help">
|
|
<STRONG>Context:</STRONG></A> server config, virtual host, directory<BR>
|
|
<A HREF="directive-dict.html#Override" REL="Help">
|
|
<STRONG>Override:</STRONG></A> Options<BR>
|
|
<A HREF="directive-dict.html#Compatibility" REL="Help">
|
|
<STRONG>Compatibility:</STRONG></A> UseCanonicalName is only available in
|
|
Apache 1.3 and later<P>
|
|
|
|
In many situations Apache has to construct a <EM>self-referential</EM>
|
|
URL. That is, a URL which refers back to the same server.
|
|
With <CODE>UseCanonicalName on</CODE> (and in all versions prior to
|
|
1.3) Apache will use the <A HREF="#servername">ServerName</A> and <A
|
|
HREF="#port">Port</A> directives to construct a canonical name for the
|
|
server. This name is used in all self-referential URLs, and for the
|
|
values of <CODE>SERVER_NAME</CODE> and <CODE>SERVER_PORT</CODE> in CGIs.
|
|
|
|
<P>With <CODE>UseCanonicalName off</CODE> Apache will form
|
|
self-referential URLs using the hostname and port supplied
|
|
by the client if any are supplied (otherwise it will use the
|
|
canonical name). These values are the same that are used to
|
|
implement <A HREF="../vhosts/name-based.html">name based virtual
|
|
hosts</A>, and are available with the same clients. The CGI variables
|
|
<CODE>SERVER_NAME</CODE> and <CODE>SERVER_PORT</CODE> will be constructed
|
|
from the client supplied values as well.
|
|
|
|
<P>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
|
|
<CODE>www</CODE>. You'll notice that if the users type a shortname,
|
|
and a URL which is a directory, such as <CODE>http://www/splat</CODE>,
|
|
<EM>without the trailing slash</EM> then Apache will redirect them to
|
|
<CODE>http://www.domain.com/splat/</CODE>. If you have authentication
|
|
enabled, this will cause the user to have to reauthenticate twice (once
|
|
for <CODE>www</CODE> and once again for <CODE>www.domain.com</CODE>).
|
|
But if <CODE>UseCanonicalName</CODE> is set off, then Apache will redirect
|
|
to <CODE>http://www/splat/</CODE>.
|
|
|
|
<P>There is a third option, <CODE>UseCanonicalName DNS</CODE>, which
|
|
is intended for use with mass IP-based virtual hosting to support
|
|
ancient clients that do not provide a <CODE>Host:</CODE> 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.
|
|
|
|
<P><STRONG>Warning:</STRONG> if CGIs make assumptions about the values of
|
|
<CODE>SERVER_NAME</CODE> 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 <CODE>SERVER_NAME</CODE> to construct
|
|
self-referential URLs then it should be just fine.
|
|
|
|
<P><STRONG>See also:</STRONG>
|
|
<A HREF="#servername">ServerName</A>,
|
|
<A HREF="#port">Port</A>
|
|
|
|
<P><HR>
|
|
|
|
<H2><A NAME="virtualhost"><VirtualHost> directive</A></H2>
|
|
<!--%plaintext <?INDEX {\tt VirtualHost} section directive> -->
|
|
<A
|
|
HREF="directive-dict.html#Syntax"
|
|
REL="Help"
|
|
><STRONG>Syntax:</STRONG></A> <VirtualHost <EM>addr</EM>[:<EM>port</EM>]
|
|
[<EM>addr</EM>[:<EM>port</EM>]] ...> ...
|
|
</VirtualHost> <BR>
|
|
<A
|
|
HREF="directive-dict.html#Context"
|
|
REL="Help"
|
|
><STRONG>Context:</STRONG></A> server config<BR>
|
|
<A
|
|
HREF="directive-dict.html#Status"
|
|
REL="Help"
|
|
><STRONG>Status:</STRONG></A> Core.<BR>
|
|
<A
|
|
HREF="directive-dict.html#Compatibility"
|
|
REL="Help"
|
|
><STRONG>Compatibility:</STRONG></A> Non-IP address-based Virtual Hosting only
|
|
available in Apache 1.1 and later.<BR>
|
|
<A
|
|
HREF="directive-dict.html#Compatibility"
|
|
REL="Help"
|
|
><STRONG>Compatibility:</STRONG></A> Multiple address support only available in
|
|
Apache 1.2 and later.<P>
|
|
|
|
<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. <EM>Addr</EM> can be
|
|
<MENU>
|
|
<LI>The IP address of the virtual host
|
|
<LI>A fully qualified domain name for the IP address of the virtual host.
|
|
</MENU> Example:
|
|
<BLOCKQUOTE>
|
|
<CODE>
|
|
<VirtualHost 10.1.2.3> <BR>
|
|
ServerAdmin webmaster@host.foo.com <BR>
|
|
DocumentRoot /www/docs/host.foo.com <BR>
|
|
ServerName host.foo.com <BR>
|
|
ErrorLog logs/host.foo.com-error_log <BR>
|
|
TransferLog logs/host.foo.com-access_log <BR>
|
|
</VirtualHost>
|
|
</CODE></BLOCKQUOTE>
|
|
|
|
Each VirtualHost must correspond to a different IP address, different port
|
|
number or a
|
|
different host name for the server, in the former case the server
|
|
machine must be configured to accept IP packets for multiple
|
|
addresses. (If the machine does not have multiple network interfaces,
|
|
then this can be accomplished with the <CODE>ifconfig alias</CODE>
|
|
command (if your OS supports it), or with kernel patches like <A
|
|
HREF="../misc/vif-info.html">VIF</A> (for SunOS(TM) 4.1.x)).<P>
|
|
|
|
The special name <CODE>_default_</CODE> 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.<P>
|
|
|
|
You can specify a <CODE>:port</CODE> to change the port that is matched.
|
|
If unspecified then it defaults to the same port as the most recent
|
|
<CODE><A HREF="#port">Port</A></CODE> statement of the main server. You
|
|
may also specify <CODE>:*</CODE> to match all ports on that address.
|
|
(This is recommended when used with <CODE>_default_</CODE>.)<P>
|
|
|
|
<STRONG>SECURITY</STRONG>: See the
|
|
<A HREF="../misc/security_tips.html">security tips</A>
|
|
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.
|
|
|
|
<P><STRONG>NOTE</STRONG>: The use of <VirtualHost> does
|
|
<STRONG>not</STRONG> affect what addresses Apache listens on. You may
|
|
need to ensure that Apache is listening on the correct addresses using
|
|
<A HREF="mpm_common.html#listen">Listen</A>.
|
|
|
|
<P><STRONG>See also:</STRONG>
|
|
<A HREF="../vhosts/">Apache Virtual Host documentation</A><BR>
|
|
<STRONG>See also:</STRONG>
|
|
<A HREF="../dns-caveats.html">Warnings about DNS and Apache</A><BR>
|
|
<STRONG>See also:</STRONG>
|
|
<A HREF="../bind.html">Setting which addresses and ports Apache uses</A><BR>
|
|
<STRONG>See also</STRONG>: <A HREF="../sections.html">How Directory,
|
|
Location and Files sections work</A> for an explanation of how these
|
|
different sections are combined when a request is received
|
|
</P>
|
|
|
|
<!--#include virtual="footer.html" -->
|
|
</BODY>
|
|
</HTML>
|
|
|