svn commit: r1730730 - /httpd/httpd/trunk/docs/manual/sections.xml

[el...@apache.org]

Author: elukey
Date: Tue Feb 16 18:42:26 2016
New Revision: 1730730

URL: http://svn.apache.org/viewvc?rev=1730730&view=rev
Log:
New proposal for the sections.html documentation.


Modified:
    httpd/httpd/trunk/docs/manual/sections.xml

Modified: httpd/httpd/trunk/docs/manual/sections.xml
URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/manual/sections.xml?rev=1730730&r1=1730729&r2=1730730&view=diff
==============================================================================
--- httpd/httpd/trunk/docs/manual/sections.xml (original)
+++ httpd/httpd/trunk/docs/manual/sections.xml Tue Feb 16 18:42:26 2016
@@ -510,19 +510,7 @@ are interpreted, it is important to unde
     type="section">Directory</directive> container in the processing
     order.</p>
 
-<note><title>Merge is not always Override</title>
-    <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>
-    <p><directive>Directory</directive>, <directive>FilesMatch</directive>, 
-    <directive>Location</directive> and the other directives discussed in this section 
-    implement the same merging strategy, namely "override" when applied to the same target.</p>
-</note>
-
-<note><title>Technical Note</title>
+    <note><title>Technical Note</title>
       There is actually a
       <code>&lt;Location&gt;</code>/<code>&lt;LocationMatch&gt;</code>
       sequence performed just before the name translation phase
@@ -530,9 +518,54 @@ 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
       completed.
-</note>
+    </note>
 
-<section id="merge-examples"><title>Some Examples</title>
+<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>foo</code> header for a request to
+        <code>/example/index.html</code> ?
+    </p>
+    <highlight language="config">
+
+&lt;Directory "/"&gt;
+    Header set foo one
+    &lt;FilesMatch ".*"&gt;
+        Header set foo three
+    &lt;/FilesMatch&gt;
+&lt;/Directory&gt;
+
+&lt;Directory "/example"&gt;
+    Header set foo two
+&lt;/Directory&gt;
+     
+    </highlight>    
+    <ul>
+        <li><directive>Directory</directive> "/" matches and an initial configuration to set the "foo" header with the value "one" 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 "foo" header with the value "two".</li>
+        <li><directive>FilesMatch</directive> ".*" matches and another merge opportunity arises, causing the "foo" header
+        to be set with the value "three".</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 "foo" header with the value "three". <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 useful merge examples to practice</title>
 
 <p>Below is an artificial example to show the order of
 merging. Assuming they all apply to the request, the directives in
@@ -564,34 +597,6 @@ E.</p>
 
 </highlight>
 
-<p>Another interesting example is the following one. As described above, 
-<directive>FilesMatch</directive> is merged after <directive>Directory</directive>, 
-therefore a request for <code>/var/www/index.html</code> will eventually get the "foo" Header set to
-the value "two", not "three" as somebody might expect from a first look.
-</p>
-
-<highlight language="config">
-&lt;Directory "/"&gt;
-    Header set foo one
-    &lt;FilesMatch ".*"&gt;
-        Header set foo two
-    &lt;/FilesMatch&gt;
-&lt;/Directory&gt;
-
-&lt;Directory "/var/www"&gt;
-    Header set foo three
-&lt;/Directory&gt;
- 
-</highlight>
-
-<p>The chain of values that the "foo" header will get is: "one", "three" and "two". 
-It is important to notice that <directive>Directory</directive> and <directive>FilesMatch</directive> 
-implement the same merging strategy, namely "override" when 
-applied to the same path. In this example it means that the last directive applied in the merging order,
-<directive>FilesMatch</directive>, sets the final value for the "foo" header. 
-</p>
-<p>This is true for .htaccess too, since they have the same priority as <directive>Directory</directive>
-in the merging order.</p>
 
 <p>For a more concrete example, consider the following.  Regardless of
 any access restrictions placed in <directive module="core"