How does Apache merge multiple matching Location sections

Question

I'm working on some basic apache configuration, but I don't understand precisely how apache merges different <Location> sections when several of them match an incoming requests URL. The apache documentation in its "How the sections are merged" chapter is a little bit confusing when it comes to the order/priority of several matching sections of the same type.

For example, imagine the following apache configuration (ignore whether the actual contents make sense or not, I'm only interested in the application order of each rule/section):

<Location / >
  ProxyPass http://backend.com/
  Order allow,deny
  Satisfy any
</Location>

<Location /sub/foo>
  Order allow,deny
</Location>

<Location /sub >
  Order deny,allow
  Require valid-user
  Satisfy all
</Location>

<Location /doesnt/match >
  ProxyPass !
</Location>

Now if a client makes a request to /sub/foobar, which is the final configuration that will be applied to this request?

Is the applied configuration the equivalent of:

# All the directives contained in all the matchin Locations in declaration order
ProxyPass http://backend.com/
Order allow,deny
Satisfy any
Order allow,deny
Order deny,allow
Require valid-user
Satisfy all

or maybe

# same as above, but with longest matching path last
ProxyPass http://backend.com/
Order allow,deny
Satisfy any
Order deny,allow
Require valid-user
Satisfy all
Order allow,deny

or something completely different.

Thanks for your help, I'm really confusing.

Answer 1

According to the docs, the order of merging is as follows;

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 , each group is processed in the order that they appear in the configuration files.

Hence in your example above, a request to /sub/foobar would match the first 3 Location in order, hence the last one wins for conflicting directives.

My tests indicate that it accumulates the directives, with the last one winning. So from your example above;

<Location / >
  ProxyPass http://backend.com/
  Order allow,deny
  Satisfy any
</Location>

<Location /sub/foo>
  Order allow,deny
</Location>

<Location /sub >
  Order deny,allow
  Require valid-user
  Satisfy all
</Location>

<Location /doesnt/match >
  ProxyPass !
</Location>

goes to ....

  ProxyPass http://backend.com/
  Order allow,deny
  Satisfy any
  Order allow,deny
  Order deny,allow
  Require valid-user
  Satisfy all   
  ProxyPass !  <--- not matches

which goes to;

  ProxyPass http://backend.com/
  Order deny,allow
  Require valid-user
  Satisfy all   

(You are right that it is not clear from the docs how some of the edge cases are resolved, its possible that any allow from * type directives would be connected to the associated Order allow,deny, but I didn't test that. Also what happens if you match Satisfy Any but you have previously collected an Allow from *...)

interesting note about ProxyPass

Just to be annoying, ProxyPass appears to work in the other direction.... ;-)

Ordering ProxyPass Directives

The configured ProxyPass and ProxyPassMatch rules are 

checked in the order of configuration. The first rule that matches wins. So usually you should sort conflicting ProxyPass rules starting with the longest URLs first. Otherwise later rules for longer URLS will be hidden by any earlier rule which uses a leading substring of the URL. Note that there is some relation with worker sharing.

For the same reasons exclusions must come before the general 

ProxyPass directives.