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