Apache HTTP Server
Directives - Order of precedence/merging
 The configuration sections are applied in a very particular order and has important effects on how configuration directives are interpreted.
The order of merging is:
<Directory>(except regular expressions) and
.htaccessdone simultaneously (with
.htaccess, if allowed, overriding
<Directory>, each group is processed in the order that they appear in the configuration files.
<Directory> (group 1 above) is processed in the order shortest directory component to longest. So for example,
<Directory /var/web/dir> will be processed before
<Directory /var/web/dir/subdir>. If multiple
<Directory> sections apply to the same directory they are processed in the configuration file order. Configurations included via the
Include directive will be treated as if they were inside the including file at the location of the
<VirtualHost> sections are applied after the corresponding sections outside the virtual host definition. This allows virtual hosts to override the main server configuration.
When the request is served by
<Proxy> container takes the place of the
<Directory> container in the processing order.
Later sections override earlier ones.
A quick summary :
- Apache configuration file is parsed top to bottom.
- Included files are parsed right at their include location. In other words, within the configuration file.
- For directives which are called more than once, the last call overrides the previous calls.
- For a directive called more than once in a directory tree, the lowest call in the directory tree takes precedence.
.htaccessdirectives take precedence over the main configuration file directives.
This in particular is worth paying attention to:
For directives which are called more than once, the last call overrides the previous calls.
In situations where you have a configuration with a short Location path and a longer
Locationpath (both referring to the same overall path) like this :
<Location /sub/foo> Order allow,deny </Location> <Location /sub > Order deny,allow Require valid-user Satisfy all </Location>
The directives are accumulated and the last one wins. So, if you need to override strict
Locationsettings for a subset of users/situations, have that block come after the more strict configuration block.
Theoretically this should work:
<Location /sub > Order deny,allow Require valid-user Satisfy all </Location> <Location /sub/foo> Order allow,deny </Location>
However in practice I'm finding that the
<Location /sub >section always takes precedence, no matter what order I have the directives in.
- Prior to version 2.4 Apache did not support nested LDAP groups
Much of the following is lifted directly from the official documentation .
<Location>sections are processed in the order they appear in the configuration file, after the
.htaccessfiles are read, and after the
- The specified location matches exactly the path component of the URL.
- The specified location, which ends in a forward slash, is a prefix of the path component of the URL (treated as a context root).
- The specified location, with the addition of a trailing slash, is a prefix of the path component of the URL (also treated as a context root).
In the example below, where no trailing slash is used, requests to
/private1/file.txtwill have the enclosed directives applied, but
<Location /private1> # ... </Location>
In the example below, where a trailing slash is used, requests to
/private2/file.txtwill have the enclosed directives applied, but
<Location /private2/> # ... </Location>
When to use
<Location>to apply directives to content that lives outside the filesystem. For content that lives in the filesystem, use
<Files>. An exception is
<Location />, which is an easy way to apply a configuration to the entire server.