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