core.html.en

apache 安装教程 apache 安装教程

      <li>Apply directive <code>AllowOverride FileInfo</code> (for
      directory <code>/home/web</code>).</li>

      <li>Apply any FileInfo directives in
      <code>/home/web/.htaccess</code></li>
    </ul>

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

    <blockquote>
      <code>&lt;Directory ~ abc$&gt;<br />
       ... directives here ...<br />
       &lt;/Directory&gt;<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
    &lt;Directory&gt;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
    &lt;Directory /&gt; 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></p>
<pre>
 &lt;Directory /&gt;
     Order Deny,Allow
     Deny from All
 &lt;/Directory&gt;
</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>
    &lt;Directory&gt; directives cannot nest, and cannot appear in
    a <a href="#limit">&lt;Limit&gt;</a> or <a
    href="#limitexcept">&lt;LimitExcept&gt;</a> section. 

   <p>If you have <a href="mod_proxy.html">mod_proxy</a> enabled, you
   can use the <code>proxy:</code> syntax to apply configuration
   directives to proxied content. The syntax for this is to specify the
   proxied URLs to which you wish to apply the configuration, or to
   specify <code>*</code> to apply to all proxied content:</p>

   <p>To apply to all proxied content:</p>

   <pre>
   &lt;Directory proxy:*&gt;
     ... directives here ...
   &lt;/Directory&gt;
   </pre>

   <p>To apply to just a subset of proxied content:</p>

   <pre>
   &lt;Directory proxy:http://www.example.com/&gt;
     ... directives here ...
   &lt;/Directory&gt;
   </pre>

    <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>
    <p><strong>See also</strong>: <a
    href="#directorymatch">DirectoryMatch</a></p>
    <hr />

    <h2><a id="directorymatch"
    name="directorymatch">&lt;DirectoryMatch&gt;</a></h2>
    <a href="directive-dict.html#Syntax"
    rel="Help"><strong>Syntax:</strong></a> &lt;DirectoryMatch
    <em>regex</em>&gt; ... &lt;/DirectoryMatch&gt; <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>&lt;DirectoryMatch&gt; and &lt;/DirectoryMatch&gt; 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">&lt;Directory&gt;</a>. However, it
    takes as an argument a regular expression. For example:</p>
<pre>
   &lt;DirectoryMatch "^/www/.*/[0-9]{3}"&gt;
</pre>

    <p>would match directories in /www/ that consisted of three
    numbers.</p>

    <p><strong>See Also:</strong> <a
    href="#directory">&lt;Directory&gt;</a> for a description of
    how regular expressions are mixed in with normal
    &lt;Directory&gt;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</p>
    <hr />

    <h2><a id="documentroot" name="documentroot">DocumentRoot
    directive</a></h2>

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

    <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 id="ebcdicconvert"
    name="ebcdicconvert">EBCDICConvert</a></h2>

    <a href="directive-dict.html#Syntax"
    rel="Help"><strong>Syntax:</strong></a> EBCDICConvert
    On|Off[=<em>direction</em>] <em>extension</em>
    [<em>extension</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 configurable
    EBCDIC conversion is only available in Apache 1.3.19 and later,
    and on EBCDIC based platforms. 

    <p>The EBCDICConvert directive maps the given filename
    extensions to the specified conversion setting (<samp>On</samp>
    or <samp>Off</samp>). File extensions may be specified with or
    without a leading dot.</p>

    <p>If the optional format <samp>On=<i>direction</i></samp> (or
    <samp>Off=<i>direction</i></samp>) is used, where
    <i>direction</i> is one of <samp>In</samp>, <samp>Out</samp> or
    <samp>InOut</samp>, then the directive only applies to the
    specified transfer direction (<samp>In</samp>: uploaded content
    in a PUT or POST request, <samp>Out</samp>: returned content in
    a GET or POST request, and <samp>InOut</samp>: conversion in
    both directions).<br />
     Otherwise, <samp>InOut</samp> (conversion in both directions)
    is implied.</p>

    <p>Conversion configuration based on file extension is tested
    prior to configuration based on MIME type, to allow for generic
    MIME based rules to be overridden by a more specific file
    extension (several file extensions may exist for the same MIME
    type).</p>

    <p><strong>Example</strong>:<br />
     With a configuration like the following, the normal
    <samp>*.html</samp> files contain HTML text in EBCDIC encoding,
    while <samp>*.ahtml</samp> files contain HTML text in ASCII
    encoding:</p>
<pre>
    # *.html and *.ahtml contain HTML text:
    AddType  text/html  .html .ahtml

    # *.ahtml is not converted (contains ASCII text already):
    EBCDICConvert       Off .ahtml

    # All other text/html files presumably contain EBCDIC text:
    EBCDICConvertByType On  text/html
</pre>
    <br />
     <br />
     

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

    <h2><a id="ebcdicconvertbytype"
    name="ebcdicconvertbytype">EBCDICConvertByType</a></h2>

    <a href="directive-dict.html#Syntax"
    rel="Help"><strong>Syntax:</strong></a> EBCDICConvertByType
    On|Off[=<em>direction</em>] <em>mimetype</em>
    [<em>mimetype</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 configurable
    EBCDIC conversion is only available in Apache 1.3.19 and later,
    and on EBCDIC based platforms. 

    <p>The EBCDICConvertByType directive maps the given MIME type
    (optionally containing wildcards) to the specified conversion
    setting (<samp>On</samp> or <samp>Off</samp>).</p>

    <p>If the optional format <samp>On=<i>direction</i></samp> (or
    <samp>Off=<i>direction</i></samp>) is used, where
    <i>direction</i> is one of <samp>In</samp>, <samp>Out</samp> or
    <samp>InOut</samp>, then the directive only applies to the
    specified transfer direction (<samp>In</samp>: uploaded content
    in a PUT or POST request, <samp>Out</samp>: returned content in
    a GET or POST request, and <samp>InOut</samp>: conversion in
    both directions).<br />
     Otherwise, <samp>InOut</samp> (conversion in both directions)
    is implied.</p>

    <p><strong>Example</strong>:<br />
     A useful standard configuration should at least contain the
    following defaults:</p>
<pre>
    # All text documents are stored as EBCDIC files:
    EBCDICConvertByType On  text/* message/* multipart/*
    EBCDICConvertByType On  application/x-www-form-urlencoded \
                model/vrml application/postscript
    # All other files are assumed to be binary:
    EBCDICConvertByType Off */*
</pre>
    If you serve ASCII documents only, for example from an NFS
    mounted unix server, use: 
<pre>
    # All documents are ASCII already:
    EBCDICConvertByType Off */*
</pre>

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

    <h2><a id="ebcdickludge"
    name="ebcdickludge">EBCDICKludge</a></h2>

    <a href="directive-dict.html#Syntax"
    rel="Help"><strong>Syntax:</strong></a> EBCDICKludge
    On|Off<br />
     <a href="directive-dict.html#Default"
    rel="Help"><strong>Default:</strong></a> <code>EBCDICKludge
    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#Override"
    rel="Help"><strong>Override:</strong></a> FileInfo<br />
     <a href="directive-dict.html#Compatibility"
    rel="Help"><strong>Compatibility:</strong></a> EBCDICKludge is
    only available in Apache 1.3.19 and later, and on EBCDIC based
    platforms. It is deprecated and will be withdrawn in a future
    version.<br />
     

    <p>The EBCDICKludge is provided for the backward compatible
    behavior with apache versions 1.3.0 through 1.3.18. In these
    versions, all files with MIME types starting with "text/",
    "message/" or "multipart/" or with type
    "application/x-www-form-urlencoded" would be converted by
    default, all other documents were returned unconverted. Only if
    a MIME type "<samp>text/<b>x-ascii-</b><i>subtype</i></samp>"
    was configured for a certain document, the document was assumed
    to be in ASCII format already, and was not converted again.
    Instead, the "<samp><b>x-ascii-</b></samp>" was removed from
    the type, resulting in the MIME type
    "<samp>text/<i>subtype</i></samp>" being returned for the
    document.</p>

    <p>If the EBCDICKludge directive is set to <samp>On</samp>, and
    if none of the file extensions configured with the <a
    href="#ebcdicconvert">EBCDICConvert</a> directive matches in
    the current context, then the server tests for a MIME type of
    the format
    <samp><i>type/</i><b>x-ascii-</b><i>subtype</i></samp>. If the
    document has such a type, then the
    "<samp><b>x-ascii-</b></samp>" substring is removed and the
    conversion set to <samp>Off</samp>. This allows for overriding
    the implicit assumption that all text files are stored in
    EBCDIC format, for example when serving documents from an NFS
    mounted directory with ASCII documents.<br />
     By using the EBCDICKludge, there is no way to force one of the
    other MIME types (<em>e.g.</em>, model/vrml) to be treated as
    an EBCDIC text file. Use of the <a
    href="#ebcdicconvertbytype">EBCDICConvertByType</a> directive