to another site only if the server is started using
<code>httpd -DClosedForNow</code>:</p>
-<example>
-<IfDefine ClosedForNow><br />
-Redirect / http://otherserver.example.com/<br />
+<highlight language="config">
+<IfDefine ClosedForNow>
+ Redirect / http://otherserver.example.com/
</IfDefine>
-</example>
+</highlight>
<p>The <directive type="section" module="core">IfModule</directive>
directive is very similar, except it encloses directives that will
module="mod_mime_magic">MimeMagicFile</directive> directive will be
applied only if <module>mod_mime_magic</module> is available.</p>
-<example>
-<IfModule mod_mime_magic.c><br />
-MimeMagicFile conf/magic<br />
+<highlight language="config">
+<IfModule mod_mime_magic.c>
+ MimeMagicFile conf/magic
</IfModule>
-</example>
+</highlight>
<p>The <directive type="section" module="mod_version">IfVersion</directive>
directive is very similar to <directive type="section"
module is designed for the use in test suites and large networks which have to
deal with different httpd versions and different configurations.</p>
-<example>
- <IfVersion >= 2.1><br />
- <indent>
- # this happens only in versions greater or<br />
- # equal 2.1.0.<br />
- </indent>
- </IfVersion>
-</example>
+<highlight language="config">
+<IfVersion >= 2.1>
+ # this happens only in versions greater or
+ # equal 2.1.0.
+</IfVersion>
+</highlight>
<p><directive type="section" module="core">IfDefine</directive>,
<directive type="section" module="core">IfModule</directive>, and the
following configuration, directory indexes will be enabled for the
<code>/var/web/dir1</code> directory and all subdirectories.</p>
-<example>
-<Directory /var/web/dir1><br />
-Options +Indexes<br />
+<highlight language="config">
+<Directory /var/web/dir1>
+ Options +Indexes
</Directory>
-</example>
+</highlight>
<p>Directives enclosed in a <directive type="section"
module="core">Files</directive> section apply to any file with
deny access to any file named <code>private.html</code> regardless
of where it is found.</p>
-<example>
-<Files private.html><br />
-Order allow,deny<br />
-Deny from all<br />
+<highlight language="config">
+<Files private.html>
+ Order allow,deny
+ Deny from all
</Files>
-</example>
+</highlight>
<p>To address files found in a particular part of the filesystem, the
<directive type="section" module="core">Files</directive> and
of <code>private.html</code> found under the <code>/var/web/dir1/</code>
directory.</p>
-<example>
-<Directory /var/web/dir1><br />
-<Files private.html><br />
-Order allow,deny<br />
-Deny from all<br />
-</Files><br />
+<highlight language="config">
+<Directory /var/web/dir1>
+ <Files private.html>
+ Order allow,deny
+ Deny from all
+ </Files>
</Directory>
-</example>
+</highlight>
</section>
<section id="webspace"><title>Webspace Containers</title>
<code>http://yoursite.example.com/private/dir/file.html</code> as well
as any other requests starting with the <code>/private</code> string.</p>
-<example>
-<LocationMatch ^/private><br />
-Order Allow,Deny<br />
-Deny from all<br />
+<highlight language="config">
+<LocationMatch ^/private>
+ Order Allow,Deny
+ Deny from all
</LocationMatch>
-</example>
+</highlight>
<p>The <directive type="section" module="core">Location</directive>
directive need not have anything to do with the filesystem.
No file called <code>server-status</code> needs to exist in the
filesystem.</p>
-<example>
-<Location /server-status><br />
-SetHandler server-status<br />
+<highlight language="config">
+<Location /server-status>
+ SetHandler server-status
</Location>
-</example>
+</highlight>
</section>
<section id="wildcards"><title>Wildcards and Regular Expressions</title>
<p>A non-regex wildcard section that changes the configuration of
all user directories could look as follows:</p>
-<example>
-<Directory /home/*/public_html><br />
-Options Indexes<br />
+<highlight language="config">
+<Directory /home/*/public_html>
+ Options Indexes
</Directory>
-</example>
+</highlight>
<p>Using regex sections, we can deny access to many types of image files
at once:</p>
-<example>
-<FilesMatch \.(?i:gif|jpe?g|png)$><br />
-Order allow,deny<br />
-Deny from all<br />
+<highlight language="config">
+<FilesMatch \.(?i:gif|jpe?g|png)$>
+ Order allow,deny
+ Deny from all
</FilesMatch>
-</example>
+</highlight>
</section>
location, allowing your restrictions to be circumvented.
For example, consider the following configuration:</p>
-<example>
-<Location /dir/><br />
-Order allow,deny<br />
-Deny from all<br />
+<highlight language="config">
+<Location /dir/>
+ Order allow,deny
+ Deny from all
</Location>
-</example>
+</highlight>
<p>This works fine if the request is for
<code>http://yoursite.example.com/dir/</code>. But what if you are on
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>cnn.com</code> website.</p>
-
-<example>
-<Proxy http://cnn.com/*><br />
-Order allow,deny<br />
-Deny from all<br />
+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/*">
+ Order allow,deny
+ Allow from 192.168.1.104 192.168.1.205
+ Deny from all
</Proxy>
-</example>
+</highlight>
</section>
<section id="whatwhere"><title>What Directives are Allowed?</title>
type="section">Directory</directive> container in the processing
order.</p>
- <p>Later sections override earlier ones.</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>
this example will be applied in the order A > B > C > D >
E.</p>
-<example>
-<Location /><br />
-E<br />
-</Location><br />
-<br />
-<Files f.html><br />
-D<br />
-</Files><br />
-<br />
-<VirtualHost *><br />
-<Directory /a/b><br />
-B<br />
-</Directory><br />
-</VirtualHost><br />
-<br />
-<DirectoryMatch "^.*b/"><br />
-C<br />
-</DirectoryMatch><br />
-<br />
-<Directory /a/b><br />
-A<br />
-</Directory><br />
-<br />
-</example>
+<highlight language="config">
+<Location "/">
+ E
+</Location>
+
+<Files "f.html">
+ D
+</Files>
+
+<VirtualHost *>
+<Directory "/a/b">
+ B
+</Directory>
+</VirtualHost>
+
+<DirectoryMatch "^.*b$">
+ C
+</DirectoryMatch>
+
+<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"
evaluated last and will allow unrestricted access to the server. In
other words, order of merging is important, so be careful!</p>
-<example>
-<Location /><br />
-Order deny,allow<br />
-Allow from all<br />
-</Location><br />
-<br />
-# Woops! This <Directory> section will have no effect<br />
-<Directory /><br />
-Order allow,deny<br />
-Allow from all<br />
-Deny from badguy.example.com<br />
+<highlight language="config">
+<Location "/">
+ Require all granted
+</Location>
+
+# Woops! This <Directory> section will have no effect
+<Directory "/">
+ <RequireAll>
+ Require all granted
+ Require not host badguy.example.com
+ </RequireAll>
</Directory>
-</example>
+</highlight>
</section>
projects / thirdparty / apache / httpd.git / commitdiff
