| <!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> |