core.html.en

apache 安装教程 apache 安装教程

    mentioned above is the preferred way to configure such a
    conversion. (Before Apache version 1.3.19, there was no way at
    all to force these binary documents to be treated as EBCDIC
    text files.)</p>

    <p><strong>See also</strong>: <a
    href="#ebcdicconvert">EBCDICConvert</a>, <a
    href="#ebcdicconvertbytype">EBCDICConvertByType</a> and <a
    href="../ebcdic.html#ebcdic">Overview of the EBCDIC Conversion
    Functions</a></p>
    <hr />

    <h2><a id="enableexceptionhook" name="enableexceptionhook">
    EnableExceptionHook directive</a></h2>

    <a href="directive-dict.html#Syntax"
    rel="Help"><strong>Syntax:</strong></a> EnableExceptionHook
    on|off<br />
     <a href="directive-dict.html#Default"
    rel="Help"><strong>Default:</strong></a> <code>EnableExceptionHook
    off</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> EnableExceptionHook
    is available in Apache 1.3.30 and later

    <p><code>EnableExceptionHook</code> controls whether or not an
    exception hook implemented by a module will be called after a
    child process crash.  The exception hook allows modules to log
    diagnostic information that may help determine the cause of the
    crash.</p>
    <hr />

    <h2><a id="errordocument" name="errordocument">ErrorDocument
    directive</a></h2>

    <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. 

    <p>In the event of a problem or error, Apache can be configured
    to do one of four things,</p>

    <ol>
      <li>output a simple hardcoded error message</li>

      <li>output a customized message</li>

      <li>redirect to a local <em>URL-path</em> to handle the
      problem/error</li>

      <li>redirect to an external <em>URL</em> to handle the
      problem/error</li>
    </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 message or
    URL.</p>

    <p><em>Messages</em> in this context begin with a single
    double-quote character (<code>"</code>), which does not form
    part of the message itself. Apache will sometimes offer
    additional information regarding the problem/error.</p>

    <p>URLs can begin with a slash (/) for local URLs, or be a full
    URL which the client can resolve. Examples:</p>

    <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>

    <p>Microsoft Internet Explorer (MSIE) will by default ignore
    server-generated error messages when they are "too small" and substitute
    its own "friendly" error messages. The size threshold varies depending on
    the type of error, but in general, if you make your error document
    greater than 512 bytes, then MSIE will show the server-generated
    error rather than masking it.  More information is available in
    Microsoft Knowledgebase article <a
    href="http://support.microsoft.com/default.aspx?scid=kb;en-us;Q294807"
    >Q294807</a>.</p>

    <p>See Also: <a href="../custom-error.html">documentation of
    customizable responses.</a> See the <a
    href="http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html">HTTP
    specification</a> for a complete list of the status codes and their
    meanings.</p>
    <hr />

    <h2><a id="errorlog" name="errorlog">ErrorLog
    directive</a></h2>

    <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>

    <p>Examples</p>

    <p><code>ErrorLog logs/vhost1.error</code></p>

    or

    <p><code>ErrorLog |/usr/local/bin/errorlog.pl</code></p>

    <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>

    <p>For example:</p>

    <p><code>ErrorLog syslog</code></p>

    or

    <p><code>ErrorLog syslog:user</code></p>

    <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>

    <p><strong>See also:</strong> <a href="#loglevel">LogLevel</a>
    and <a href="../logs.html">Apache Log Files</a></p>
    <hr />

    <h2><a id="fileetag" name="fileetag">FileETag directive</a></h2>
    <a href="directive-dict.html#Syntax"
    rel="Help"><strong>Syntax:</strong></a> FileETag
    <i>component</i> ...<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<br />
     <a href="directive-dict.html#Compatibility"
    rel="Help"><strong>Compatibility:</strong></a> only available
    in Apache 1.3.23 versions and later. 

    <p>
    The FileETag directive configures the file attributes that are
    used to create the ETag (entity tag) response header field
    when the document is based on a file.
    (The ETag value is used in cache management to save network
    bandwidth.)  In Apache 1.3.22 and earlier, the ETag value was
    <i>always</i> formed from the file's inode, size, and last-modified
    time (mtime).  The FileETag directive allows you to choose
    which of these -- if any -- should be used.  The recognized
    keywords are:
    </p>
    <dl compact="compact">
     <dt><b>INode</b></dt>
     <dd>The file's i-node number will be included in the calculation</dd>
     <dt><b>MTime</b></dt>
     <dd>The date and time the file was last modified will be included</dd>
     <dt><b>Size</b></dt>
     <dd>The number of bytes in the file will be included</dd>
     <dt><b>All</b></dt>
     <dd>All available fields will be used (equivalent to
      '<code>FileETag&nbsp;INode&nbsp;MTime&nbsp;Size</code>')</dd>
     <dt><b>None</b></dt>
     <dd>If a document is file-based, no ETag field will be included in the
      response</dd>
    </dl>
    <p>
    The INode, MTime, and Size keywords may be prefixed with either '+'
    or '-', which allow changes to be made to the default setting
    inherited from a broader scope.  Any keyword appearing without
    such a prefix immediately and completely cancels the inherited
    setting.
    </p>
    <p>
    If a directory's configuration includes
    '<code>FileETag&nbsp;INode&nbsp;MTime&nbsp;Size</code>', and a
    subdirectory's includes '<code>FileETag&nbsp;-INode</code>',
    the setting for that subdirectory (which will be inherited by
    any sub-subdirectories that don't override it) will be equivalent to
    '<code>FileETag&nbsp;MTime&nbsp;Size</code>'.
    </p>
    <hr />

    <h2><a id="files" name="files">&lt;Files&gt; directive</a></h2>
    <a href="directive-dict.html#Syntax"
    rel="Help"><strong>Syntax:</strong></a> &lt;Files
    <em>filename</em>&gt; ... &lt;/Files&gt;<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>The &lt;Files&gt; directive provides for access control by
    filename. It is comparable to the <a
    href="#directory">&lt;Directory&gt;</a> directive and <a
    href="#location">&lt;Location&gt;</a> directives. It should be
    matched with a &lt;/Files&gt; 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>&lt;Files&gt;</code> sections are processed in
    the order they appear in the configuration file, after the
    &lt;Directory&gt; sections and <code>.htaccess</code> files are
    read, but before &lt;Location&gt; sections. Note that
    &lt;Files&gt; can be nested inside &lt;Directory&gt; 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>
   &lt;Files ~ "\.(gif|jpe?g|png)$"&gt;
</pre>
    would match most common Internet graphics formats. In Apache
    1.3 and later, <a href="#filesmatch">&lt;FilesMatch&gt;</a> is
    preferred, however. 

    <p>Note that unlike <a
    href="#directory"><code>&lt;Directory&gt;</code></a> and <a
    href="#location"><code>&lt;Location&gt;</code></a> sections,
    <code>&lt;Files&gt;</code> sections can be used inside
    .htaccess files. This allows users to control access to their
    own files, at a file-by-file level.
    For example, to password protect a single file within a
    particular directory, you might add the following to your
    <code>.htaccess</code> file:</p>

    <pre>
    &lt;Files admin.cgi&gt;
    Require group admin
    &lt;/Files&gt;</pre>

    <p>Remember that directives apply to subdirectories as well, so this
    will also protect files called <code>admin.cgi</code> in
    subdirectories, unless specifically overridden.</p>

    <p>(See <a href="#require">Require</a> for details on using the
    <code>Require</code> directive)</p>

    <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</p>
    <hr />

    <h2><a id="filesmatch"
    name="filesmatch">&lt;FilesMatch&gt;</a></h2>
    <a href="directive-dict.html#Syntax"
    rel="Help"><strong>Syntax:</strong></a> &lt;FilesMatch
    <em>regex</em>&gt; ... &lt;/FilesMatch&gt;<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>The &lt;FilesMatch&gt; directive provides for access control
    by filename, just as the <a href="#files">&lt;Files&gt;</a>
    directive does. However, it accepts a regular expression. For
    example:</p>
<pre>
   &lt;FilesMatch "\.(gif|jpe?g|png)$"&gt;
</pre>

    <p>would match most common Internet graphics formats.</p>