<highlight language="config">
<IfDefine ClosedForNow>
- Redirect / http://otherserver.example.com/
+ Redirect "/" "http://otherserver.example.com/"
</IfDefine>
</highlight>
<code>/var/web/dir1</code> directory and all subdirectories.</p>
<highlight language="config">
-<Directory /var/web/dir1>
+<Directory "/var/web/dir1">
Options +Indexes
</Directory>
</highlight>
of where it is found.</p>
<highlight language="config">
-<Files private.html>
+<Files "private.html">
Require all denied
</Files>
</highlight>
directory.</p>
<highlight language="config">
-<Directory /var/web/dir1>
- <Files private.html>
+<Directory "/var/web/dir1">
+ <Files "private.html">
Require all denied
</Files>
</Directory>
as any other requests starting with the <code>/private</code> string.</p>
<highlight language="config">
-<LocationMatch ^/private>
+<LocationMatch "^/private">
Require all denied
</LocationMatch>
</highlight>
filesystem.</p>
<highlight language="config">
-<Location /server-status>
+<Location "/server-status">
SetHandler server-status
</Location>
</highlight>
certain sections or directives are evaluated. For
<directive type="section" module="core">Location</directive> this would be:</p>
<highlight language="config">
-<Location /foo>
+<Location "/foo">
</Location>
-<Location /foo/bar>
+<Location "/foo/bar">
</Location>
</highlight>
<p><directive type="section" module="mod_alias">Alias</directive>es on the other hand,
are mapped vice-versa:</p>
<highlight language="config">
-Alias /foo/bar /srv/www/uncommon/bar
-Alias /foo /srv/www/common/foo
+Alias "/foo/bar" "/srv/www/uncommon/bar"
+Alias "/foo" "/srv/www/common/foo"
</highlight>
<p>The same is true for the <directive module="mod_proxy">ProxyPass</directive>
directives:</p>
<highlight language="config">
-ProxyPass /special-area http://special.example.com smax=5 max=10
-ProxyPass / balancer://mycluster/ stickysession=JSESSIONID|jsessionid nofailover=On
+ProxyPass "/special-area" "http://special.example.com" smax=5 max=10
+ProxyPass "/" "balancer://mycluster/" stickysession=JSESSIONID|jsessionid nofailover=On
</highlight>
</section>
all user directories could look as follows:</p>
<highlight language="config">
-<Directory /home/*/public_html>
+<Directory "/home/*/public_html">
Options Indexes
</Directory>
</highlight>
<p>Using regex sections, we can deny access to many types of image files
at once:</p>
<highlight language="config">
-<FilesMatch \.(?i:gif|jpe?g|png)$>
+<FilesMatch "\.(?i:gif|jpe?g|png)$">
Require all denied
</FilesMatch>
</highlight>
and modules like <module>mod_rewrite</module>.</p>
<highlight language="config">
-<DirectoryMatch ^/var/www/combined/(?<SITENAME>[^/]+)>
- require ldap-group cn=%{env:SITENAME},ou=combined,o=Example
+<DirectoryMatch "^/var/www/combined/(?<SITENAME>[^/]+)">
+ require ldap-group cn=%{env:MATCH_SITENAME},ou=combined,o=Example
</DirectoryMatch>
</highlight>
For example, consider the following configuration:</p>
<highlight language="config">
-<Location /dir/>
+<Location "/dir/">
Require all denied
</Location>
</highlight>
filesystem location. Therefore you should always use the filesystem
containers when you can. There is, however, one exception to this
rule. Putting configuration restrictions in a <code><Location
-/></code> section is perfectly safe because this section will apply
+"/"></code> section is perfectly safe because this section will apply
to all requests regardless of the specific URL.</p>
</section>
<section id="nesting"><title>Nesting of sections</title>
-<p>Some section types can be nested inside other section types. One the one
+<p>Some section types can be nested inside other section types. On the one
hand, <directive type="section" module="core">Files</directive> can be used
inside <directive type="section" module="core">Directory</directive>. On
the other hand, <directive type="section" module="core">If</directive> can
and <directive type="section" module="mod_proxy">ProxyMatch</directive>
containers apply enclosed configuration directives only
to sites accessed through <module>mod_proxy</module>'s proxy server
-that match the specified URL. For example, the following configuration
-will prevent the proxy server from being used to access the
-<code>www.example.com</code> website.</p>
+that match the specified URL. For example, the following configuration
+will allow only a subset of clients to access the
+<code>www.example.com</code> website using the proxy server:</p>
<highlight language="config">
<Proxy http://www.example.com/*>
- Require all granted
+ Require host yournetwork.example.com
</Proxy>
</highlight>
</section>
the order that they appear in the configuration files. <directive
type="section" module="core">Directory</directive> (group 1 above)
is processed in the order shortest directory component to longest.
- So for example, <code><Directory /var/web/dir></code> will
+ So for example, <code><Directory "/var/web/dir"></code> will
be processed before <code><Directory
- /var/web/dir/subdir></code>. If multiple <directive
+ "/var/web/dir/subdir"></code>. If multiple <directive
type="section" module="core">Directory</directive> sections apply
to the same directory they are processed in the configuration file
order. Configurations included via the <directive
type="section">Directory</directive> container in the processing
order.</p>
- <p>Later sections override earlier ones, however each module is responsible
- for interpreting what form this override takes. A later configuration section
- with directives from a given module might cause a conceptual "merge" of some
- directives, all directives, or a complete replacement of the modules
- configuration with the module defaults and directives explicitly listed in
- the later context.</p>
-
-<note><title>Technical Note</title>
+ <note><title>Technical Note</title>
There is actually a
<code><Location></code>/<code><LocationMatch></code>
sequence performed just before the name translation phase
are used to map URLs to filenames). The results of this
sequence are completely thrown away after the translation has
completed.
-</note>
+ </note>
+
+<section id="relationship-module-configuration"><title>Relationship between modules and configuration sections</title>
+ <p>One question that often arises after reading how configuration sections are
+ merged is related to how and when directives of specific modules like <module>mod_rewrite</module>
+ are processed. The answer is not trivial and needs a bit of background.
+ Each httpd module manages its own configuration, and each of its directives in httpd.conf specify one piece
+ of configuration in a particular context. httpd does not execute a command as it is read.</p>
+ <p>At runtime, the core of httpd iterates over the defined configuration sections in the order
+ described above to determine which ones apply to the current request. When the first section matches,
+ it is considered the current configuration for this request. If a subsequent section matches too,
+ then each module with a directive in either of the sections is given a chance to merge its configuration between the two sections. The result is a third configuration, and the process goes on until all the configuration sections
+ are evaluated.</p>
+ <p>After the above step, the "real" processing of the HTTP request begins: each module has a chance to run
+ and perform whatever tasks they like. They can retrieve their own final merged configuration from the core
+ of the httpd to determine how they should act.</p>
+ <p>An example can help to visualize the whole process. The following configuration uses the
+ <directive module="mod_headers">Header</directive> directive of <module>mod_headers</module> to set
+ a specific HTTP header. What value will httpd set in the <code>CustomHeaderName</code> header for a request to
+ <code>/example/index.html</code> ?
+ </p>
+ <highlight language="config">
+
+<Directory "/">
+ Header set CustomHeaderName one
+ <FilesMatch ".*">
+ Header set CustomHeaderName three
+ </FilesMatch>
+</Directory>
+
+<Directory "/example">
+ Header set CustomHeaderName two
+</Directory>
+
+ </highlight>
+ <ul>
+ <li><directive>Directory</directive> "/" matches and an initial configuration to set the <code>CustomHeaderName</code> header with the value <code>one</code> is created.</li>
+ <li><directive>Directory</directive> "/example" matches, and since <module>mod_headers</module> specifies in its code to override in case of a merge, a new configuration is created to set the <code>CustomHeaderName</code> header with the value <code>two</code>.</li>
+ <li><directive>FilesMatch</directive> ".*" matches and another merge opportunity arises, causing the <code>CustomHeaderName</code> header to be set with the value <code>three</code>.</li>
+ <li>Eventually during the next steps of the HTTP request processing <module>mod_headers</module> will be called and it will receive the configuration to set the <code>CustomHeaderName</code> header with the value <code>three</code>. <module>mod_headers</module> normally uses this configuration to perfom its job, namely setting the foo header. This does not mean that a module can't perform a more complex action like discarding directives because not needed or deprecated, etc..</li>
+ </ul>
+
+ <p>This is true for .htaccess too since they have the same priority as <directive>Directory</directive> in the merge order. The important concept to understand is that configuration sections like <directive>Directory</directive> and <directive>FilesMatch</directive> are not comparable to module specific directives like <directive module="mod_headers">Header</directive> or <directive module="mod_rewrite">RewriteRule</directive> because they operate on different levels.
+ </p>
+</section>
-<section id="merge-examples"><title>Some Examples</title>
+<section id="merge-examples"><title>Some useful examples</title>
<p>Below is an artificial example to show the order of
merging. Assuming they all apply to the request, the directives in
E.</p>
<highlight language="config">
-<Location />
+<Location "/">
E
</Location>
-<Files f.html>
+<Files "f.html">
D
</Files>
<VirtualHost *>
-<Directory /a/b>
- B
-</Directory>
+ <Directory "/a/">
+ B
+ </Directory>
</VirtualHost>
<DirectoryMatch "^.*b$">
C
</DirectoryMatch>
-<Directory /a/b>
+<Directory "/a/b">
A
</Directory>
</highlight>
+
<p>For a more concrete example, consider the following. Regardless of
any access restrictions placed in <directive module="core"
type="section">Directory</directive> sections, the <directive
other words, order of merging is important, so be careful!</p>
<highlight language="config">
-<Location />
+<Location "/">
Require all granted
</Location>
-# Woops! This <Directory> section will have no effect
-<Directory />
+# Whoops! This <Directory> section will have no effect
+<Directory "/">
<RequireAll>
Require all granted
Require not host badguy.example.com
projects / apache / blobdiff