mirror of
https://github.com/apache/httpd.git
synced 2025-10-30 08:05:39 +03:00
40d82b9a7a
Removed note about order reversal in 1.2-1.3a versions. Fixed a couple typos. Matched up <p> & </p>. git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@87993 13f79535-47bb-0310-9956-ffa450edef68
164 lines
5.1 KiB
Plaintext
164 lines
5.1 KiB
Plaintext
<!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>
|
|
|
|
<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 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.</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.
|
|
</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).
|
|
</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.
|
|
</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>
|