sections.html.en

Apache_2.0.59-Openssl_0.9 配置tomcat. Apache_2.0.59-Openssl_0.9 配置tomcat.

Order allow,deny<br />
Deny from all<br />
&lt;/FilesMatch&gt;
</code></p></div>



<h3><a name="whichwhen" id="whichwhen">What to use When</a></h3>

<p>Choosing between filesystem containers and webspace containers is
actually quite easy.  When applying directives to objects that reside
in the filesystem always use <code class="directive"><a href="./mod/core.html#directory">&lt;Directory&gt;</a></code> or <code class="directive"><a href="./mod/core.html#files">&lt;Files&gt;</a></code>.  When applying directives to objects
that do not reside in the filesystem (such as a webpage generated from
a database), use <code class="directive"><a href="./mod/core.html#location">&lt;Location&gt;</a></code>.</p>

<p>It is important to never use <code class="directive"><a href="./mod/core.html#location">&lt;Location&gt;</a></code> when trying to restrict
access to objects in the filesystem.  This is because many
different webspace locations (URLs) could map to the same filesystem
location, allowing your restrictions to be circumvented.
For example, consider the following configuration:</p>

<div class="example"><p><code>
&lt;Location /dir/&gt;<br />
Order allow,deny<br />
Deny from all<br />
&lt;/Location&gt;
</code></p></div>

<p>This works fine if the request is for
<code>http://yoursite.example.com/dir/</code>.  But what if you are on
a case-insensitive filesystem?  Then your restriction could be easily
circumvented by requesting
<code>http://yoursite.example.com/DIR/</code>.  The <code class="directive"><a href="./mod/core.html#directory">&lt;Directory&gt;</a></code> directive, in
contrast, will apply to any content served from that location,
regardless of how it is called.  (An exception is filesystem links.
The same directory can be placed in more than one part of the
filesystem using symbolic links.  The <code class="directive"><a href="./mod/core.html#directory">&lt;Directory&gt;</a></code> directive will follow the symbolic
link without resetting the pathname.  Therefore, for the highest level
of security, symbolic links should be disabled with the appropriate
<code class="directive"><a href="./mod/core.html#options">Options</a></code> directive.)</p>

<p>If you are, perhaps, thinking that none of this applies to you
because you use a case-sensitive filesystem, remember that there are
many other ways to map multiple webspace locations to the same
filesystem location.  Therefore you should always use the filesystem
containers when you can.  There is, however, one exception to this
rule.  Putting configuration restrictions in a <code>&lt;Location
/&gt;</code> section is perfectly safe because this section will apply
to all requests regardless of the specific URL.</p>


</div><div class="top"><a href="#page-header"><img alt="top" src="./images/up.gif" /></a></div>
<div class="section">
<h2><a name="virtualhost" id="virtualhost">Virtual Hosts</a></h2>

<p>The <code class="directive"><a href="./mod/core.html#virtualhost">&lt;VirtualHost&gt;</a></code>
container encloses directives that apply to specific hosts.
This is useful when serving multiple hosts from the same machine
with a different configuration for each.  For more information,
see the <a href="vhosts/">Virtual Host Documentation</a>.</p>
</div><div class="top"><a href="#page-header"><img alt="top" src="./images/up.gif" /></a></div>
<div class="section">
<h2><a name="proxy" id="proxy">Proxy</a></h2>

<p>The <code class="directive"><a href="./mod/mod_proxy.html#proxy">&lt;Proxy&gt;</a></code>
and <code class="directive"><a href="./mod/mod_proxy.html#proxymatch">&lt;ProxyMatch&gt;</a></code>
containers apply enclosed configuration directives only
to sites accessed through <code class="module"><a href="./mod/mod_proxy.html">mod_proxy</a></code>'s proxy server
that match the specified URL.  For example, the following configuration
will prevent the proxy server from being used to access the
<code>cnn.com</code> website.</p>

<div class="example"><p><code>
&lt;Proxy http://cnn.com/*&gt;<br />
Order allow,deny<br />
Deny from all<br />
&lt;/Proxy&gt;
</code></p></div>
</div><div class="top"><a href="#page-header"><img alt="top" src="./images/up.gif" /></a></div>
<div class="section">
<h2><a name="whatwhere" id="whatwhere">What Directives are Allowed?</a></h2>

<p>To find out what directives are allowed in what types of
configuration sections, check the <a href="mod/directive-dict.html#Context">Context</a> of the directive.
Everything that is allowed in 
<code class="directive"><a href="./mod/core.html#directory">&lt;Directory&gt;</a></code>
sections is also syntactically allowed in
<code class="directive"><a href="./mod/core.html#directorymatch">&lt;DirectoryMatch&gt;</a></code>,
<code class="directive"><a href="./mod/core.html#files">&lt;Files&gt;</a></code>,
<code class="directive"><a href="./mod/core.html#filesmatch">&lt;FilesMatch&gt;</a></code>,
<code class="directive"><a href="./mod/core.html#location">&lt;Location&gt;</a></code>,
<code class="directive"><a href="./mod/core.html#locationmatch">&lt;LocationMatch&gt;</a></code>,
<code class="directive"><a href="./mod/mod_proxy.html#proxy">&lt;Proxy&gt;</a></code>,
and <code class="directive"><a href="./mod/mod_proxy.html#proxymatch">&lt;ProxyMatch&gt;</a></code>
sections.  There are some exceptions, however:</p>

<ul>
<li>The <code class="directive"><a href="./mod/core.html#allowoverride">AllowOverride</a></code> directive
works only in <code class="directive"><a href="./mod/core.html#directory">&lt;Directory&gt;</a></code>
sections.</li>

<li>The <code>FollowSymLinks</code> and
<code>SymLinksIfOwnerMatch</code> <code class="directive"><a href="./mod/core.html#options">Options</a></code> work only in <code class="directive"><a href="./mod/core.html#directory">&lt;Directory&gt;</a></code> sections or
<code>.htaccess</code> files.</li>

<li>The <code class="directive"><a href="./mod/core.html#options">Options</a></code> directive cannot
be used in <code class="directive"><a href="./mod/core.html#files">&lt;Files&gt;</a></code>
and <code class="directive"><a href="./mod/core.html#filesmatch">&lt;FilesMatch&gt;</a></code>
sections.</li>
</ul>
</div><div class="top"><a href="#page-header"><img alt="top" src="./images/up.gif" /></a></div>
<div class="section">
<h2><a name="mergin" id="mergin">How the sections are merged</a></h2>

<p>The configuration sections are applied in a very particular order.
Since this can have important effects on how configuration directives
are interpreted, it is important to understand how this works.</p>

    <p>The order of merging is:</p>

    <ol>
      <li> <code class="directive"><a href="./mod/core.html#directory">&lt;Directory&gt;</a></code> (except regular expressions)
      and <code>.htaccess</code> done simultaneously (with
      <code>.htaccess</code>, if allowed, overriding
      <code class="directive"><a href="./mod/core.html#directory">&lt;Directory&gt;</a></code>)</li>

      <li><code class="directive"><a href="./mod/core.html#directorymatch">&lt;DirectoryMatch&gt;</a></code>
      (and <code>&lt;Directory ~&gt;</code>)</li>

      <li><code class="directive"><a href="./mod/core.html#files">&lt;Files&gt;</a></code> and <code class="directive"><a href="./mod/core.html#filesmatch">&lt;FilesMatch&gt;</a></code> done
      simultaneously</li>

      <li><code class="directive"><a href="./mod/core.html#location">&lt;Location&gt;</a></code>
      and <code class="directive"><a href="./mod/core.html#locationmatch">&lt;LocationMatch&gt;</a></code> done simultaneously</li>
    </ol>

    <p>Apart from <code class="directive"><a href="./mod/core.html#directory">&lt;Directory&gt;</a></code>, each group is processed in
    the order that they appear in the configuration files.  <code class="directive"><a href="./mod/core.html#directory">&lt;Directory&gt;</a></code> (group 1 above)
    is processed in the order shortest directory component to longest.
    So for example, <code>&lt;Directory /var/web/dir&gt;</code> will
    be processed before <code>&lt;Directory
    /var/web/dir/subdir&gt;</code>.  If multiple <code class="directive"><a href="./mod/core.html#directory">&lt;Directory&gt;</a></code> sections apply
    to the same directory they are processed in the configuration file
    order. Configurations included via the <code class="directive"><a href="./mod/core.html#include">Include</a></code> directive will be treated as if
    they were inside the including file at the location of the
    <code class="directive"><a href="./mod/core.html#include">Include</a></code> directive.</p>

    <p>Sections inside <code class="directive"><a href="./mod/core.html#virtualhost">&lt;VirtualHost&gt;</a></code> sections
    are applied <em>after</em> the corresponding sections outside
    the virtual host definition. This allows virtual hosts to
    override the main server configuration.</p>

    <p>Later sections override earlier ones.</p>

<div class="note"><h3>Technical Note</h3>
      There is actually a
      <code>&lt;Location&gt;</code>/<code>&lt;LocationMatch&gt;</code>
      sequence performed just before the name translation phase
      (where <code>Aliases</code> and <code>DocumentRoots</code>
      are used to map URLs to filenames). The results of this
      sequence are completely thrown away after the translation has
      completed.
</div>

<h3><a name="merge-examples" id="merge-examples">Some Examples</a></h3>

<p>Below is an artificial example to show the order of
merging. Assuming they all apply to the request, the directives in
this example will be applied in the order A &gt; B &gt; C &gt; D &gt;
E.</p>

<div class="example"><p><code>
&lt;Location /&gt;<br />
E<br />
&lt;/Location&gt;<br />
<br />
&lt;Files f.html&gt;<br />
D<br />
&lt;/Files&gt;<br />
<br />
&lt;VirtualHost *&gt;<br />
&lt;Directory /a/b&gt;<br />
B<br />
&lt;/Directory&gt;<br />
&lt;/VirtualHost&gt;<br />
<br />
&lt;DirectoryMatch "^.*b$"&gt;<br />
C<br />
&lt;/DirectoryMatch&gt;<br />
<br />
&lt;Directory /a/b&gt;<br />
A<br />
&lt;/Directory&gt;<br />
<br />
</code></p></div>

<p>For a more concrete example, consider the following.  Regardless of
any access restrictions placed in <code class="directive"><a href="./mod/core.html#directory">&lt;Directory&gt;</a></code> sections, the <code class="directive"><a href="./mod/core.html#location">&lt;Location&gt;</a></code> section will be
evaluated last and will allow unrestricted access to the server.  In
other words, order of merging is important, so be careful!</p>

<div class="example"><p><code>
&lt;Location /&gt;<br />
Order deny,allow<br />
Allow from all<br />
&lt;/Location&gt;<br />
<br />
# Woops!  This &lt;Directory&gt; section will have no effect<br />
&lt;Directory /&gt;<br />
Order allow,deny<br />
Allow from all<br />
Deny from badguy.example.com<br />
&lt;/Directory&gt;
</code></p></div>



</div></div>
<div class="bottomlang">
<p><span>Available Languages: </span><a href="./en/sections.html" title="English">&nbsp;en&nbsp;</a> |
<a href="./es/sections.html" hreflang="es" rel="alternate" title="Espa駉l">&nbsp;es&nbsp;</a> |
<a href="./ja/sections.html" hreflang="ja" rel="alternate" title="Japanese">&nbsp;ja&nbsp;</a> |
<a href="./ko/sections.html" hreflang="ko" rel="alternate" title="Korean">&nbsp;ko&nbsp;</a></p>
</div><div id="footer">
<p class="apache">Copyright 2006 The Apache Software Foundation.<br />Licensed under the <a href="http://www.apache.org/licenses/LICENSE-2.0">Apache License, Version 2.0</a>.</p>
<p class="menu"><a href="./mod/">Modules</a> | <a href="./mod/directives.html">Directives</a> | <a href="./faq/">FAQ</a> | <a href="./glossary.html">Glossary</a> | <a href="./sitemap.html">Sitemap</a></p></div>
</body></html>