mirror of
https://github.com/apache/httpd.git
synced 2025-05-17 15:21:13 +03:00
94e6f97c4a
Submitted by: Chris Pepper PR: 6623 git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86384 13f79535-47bb-0310-9956-ffa450edef68
171 lines
5.2 KiB
Plaintext
171 lines
5.2 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>
|
|
|
|
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.
|
|
|
|
<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). Semantically however some things, and the most
|
|
notable are <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.
|
|
|
|
<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 were inside the including file
|
|
at the location of the <CODE>Include</CODE> directive.
|
|
|
|
<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).
|
|
|
|
<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>
|
|
|
|
<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>
|