<!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">
<div align="CENTER">
<img src="images/sub.gif" alt="[APACHE DOCUMENTATION]" />
<h3>Apache HTTP Server Version 1.3</h3>
<p><small><em>Is this the version you want? For more recent
versions, check our <a href="/docs/">documentation
index</a>.</em></small></p>
</div>
<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. The configuration files are read in the order
httpd.conf, srm.conf and access.conf. 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. (Note: this only works
correctly from 1.2.2 and 1.3a2 onwards. Before those releases
sections inside virtual hosts were applied <em>before</em> the
main server).</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>
<hr />
<h3 align="CENTER">Apache HTTP Server</h3>
<a href="./"><img src="images/index.gif" alt="Index" /></a>
</body>
</html>
distrib
>
Mandriva
>
2010.0
>
i586
>
media
>
contrib-release
>
by-pkgid
>
d265f71d7fce441fd72dd0a77d0f8893
>
files
>
212
