httpd-cvs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject svn commit: r1731194 - /httpd/httpd/branches/2.4.x/docs/manual/sections.xml
Date Fri, 19 Feb 2016 08:05:08 GMT
Author: elukey
Date: Fri Feb 19 08:05:08 2016
New Revision: 1731194

Improved sections doc for Bug: 58789


Modified: httpd/httpd/branches/2.4.x/docs/manual/sections.xml
--- httpd/httpd/branches/2.4.x/docs/manual/sections.xml (original)
+++ httpd/httpd/branches/2.4.x/docs/manual/sections.xml Fri Feb 19 08:05:08 2016
@@ -405,13 +405,13 @@ see the <a href="vhosts/">Virtual Host D
 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></code> website.</p>
+that match the specified URL. For example, the following configuration
+will allow only a subset of clients to access the
+<code></code> website using the proxy server:</p>
 <highlight language="config">
 &lt;Proxy "*"&gt;
-    Require all granted
+    Require host
@@ -510,14 +510,7 @@ are interpreted, it is important to unde
     type="section">Directory</directive> container in the processing
-    <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
       sequence performed just before the name translation phase
@@ -525,9 +518,53 @@ are interpreted, it is important to unde
       are used to map URLs to filenames). The results of this
       sequence are completely thrown away after the translation has
+    </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">
+&lt;Directory "/"&gt;
+    Header set CustomHeaderName one
+    &lt;FilesMatch ".*"&gt;
+        Header set CustomHeaderName three
+    &lt;/FilesMatch&gt;
+&lt;Directory "/example"&gt;
+    Header set CustomHeaderName two
+    </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 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
@@ -559,6 +596,7 @@ E.</p>
 <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

View raw message