mirror of
https://github.com/apache/httpd.git
synced 2025-06-01 23:21:45 +03:00
d78c998c6a
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@96194 13f79535-47bb-0310-9956-ffa450edef68
152 lines
5.5 KiB
Plaintext
152 lines
5.5 KiB
Plaintext
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
|
|
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
|
|
|
|
<html xmlns="http://www.w3.org/1999/xhtml">
|
|
<head>
|
|
<meta name="generator" content="HTML Tidy, see www.w3.org" />
|
|
|
|
<title>How Directory, Location and Files sections work</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">How Directory, Location and Files sections
|
|
work</h1>
|
|
|
|
<p>The sections <a
|
|
href="mod/core.html#directory"><code><Directory></code></a>,
|
|
<a
|
|
href="mod/core.html#location"><code><Location></code></a>
|
|
and <a
|
|
href="mod/core.html#files"><code><Files></code></a> can
|
|
contain directives which only apply to specified directories,
|
|
URLs or files respectively. Also htaccess files can be used
|
|
inside a directory to apply directives to that directory. This
|
|
document explains how these different sections differ and how
|
|
they relate to each other when Apache decides which directives
|
|
apply for a particular directory or request URL.</p>
|
|
|
|
<h2>Directives allowed in the sections</h2>
|
|
|
|
<p>Everything that is syntactically allowed in
|
|
<code><Directory></code> is also allowed in
|
|
<code><Location></code> (except a
|
|
sub-<code><Files></code> section). Semantically, however
|
|
some things, most notably <code>AllowOverride</code> and the
|
|
two options <code>FollowSymLinks</code> and
|
|
<code>SymLinksIfOwnerMatch</code>, make no sense in
|
|
<code><Location></code>,
|
|
<code><LocationMatch></code> or
|
|
<code><DirectoryMatch></code>. The same for
|
|
<code><Files></code> -- syntactically everything is fine,
|
|
but semantically some things are different.</p>
|
|
|
|
<h2>How the sections are merged</h2>
|
|
|
|
<p>The order of merging is:</p>
|
|
|
|
<ol>
|
|
<li><code><Directory></code> (except regular
|
|
expressions) and .htaccess done simultaneously (with
|
|
.htaccess, if allowed, overriding
|
|
<code><Directory></code>)</li>
|
|
|
|
<li><code><DirectoryMatch></code>, and
|
|
<code><Directory></code> with regular expressions</li>
|
|
|
|
<li><code><Files></code> and
|
|
<code><FilesMatch></code> done simultaneously</li>
|
|
|
|
<li><code><Location></code> and
|
|
<code><LocationMatch></code> done simultaneously</li>
|
|
</ol>
|
|
|
|
<p>Apart from <code><Directory></code>, each group is
|
|
processed in the order that they appear in the configuration
|
|
files. <code><Directory></code> (group 1 above) is
|
|
processed in the order shortest directory component to longest.
|
|
If multiple <code><Directory></code> sections apply to
|
|
the same directory they are processed in the configuration
|
|
file order. Configurations included
|
|
via the <code>Include</code> directive will be treated as if
|
|
they were inside the including file at the location of the
|
|
<code>Include</code> directive.</p>
|
|
|
|
<p>Sections inside <code><VirtualHost></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>
|
|
|
|
<h2>Notes about using sections</h2>
|
|
|
|
<p>The general guidelines are:</p>
|
|
|
|
<ul>
|
|
<li>If you are attempting to match objects at the filesystem
|
|
level then you must use <code><Directory></code> and/or
|
|
<code><Files></code>.</li>
|
|
|
|
<li>If you are attempting to match objects at the URL level
|
|
then you must use <code><Location></code></li>
|
|
</ul>
|
|
|
|
<p>But a notable exception is:</p>
|
|
|
|
<ul>
|
|
<li>proxy control is done via <code><Directory></code>.
|
|
This is a legacy mistake because the proxy existed prior to
|
|
<code><Location></code>. A future version of the config
|
|
language should probably switch this to
|
|
<code><Location></code>.</li>
|
|
</ul>
|
|
|
|
<p>Note about .htaccess parsing:</p>
|
|
|
|
<ul>
|
|
<li>Modifying .htaccess parsing during Location doesn't do
|
|
anything because .htaccess parsing has already occurred.</li>
|
|
</ul>
|
|
|
|
<p><code><Location></code> and symbolic links:</p>
|
|
|
|
<ul>
|
|
<li>It is not possible to use "<code>Options
|
|
FollowSymLinks</code>" or "<code>Options
|
|
SymLinksIfOwnerMatch</code>" inside a
|
|
<code><Location></code>,
|
|
<code><LocationMatch></code> or
|
|
<code><DirectoryMatch></code> section (the options are
|
|
simply ignored). Using the options in question is only
|
|
possible inside a <code><Directory></code> section (or
|
|
a <code>.htaccess</code> file).</li>
|
|
</ul>
|
|
|
|
<p><code><Files></code> and <code>Options</code>:</p>
|
|
|
|
<ul>
|
|
<li>Apache won't check for it, but using an
|
|
<code>Options</code> directive inside a
|
|
<code><Files></code> section has no effect.</li>
|
|
</ul>
|
|
|
|
<p>Another note:</p>
|
|
|
|
<ul>
|
|
<li>There is actually a
|
|
<code><Location></code>/<code><LocationMatch></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.</li>
|
|
</ul>
|
|
<!--#include virtual="footer.html" -->
|
|
</body>
|
|
</html>
|
|
|