Apache HTTP Server

From WhyAskWhy.org Wiki
Revision as of 12:23, 20 February 2015 by Deoren (talk | contribs) (Saving notes on Directive precedence/processing order. My results are not matching the official documentation.)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search


Directives - Order of precedence/merging

[1] 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:

  1. <Directory> (except regular expressions) and .htaccess done simultaneously (with .htaccess, if allowed, overriding <Directory>)
  2. <DirectoryMatch> (and <Directory ~>)
  3. <Files> and <FilesMatch> done simultaneously
  4. <Location> and <LocationMatch> done simultaneously

Apart from <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 Include directive.

Sections inside <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 mod_proxy, the <Proxy> container takes the place of the <Directory> container in the processing order.

Later sections override earlier ones.


A quick summary [2]:

  1. Apache configuration file is parsed top to bottom.
  2. Included files are parsed right at their include location. In other words, within the configuration file.
  3. For directives which are called more than once, the last call overrides the previous calls.
  4. For a directive called more than once in a directory tree, the lowest call in the directory tree takes precedence.
  5. .htaccess directives 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 Location path (both referring to the same overall path) like this [3]:

<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 Location settings 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.


LDAP

Nested Groups

  • Prior to version 2.4 Apache did not support nested LDAP groups


Location Directive

Much of the following is lifted directly from the official documentation [4].

Processing order

  • <Location> sections are processed in the order they appear in the configuration file, after the <Directory> sections and .htaccess files are read, and after the <Files> sections.

Matching rules

  • 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, /private1/ and /private1/file.txt will have the enclosed directives applied, but /private1other would not.

<Location /private1>
    #  ...
</Location>

In the example below, where a trailing slash is used, requests to /private2/ and /private2/file.txt will have the enclosed directives applied, but /private2 and /private2other would not.

<Location /private2/>
    # ...
</Location>

When to use <Location>

Use <Location> to apply directives to content that lives outside the filesystem. For content that lives in the filesystem, use <Directory> and <Files>. An exception is <Location />, which is an easy way to apply a configuration to the entire server.


References