mirror of
https://github.com/apache/httpd.git
synced 2025-08-27 16:41:57 +03:00
2228b8d6c6
are merged. Based on Dean's explanation from PR#586. Link to this doc from the directive descriptions in core.html. PR: 586 git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@79051 13f79535-47bb-0310-9956-ffa450edef68
140 lines
4.3 KiB
HTML
140 lines
4.3 KiB
HTML
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
|
|
<html><head>
|
|
<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>
|
|
|
|
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="mode/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.
|
|
|
|
<h2>Directives allowed in the sections</h2>
|
|
|
|
Everything that is syntactically allowed in
|
|
<code><Directory></code> is also allowed in
|
|
<code><Location></code> (except a sub-<code><Files></code>
|
|
section, but the code doesn't test for that, Lars has an open bug
|
|
report on that). Semantically however some things, and the most
|
|
notable is AllowOverrides, make no sense in
|
|
<code><Location></code>. The same for
|
|
<code><Files></code> -- syntactically everything is fine, but
|
|
semantically some things are different.
|
|
|
|
<h2>How the sections are merged</h2>
|
|
|
|
The order of merging is:
|
|
|
|
<ol>
|
|
|
|
<li>
|
|
|
|
<code><Directory></code> (except regular expressions) and
|
|
.htaccess done simultaneously (with .htaccess 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>
|
|
|
|
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 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 where inside the including file
|
|
at the location of the <code>Include</code> directive.
|
|
|
|
<p>
|
|
|
|
Sections inside <code><VirtualHost></code> sections are applied
|
|
<i>after</i> 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 <i>before</i> the main server).
|
|
|
|
<h2>Notes about using sections</h2>
|
|
|
|
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>
|
|
|
|
But a notable exception is:
|
|
|
|
<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>
|
|
|
|
Note also that modifying .htaccess parsing during Location doesn't do
|
|
anything because .htaccess parsing has already occured.
|
|
|
|
<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>
|