--- /dev/null
+<!--%hypertext -->
+<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
+<HTML>
+<HEAD>
+<TITLE>Apache Core Features</TITLE>
+</HEAD>
+
+<BODY>
+<IMG SRC="../images/apache_sub.gif" ALT="">
+<!--/%hypertext -->
+<H1>Apache Core Features</h1>
+
+These configuration parameters control the core Apache features, and are
+always available.
+
+<!--%hypertext -->
+<ul>
+<li><A HREF="#accessconfig">AccessConfig</A>
+<li><A HREF="#accessfilename">AccessFileName</A>
+<li><A HREF="#allowoverride">AllowOverride</A>
+<li><A HREF="#authname">AuthName</A>
+<li><A HREF="#authtype">AuthType</A>
+<li><A HREF="#bindaddress">BindAdress</A>
+<li><A HREF="#defaulttype">DefaultType</A>
+<li><A HREF="#directory"><Directory></A>
+<li><A HREF="#documentroot">DocumentRoot</A>
+<li><A HREF="#errordocument">ErrorDocument</A>
+<li><A HREF="#errorlog">ErrorLog</A>
+<li><A HREF="#group">Group</A>
+<li><A HREF="#identitycheck">IdentityCheck</A>
+<li><A HREF="#keepalive">KeepAlive</A>
+<li><A HREF="#keepalivetimeout">KeepAliveTimeout</A>
+<li><A HREF="#limit"><Limit></A>
+<li><A HREF="#listen">Listen;</A>
+<li><A HREF="#location"><Location></A>
+<li><A HREF="#maxclients">MaxClients</A>
+<li><A HREF="#maxrequestsperchild">MaxRequestsPerChild</A>
+<li><A HREF="#maxspareservers">MaxSpareServers</A>
+<li><A HREF="#minspareservers">MinSpareServers</A>
+<li><A HREF="#options">Options</A>
+<li><A HREF="#pidfile">PidFile</A>
+<li><A HREF="#port">Port</A>
+<li><A HREF="#require">require</A>
+<li><A HREF="#resourceconfig">ResourceConfig</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="#servertype">ServerType</A>
+<li><A HREF="#startservers">StartServers</A>
+<li><A HREF="#timeout">TimeOut</A>
+<li><A HREF="#user">User</A>
+<li><A HREF="#virtualhost"><VirtualHost></A>
+</ul>
+<hr>
+<!--/%hypertext -->
+
+<A name="accessconfig"><h2>AccessConfig directive</h2></A>
+<!--%plaintext <?INDEX {\tt AccessConfig} directive> -->
+<strong>Syntax:</strong> AccessConfig <em>filename</em><br>
+<strong>Default:</strong> <code>AccessConfig conf/access.conf</code><br>
+<strong>Context:</strong> server config, virtual host<br>
+<strong>Status:</strong> core<p>
+
+The server will read this file for more directives after reading the
+<A HREF="#resourceconfig">ResourceConfig</A> file. <em>Filename</em> is
+relative to the <A HREF="#serverroot">ServerRoot</A>.
+This feature can be disabled using:
+<blockquote><code>AccessConfig /dev/null</code></blockquote>
+Historically, this file only contained
+<A HREF="#directory"><Directory></A> sections; in fact it can now
+contain any server directive allowed in the <em>server config</em> context.
+<p><hr>
+
+<A name="accessfilename"><h2>AccessFileName directive</h2></A>
+<!--%plaintext <?INDEX {\tt AccessFileName} directive> -->
+<strong>Syntax:</strong> AccessFileName <em>filename</em><br>
+<strong>Default:</strong> <code>AccessFileName .htaccess</code><br>
+<strong>Context:</strong> server config, virtual host<br>
+<strong>Status:</strong> core<p>
+
+When returning a document to the client the server looks for an
+access control file with this name 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><hr>
+
+<A name="allowoverride"><h2>AllowOverride directive</h2></A>
+<!--%plaintext <?INDEX {\tt AllowOverride} directive> -->
+<strong>Syntax:</strong> AllowOverride <em>override override ...</em><br>
+<strong>Default:</strong> <code>AllowOverride All</code><br>
+<strong>Context:</strong> directory<br>
+<strong>Status:</strong> core<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>
+
+<em>Override</em> can be set to <code>None</code>, in which case the server
+will not read the file, <code>All</code> in which case the server will
+allow all the directives, or one or more of the following:
+<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> and
+<A HREF="#require">require</A>).
+<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> and
+<A HREF="mod_negotiation.html#languagepriority">LanguagePriority</A>).
+<dt>Indexes
+<dd>
+<!--%plaintext <?INDEX {\tt Indexes} override> -->
+Allow use of the directives controlling directory indexing
+(<A HREF="mod_dir.html#adddescription">AddDescription</A>,
+<A HREF="mod_dir.html#addicon">AddIcon</A>,
+<A HREF="mod_dir.html#addiconbyencoding">AddIconByEncoding</A>,
+<A HREF="mod_dir.html#addiconbytype">AddIconByType</A>,
+<A HREF="mod_dir.html#defaulticon">DefaultIcon</A>,
+<A HREF="mod_dir.html#directoryindex">DirectoryIndex</A>,
+<A HREF="mod_dir.html#fancyindexing">FancyIndexing</A>,
+<A HREF="mod_dir.html#headername">HeaderName</A>,
+<A HREF="mod_dir.html#indexignore">IndexIgnore</A>,
+<A HREF="mod_dir.html#indexoptions">IndexOptions</A> and
+<A HREF="mod_dir.html#readmename">ReadmeName</A>).
+<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><hr>
+
+<A name="authname"><h2>AuthName directive</h2></A>
+<!--%plaintext <?INDEX {\tt AuthName} directive> -->
+<strong>Syntax:</strong> AuthName <em>auth-domain</em><br>
+<strong>Context:</strong> directory, .htaccess<br>
+<strong>Override:</strong> AuthConfig<br>
+<strong>Status:</strong> 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.
+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>
+
+<A name="authtype"><h2>AuthType directive</h2></A>
+<!--%plaintext <?INDEX {\tt AuthType} directive> -->
+<strong>Syntax:</strong> AuthType <em>type</em><br>
+<strong>Context:</strong> directory, .htaccess<br>
+<strong>Override:</strong> AuthConfig<br>
+<strong>Status:</strong> core<p>
+
+This directive selects the type of user authentication for a directory.
+Only <code>Basic</code> is 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>
+
+
+<A name="bindaddress"><h2>BindAddress directive</h2></A>
+<!--%plaintext <?INDEX {\tt BindAddress} directive> -->
+<strong>Syntax:</strong> BindAddress <em>saddr</em><br>
+<strong>Default:</strong> <code>BindAddress *</code><br>
+<strong>Context:</strong> server config<br>
+<strong>Status:</strong> core<p>
+
+A Unix® http server can either listen on for connections to every
+IP address of the server machine, or just one IP address of the server
+machine. <em>Saddr</em> can be
+
+<menu>
+<li>*
+<li>An IP address
+<li>A fully-qualified internet domain name
+</menu>
+If the value is *, then the server will listen for connections on
+every IP address, otherwise it will only listen on the IP address
+specified. <p>
+
+This option can be used as an alternative method for supporting
+<A HREF="virtual-host.html">virtual hosts</A> instead of using
+<A HREF="#virtualhost"><VirtualHost></A> sections.<p><hr>
+
+<p><strong>See Also:</strong>
+<a href="bind.html">Setting which addresses and ports Apache uses</a></p>
+
+<A name="defaulttype"><h2>DefaultType directive</h2></A>
+<!--%plaintext <?INDEX {\tt DefaultType} directive> -->
+<strong>Syntax:</strong> DefaultType <em>mime-type</em><br>
+<strong>Default:</strong> <code>DefaultType text/html</code><br>
+<strong>Context:</strong> server config, virtual host, directory, .htaccess<br>
+<strong>Override:</strong> FileInfo<br>
+<strong>Status:</strong> 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>
+
+<A name="directory"><h2><Directory> directive</h2></A>
+<!--%plaintext <?INDEX {\tt Directory} section directive> -->
+<strong>Syntax:</strong> <Directory <em>directory</em>> ...
+</Directory> <br>
+<strong>Context:</strong> server config, virtual host<br>
+<strong>Status:</strong> 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</em> is either the full path to a directory,
+or a wildcard string. In a wildcard string, `?' matches any single character,
+and `*' matches any sequences of characters. Example:
+<blockquote>
+<code>
+<Directory /usr/local/httpd/htdocs><br>
+Options Indexes FollowSymLinks<br>
+</Directory></code></blockquote>
+If multiple 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>
+</Directoy><br><br>
+<Directory /home/*><br>
+AllowOverride FileInfo<br>
+</Directory></code></blockquote>
+The 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>
+
+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> section.
+<p><hr>
+
+<A NAME="documentroot"><h2>DocumentRoot directive</h2></A>
+<!--%plaintext <?INDEX {\tt DocumentRoot} directive> -->
+<strong>Syntax:</strong> DocumentRoot <em>directory-filename</em><br>
+<strong>Default:</strong> <code>DocumentRoot
+/usr/local/etc/httpd/htdocs</code><br>
+<strong>Context:</strong> server config, virtual host<br>
+<strong>Status:</strong> 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 (i.e. "DocumentRoot /usr/web/") so
+please avoid that.
+
+<p><hr>
+
+<A name="errordocument"><h2>ErrorDocument directive</h2></A>
+<!--%plaintext <?INDEX {\tt ErrorDocument} directive> -->
+<strong>Syntax:</strong> ErrorDocument <em>error-code document</em><br>
+<strong>Context</strong> server config, virtual host, directory, .htaccess<br>
+<strong>Status:</strong> core<br>
+<strong>Compatibility:</strong> The directory and .htaccess contexts
+are only available in Apache 1.1 and later.<p>
+
+In the event of a problem or error, Apache can be configured to do
+one of four things,
+
+<OL>
+<LI>behave like NCSA httpd 1.3
+<LI>output a customized message
+<LI>redirect to a local URL to handle the problem/error
+<LI>redirect to an external URL to handle the problem/error
+</OL>
+
+<P>2-4 are configured using <CODE>ErrorDocument</CODE>, which
+is followed by the HTTP response code and a message or URL.
+
+<P><em>Messages</em> in this context, begin with a single quote
+(<code>"</code>), which does not form part of the message itself. Apache will
+sometime offer additional information regarding the problem/error. This can be
+embedded into the message using <code>%s</code>
+
+<P>URLs will begin with a slash (/) for local URLs, or will be a full
+URL which the client can resolve. Examples:
+<blockquote><code>
+ErrorDocument 500 /cgi-bin/tester<br>
+ErrorDocument 404 /cgi-bin/bad_urls.pl<br>
+ErrorDocument 401 http://www2.foo.bar/subscription_info.html<br>
+ErrorDocument 403 "Sorry can't allow you access today
+</code></blockquote>
+
+See Also: <A HREF="custom-error.html">documentation of customizable
+responses.</A><p><hr>
+
+<A name="errorlog"><h2>ErrorLog directive</h2></A>
+<!--%plaintext <?INDEX {\tt ErrorLog} directive> -->
+<strong>Syntax:</strong> ErrorLog <em>filename</em><br>
+<strong>Default:</strong> <code>ErrorLog logs/error_log</code><br>
+<strong>Context:</strong> server config, virtual host<br>
+<strong>Status:</strong> core<p>
+
+The error log directive sets the name of the file to which the server will log
+any errors it encounters. If the filename does not begin with a slash (/)
+then it is assumed to be relative to the <A HREF="#serverroot">ServerRoot</A>.
+Example:
+<blockquote><code>ErrorLog /dev/null</code></blockquote>
+This effectively turns off error logging.<p><hr>
+
+<A name="group"><h2>Group directive</h2></A>
+<!--%plaintext <?INDEX {\tt Group} directive> -->
+<strong>Syntax:</strong> Group <em>unix-group</em><br>
+<strong>Default:</strong> <code>Group #-1</code><br>
+<strong>Context:</strong> server config<br>
+<strong>Status:</strong> core<p>
+
+The Group directive sets the group under which the server will answer requests.
+In order to use this directive, the standalone server must be run initially
+as root. <em>Unix-group</em> is one of:
+<dl>
+<dt>A group name
+<dd>Refers to the given group by name.
+<dt># followed by a group number.
+<dd>Refers to a group by its number.
+</dl>
+
+It is recommended that you set up a new group specifically for running the
+server. Some admins use user <code>nobody</code>, but this is not always
+possible or desirable.<p>
+
+Note: if you start the server as a non-root user, it will fail to change
+to the specified, and will instead continue to run as the group of the
+original user. <p>
+
+SECURITY: See <A HREF="#user">User</A> for a discussion of the security
+considerations.<p><hr>
+
+<A name="identitycheck"><h2>IdentityCheck directive</h2></A>
+<!--%plaintext <?INDEX {\tt IdentityCheck} directive> -->
+<strong>Syntax:</strong> IdentityCheck <em>boolean</em><br>
+<strong>Default:</strong> <code>IdentityCheck off</code><br>
+<strong>Context:</strong> server config, virtual host, directory, .htaccess<br>
+<strong>Status:</strong> core<p>
+
+This directive enables RFC931-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 trusted in any way except for rudimentary usage
+tracking.<p><hr>
+
+<h2><a name="keepalive">KeepAlive</a></h2>
+<strong>Syntax:</strong> KeepAlive <em>max-requests</em><br>
+<strong>Default:</strong> <code>KeepAlive 5</code><br>
+<strong>Context:</strong> server config<br>
+<strong>Status:</strong> Core<br>
+<strong>Compatibility:</strong> KeepAlive is only available in Apache
+1.1 and later.<p>
+
+This directive enables
+<a href="keepalive.html">Keep-Alive</a>
+support. Set <em>max-requests</em>
+to the maximum number of requests you want Apache to entertain per
+request. A limit is imposed to prevent a client from hogging your
+server resources. Set this to <code>0</code> to disable support.
+
+<h2><a name="keepalivetimeout">KeepAliveTimeout</a></h2>
+<strong>Syntax:</strong> KeepAliveTimeout <em>seconds</em><br>
+<strong>Default:</strong> <code>KeepAliveTimeout 15</code><br>
+<strong>Context:</strong> server config<br>
+<strong>Status:</strong> Core<br>
+<strong>Compatibility:</strong> KeepAliveTimeout is only available in Apache
+1.1 and later.<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="../core.html#timeout"><code>Timeout</code></a> directive
+applies.
+
+
+<A name="listen"><h2>Listen</h2></A>
+<strong>Syntax:</strong>
+Listen [<em>IP address</em>:]<em>port number</em><br>
+<strong>Context:</strong> server config<br>
+<strong>Status:</strong> core<br>
+<strong>Compatibility:</strong> Listen is only available in Apache
+1.1 and later.<p>
+
+<p>The Listen directive instructs Apache to listen to more than one IP
+address or port; by default it responds to requests on all IP
+interfaces, but only on the port given by the <a href="#port">Port</a>
+directive.</p>
+
+<p><strong>See Also</strong>:
+<a href="bind.html">Setting which addresses and ports Apache uses</a></p>
+
+<A name="limit"><h2><Limit> directive</h2></A>
+<!--%plaintext <?INDEX {\tt Limit} section directive> -->
+<strong>Syntax:</strong>
+ <Limit <em>method method</em> ... > ... </Limit><br>
+<strong>Context:</strong> any<br>
+<strong>Status:</strong> core<p>
+
+<Limit> and </Limit> are used to enclose a group of
+access control directives which will then apply only to the specified
+access methods, where <em>method</em> is any valid HTTP method.
+Any directive except another <Limit> or
+<A HREF="#directory"><Directory></A> may be used; the majority will be
+unaffected by the <Limit>. Example:
+<blockquote><code>
+<Limit GET POST><br>
+require valid-user<br>
+</Limit></code></blockquote>
+If an access control directive appears outside a <Limit> directive,
+then it applies to all access methods.<p><hr>
+
+<h2><a name="location"><Location></a></h2>
+
+<strong>Syntax:</strong> <Location <em>URL prefix</em>><br>
+<strong>Context:</strong> server config, virtual host<br>
+<strong>Status:</strong> core<br>
+<strong>Compatibility:</strong> Location is only available in Apache
+1.1 and later.<p>
+
+<p>The <Location> directive provides for access control by
+URL. It is comprable to the <a
+href="#directory"><Directory></a> directive, and
+should be matched with a </Location> directive. Directives that
+apply to the URL given should be listen
+within. <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.</p>
+
+<p>Note that, due to the way HTTP functions, <em>URL prefix</em>
+should, save for proxy requests, be of the form <code>/path/</code>,
+and should not include the <code>http://servername</code>. It doesn't
+neccessarily have to protect a directory (it can be an individual
+file, or a number of files), and can include wildcards. In a wildcard
+string, `?' matches any single character, and `*' matches any
+sequences of characters.
+
+<p>This 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
+ <Limit GET>
+ order deny,allow
+ deny from all
+ allow from .foo.com
+ </Limit>
+ </Location>
+</pre>
+
+
+<A name="maxclients"><h2>MaxClients directive</h2></A>
+<!--%plaintext <?INDEX {\tt MaxClients} directive> -->
+<strong>Syntax:</strong> MaxClients <em>number</em><br>
+<strong>Default:</strong> <code>MaxClients 150</code><br>
+<strong>Context:</strong> server config<br>
+<strong>Status:</strong> core<p>
+
+The MaxClients directive sets the limit on the number of simultaneous
+requests that can be supported; not more than this number of child server
+processes will be created.<p><hr>
+
+<A name="maxrequestsperchild"><h2>MaxRequestsPerChild directive</h2></A>
+<!--%plaintext <?INDEX {\tt MaxRequestsPerChild} directive> -->
+<strong>Syntax:</strong> MaxRequestsPerChild <em>number</em><br>
+<strong>Default:</strong> <code>MaxRequestsPerChild 0</code><br>
+<strong>Context:</strong> server config<br>
+<strong>Status:</strong> core<p>
+
+The MaxRequestsPerChild directive sets the limit on the number of requests
+that an individual child server process will handle. After MaxRequestsPerChild
+requests, the child process will die. If MaxRequestsPerChild is 0, then
+the process will never expire.<p>
+
+Setting MaxRequestsPerChild to a non-zero limit has two beneficial effects:
+<ul>
+<li>it limits the amount of memory that process can consume by (accidental)
+memory leakage;
+<li> by giving processes a finite lifetime, it helps reduce the
+number of processes when the server load reduces.
+</ul><p><hr>
+
+<A name="maxspareservers"><h2>MaxSpareServers directive</h2></A>
+<!--%plaintext <?INDEX {\tt MaxSpareServers} directive> -->
+<strong>Syntax:</strong> MaxSpareServers <em>number</em><br>
+<strong>Default:</strong> <code>MaxSpareServers 10</code><br>
+<strong>Context:</strong> server config<br>
+<strong>Status:</strong> core<p>
+
+The MaxSpareServers directive sets the desired maximum number of <em>idle</em>
+child server processes. An idle process is one which is not handling
+a request. If there are more than MaxSpareServers idle, then the parent
+process will kill off the excess processes.<p>
+
+Tuning of this parameter should only be necessary on very busy sites.
+Setting this parameter to a large number is almost always a bad idea.<p>
+
+See also <A HREF="#minspareservers">MinSpareServers</A> and
+<A HREF="#startservers">StartServers</A>.<p><hr>
+
+<A name="minspareservers"><h2>MinSpareServers directive</h2></A>
+<!--%plaintext <?INDEX {\tt MinSpareServers} directive> -->
+<strong>Syntax:</strong> MinSpareServers <em>number</em><br>
+<strong>Default:</strong> <code>MinSpareServers 5</code><br>
+<strong>Context:</strong> server config<br>
+<strong>Status:</strong> core<p>
+
+The MinSpareServers directive sets the desired minimum number of <em>idle</em>
+child server processes. An idle process is one which is not handling
+a request. If there are fewer than MinSpareServers idle, then the parent
+process creates new children at a maximum rate of 1 per second.<p>
+
+Tuning of this parameter should only be necessary on very busy sites.
+Setting this parameter to a large number is almost always a bad idea.<p>
+
+See also <A HREF="#maxspareservers">MaxSpareServers</A> and
+<A HREF="#startservers">StartServers</A>.<p><hr>
+
+<A name="options"><h2>Options directive</h2></A>
+<!--%plaintext <?INDEX {\tt Options} directive> -->
+<strong>Syntax:</strong> Options <em>option option ...</em><br>
+<strong>Context:</strong> server config, virtual host, directory, .htaccess<br>
+<strong>Override:</strong> Options<br>
+<strong>Status:</strong> 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.
+<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.
+<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
+#include of CGI scripts are disabled.
+<dt>Indexes
+<dd>
+<!--%plaintext <?INDEX {\tt Indexes} option> -->
+If a URL which maps to a directory is requested, and the there is no
+DirectoryIndex (e.g. index.html) in that directory, then the server will
+return a formatted listing of the directory.
+<dt>MultiViews
+<dd>
+<!--%plaintext <?INDEX {\tt MultiViews} option> -->
+<A HREF="content-negotiation.html">Ccontent negotiatad</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.
+</dl>
+
+If multiple Options could apply to a directory, then the most specific one is
+taken complete; the options are not merged. For example:
+<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.<p><hr>
+
+<A name="pidfile"><h2>PidFile directive</h2></A>
+<!--%plaintext <?INDEX {\tt PidFile} directive> -->
+<strong>Syntax:</strong> PidFile <em>filename</em><br>
+<strong>Default:</strong> <code>PidFile logs/httpd.pid</code><br>
+<strong>Context:</strong> server config<br>
+<strong>Status:</strong> core<p>
+
+The PidFile directive sets the file to which the server records the
+process id of the daemon. If the filename does not begin with a slash (/)
+then it is assumed to be relative to the <A HREF="#serverroot">ServerRoot</A>.
+The PidFile is only used in <A HREF="#servertype">standalone</A> mode.<p>
+
+It is often useful to be able to send the server a signal, so that it closes
+and then reopens its <A HREF="#errorlog">ErrorLog</A> and TransferLog, and
+re-reads its configuration files. This is done by sending a SIGHUP (kill -1)
+signal to the process id listed in the PidFile.<p><hr>
+
+<A name="port"><h2>Port directive</h2></A>
+<!--%plaintext <?INDEX {\tt Port} directive> -->
+<strong>Syntax:</strong> Port <em>number</em><br>
+<strong>Default:</strong> <code>Port 80</code><br>
+<strong>Context:</strong> server config<br>
+<strong>Status:</strong> core<p>
+
+The Port directive sets the network port on which the server listens.
+<em>Num</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>
+
+Port 80 is one of Unix's special ports. All ports numbered
+below 1024 are reserved for system use, i.e. regular (non-root) users cannot
+make use of them; instead they can only use higher port numbers.<p>
+
+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="#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="#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>
+
+<A name="require"><h2>require directive</h2></A>
+<!--%plaintext <?INDEX {\tt require} directive> -->
+<strong>Syntax:</strong> require <em>entity-name entity entity...</em><br>
+<strong>Context:</strong> directory, .htaccess<br>
+<strong>Override:</strong> AuthConfig<br>
+<strong>Status:</strong> core<p>
+
+This directive selects which authenticated users can access a directory.
+The allowed syntaxes are:
+<ul>
+<li>require user <em>userid userid ...</em><p>
+Only the named users can access the directory.<p>
+<li>require group <em>group-name 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>
+If <code>require</code> appears in a <A HREF="#limit"><Limit></A>
+section, then it restricts access to the named methods, otherwise
+it restricts access for all methods. Example:
+<blockquote><code>
+AuthType Basic<br>
+AuthName somedomain<br>
+AuthUserFile /web/users<br>
+AuthGroupFile /web/groups<br>
+Limit <GET POST><br>
+require group admin<br>
+</Limit>
+</code></blockquote>
+
+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.<p><hr>
+
+<A name="resourceconfig"><h2>ResourceConfig directive</h2></A>
+<!--%plaintext <?INDEX {\tt ResourceConfig} directive> -->
+<strong>Syntax:</strong> ResourceConfig <em>filename</em><br>
+<strong>Default:</strong> <code>ResourceConfig conf/srm.conf</code><br>
+<strong>Context:</strong> server config, virtual host<br>
+<strong>Status:</strong> core<p>
+
+The server will read this file for more directives after reading the
+httpd.conf file. <em>Filename</em> is relative to the
+<A HREF="#serverroot">ServerRoot</A>.
+This feature can be disabled using:
+<blockquote><code>ResourceConfig /dev/null</code></blockquote>
+Historically, this file contained most directives except for server
+configuration directives and <A HREF="#directory"><Directory></A>.
+sections; in fact it can now contain any server directive allowed in the
+<em>server config</em> context.<p>
+
+See also <A HREF="#accessconfig">AccessConfig</A>.<p><hr>
+
+<A name="serveradmin"><h2>ServerAdmin directive</h2></A>
+<!--%plaintext <?INDEX {\tt ServerAdmin} directive> -->
+<strong>Syntax:</strong> ServerAdmin <em>email-address</em><br>
+<strong>Context:</strong> server config, virtual host<br>
+<strong>Status:</strong> 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, e.g.
+<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>
+
+<A name="serveralias"><h2>ServerAlias directive</h2></A>
+
+<strong>Syntax:</strong> ServerAlias <em>host1 host2 ...</em><br>
+<strong>Context:</strong> virtual host<br>
+<strong>Status:</strong> core<br>
+<strong>Compatibility:</strong> 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="host.html">Host-header based virtual hosts</a>.
+
+<p><hr>
+
+<A name="servername"><h2>ServerName directive</h2></A>
+<!--%plaintext <?INDEX {\tt ServerName} directive> -->
+<strong>Syntax:</strong> ServerName <em>fully-qualified domain name</em><br>
+<strong>Context:</strong> server config, virtual host<br>
+<strong>Status:</strong> core<p>
+
+The ServerName directive sets the hostname of the server; this is only
+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.wibble.com</code></blockquote>
+would be used if the canonical (main) name of the actual machine
+were <code>monster.wibble.com</code>.<p><hr>
+
+<A name="serverpath"><h2>ServerPath directive</h2></A>
+
+<strong>Syntax:</strong> ServerPath <em>pathname</em><br>
+<strong>Context:</strong> virtual host<br>
+<strong>Status:</strong> core<br>
+<strong>Compatibility:</strong> ServerPath is only available in Apache
+1.1 and later.<p>
+
+The ServerAlias directive sets the legacy URL pathname for a host, for
+use with <a href="host.html">Host-header based virtual hosts</a>.
+
+<A name="serverroot"><h2>ServerRoot directive</h2></A>
+<!--%plaintext <?INDEX {\tt ServerRoot} directive> -->
+<strong>Syntax:</strong> ServerRoot <em>directory-filename</em><br>
+<strong>Default:</strong> <code>ServerRoot /usr/local/etc/httpd</code><br>
+<strong>Context:</strong> server config<br>
+<strong>Status:</strong> 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><hr>
+
+<A name="servertype"><h2>ServerType directive</h2></A>
+<!--%plaintext <?INDEX {\tt ServerType} directive> -->
+<strong>Syntax:</strong> ServerType <em>type</em><br>
+<strong>Default:</strong> <code>ServerType standalone</code><br>
+<strong>Context:</strong> server config<br>
+<strong>Status:</strong> core<p>
+
+The ServerType directive sets how the server is executed by the system.
+<em>Type</em> is one of
+<dl>
+<dt>inetd
+<dd>The server will be run from the system process inetd; the command to start
+the server is added to <code>/etc/inetd.conf</code>
+<dt>standalone
+<dd>The server will run as a daemon process; the command to start the server
+is added to the system startup scripts. (<code>/etc/rc.local</code> or
+<code>/etc/rc3.d/...</code>.)
+</dl>
+
+Inetd is the lesser used of the two options. For each http
+connection received, a new copy of the server is started from scratch;
+after the connection is complete, this program exits. There is a high price to
+pay per connection, but for security reasons, some admins prefer this option.
+<p>
+
+Standalone is the most common setting for ServerType since
+it is far more efficient. The server is started once, and services all
+subsequent connections. If you intend running Apache to serve a busy site,
+standalone will probably be your only option.<p>
+
+SECURITY: if you are paranoid about security, run in inetd mode. Security
+cannot be guaranteed in either, but whilst most people are happy to use
+standalone, inetd is probably least prone to attack.<p><hr>
+
+<A name="startservers"><h2>StartServers directive</h2></A>
+<!--%plaintext <?INDEX {\tt StartServers} directive> -->
+<strong>Syntax:</strong> StartServers <em>number</em><br>
+<strong>Default:</strong> <code>StartServers 5</code><br>
+<strong>Context:</strong> server config<br>
+<strong>Status:</strong> core<p>
+
+The StartServers directive sets the number of child server processes created
+on startup. As the number of processes is dynamically controlled depending
+on the load, there is usually little reason to adjust this parameter.<p>
+
+See also <A HREF="#minspareservers">MinSpareServers</A> and
+<A HREF="#maxspareservers">MaxSpareServers</A>.<p><hr>
+
+<A name="timeout"><h2>TimeOut directive</h2></A>
+<!--%plaintext <?INDEX {\tt TimeOut} directive> -->
+<strong>Syntax:</strong> TimeOut <em>number</em><br>
+<strong>Default:</strong> <code>TimeOut 1200</code><br>
+<strong>Context:</strong> server config<br>
+<strong>Status:</strong> core<p>
+
+The TimeOut directive sets the maximum time that the server will wait
+for the receipt of a request and the completion of a request, in seconds.
+So if it takes more than TimeOut seconds for a client to send a request or
+receive a response, the server will break off the connection. Thus TimeOut
+limits the maximum a transfer can take; for large files, and slow networks
+transfer times can be large.
+<p><hr>
+
+<A name="user"><h2>User directive</h2></A>
+<!--%plaintext <?INDEX {\tt User} directive> -->
+<strong>Syntax:</strong> User <em>unix-userid</em><br>
+<strong>Default:</strong> <code>User #-1</code><br>
+<strong>Context:</strong> server config<br>
+<strong>Status:</strong> core<p>
+
+The User directive sets the userid as which the server will answer requests.
+In order to use this directive, the standalone server must be run initially
+as root. <em>Unix-userid</em> is one of:
+<dl>
+<dt>A username
+<dd>Refers to the given user by name.
+<dt># followed by a user number.
+<dd>Refers to a user by their number.
+</dl>
+
+The user should have no privileges which result in it being able to access
+files which are not intended to be visible to the outside world, and
+similarly, the user should not be able to execute code which is not
+meant for httpd requests. It is recommended that you set up a new user and
+group specifically for running the server. Some admins use user
+<code>nobody</code>, but this is not always possible or desirable.<p>
+
+Notes: If you start the server as a non-root user, it will fail to change
+to the lesser privileged user, and will instead continue to run as
+that original user. If you do start the server as root, then it is normal
+for the parent process to remain running as root.<p>
+
+SECURITY: Don't set User (or <A HREF="#group">Group</A>) to
+<code>root</code> unless you know exactly what you are doing, and what the
+dangers are.<p><hr>
+
+<A name="virtualhost"><h2><VirtualHost> directive</h2></A>
+<!--%plaintext <?INDEX {\tt VirtualHost} section directive> -->
+<strong>Syntax:</strong> <VirtualHost <em>addr</em>[:<em>port</em>]> ...
+</VirtualHost> <br>
+<strong>Context:</strong> server config<br>
+<strong>Status:</strong> Core. <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 host.foo.com> <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>
+
+Currently, each VirtualHost must correspond to a different IP address for
+the server, so 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="vif.info.txt">VIF</A> (for SunOS(TM) 4.1.x).<p>
+
+<!--%hypertext -->
+<p><strong>See also:</strong>
+<A HREF="virtual-host.html">Information on Virtual Hosts.
+(multihome)</A><br>
+<strong>See also:</strong>
+<a href="host.html">Non-IP address-based Virtual Hosts</a>
+<!--/%hypertext --></p>
+
+<hr>
+
+<!--%hypertext -->
+<A HREF="../"><IMG SRC="../images/apache_home.gif" ALT="Home"></A>
+<A HREF="./"><IMG SRC="../images/apache_index.gif" ALT="Index"></A>
+
+</BODY>
+</HTML>
+<!--/%hypertext -->
projects / apache / commitdiff