Documentation rebuild

git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/branches/2.4.x@1731195 13f79535-47bb-0310-9956-ffa450edef68

1 files changed, 49 insertions, 14 deletions

diff --git a/docs/manual/sections.html.en b/docs/manual/sections.html.en
index 5e115c518e..33ce214887 100644
--- a/docs/manual/sections.html.en
+++ b/docs/manual/sections.html.en
@@ -361,12 +361,12 @@ see the <a href="vhosts/">Virtual Host Documentation</a>.</p>
 and <code class="directive"><a href="./mod/mod_proxy.html#proxymatch">&lt;ProxyMatch&gt;</a></code>
 containers apply enclosed configuration directives only
 to sites accessed through <code class="module"><a href="./mod/mod_proxy.html">mod_proxy</a></code>'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>
 
 <pre class="prettyprint lang-config">&lt;Proxy "http://www.example.com/*"&gt;
-    Require all granted
+    Require host yournetwork.example.com
 &lt;/Proxy&gt;</pre>
 
 </div><div class="top"><a href="#page-header"><img alt="top" src="./images/up.gif" /></a></div>
@@ -452,14 +452,7 @@ are interpreted, it is important to understand how this works.</p>
     container takes the place of the <code class="directive"><a href="./mod/core.html#directory">&lt;Directory&gt;</a></code> 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>
-
-<div class="note"><h3>Technical Note</h3>
+    <div class="note"><h3>Technical Note</h3>
       There is actually a
       <code>&lt;Location&gt;</code>/<code>&lt;LocationMatch&gt;</code>
       sequence performed just before the name translation phase
@@ -467,9 +460,50 @@ are interpreted, it is important to understand how this works.</p>
       are used to map URLs to filenames). The results of this
       sequence are completely thrown away after the translation has
       completed.
-</div>
+    </div>
+
+<h3><a name="relationship-module-configuration" id="relationship-module-configuration">Relationship between modules and configuration sections</a></h3>
+    <p>One question that often arises after reading how configuration sections are
+    merged is related to how and when directives of specific modules like <code class="module"><a href="./mod/mod_rewrite.html">mod_rewrite</a></code>
+    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 
+        <code class="directive"><a href="./mod/mod_headers.html#header">Header</a></code> directive of <code class="module"><a href="./mod/mod_headers.html">mod_headers</a></code> 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>
+    <pre class="prettyprint lang-config">&lt;Directory "/"&gt;
+    Header set CustomHeaderName one
+    &lt;FilesMatch ".*"&gt;
+        Header set CustomHeaderName three
+    &lt;/FilesMatch&gt;
+&lt;/Directory&gt;
 
-<h3><a name="merge-examples" id="merge-examples">Some Examples</a></h3>
+&lt;Directory "/example"&gt;
+    Header set CustomHeaderName two
+&lt;/Directory&gt;</pre>
+    
+    <ul>
+        <li><code class="directive">Directory</code> "/" matches and an initial configuration to set the <code>CustomHeaderName</code> header with the value <code>one</code> is created.</li>
+        <li><code class="directive">Directory</code> "/example" matches, and since <code class="module"><a href="./mod/mod_headers.html">mod_headers</a></code> 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><code class="directive">FilesMatch</code> ".*" 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 <code class="module"><a href="./mod/mod_headers.html">mod_headers</a></code> will be called and it will receive the configuration to set the <code>CustomHeaderName</code> header with the value <code>three</code>. <code class="module"><a href="./mod/mod_headers.html">mod_headers</a></code> 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 <code class="directive">Directory</code> in the merge order. The important concept to understand is that configuration sections like  <code class="directive">Directory</code> and <code class="directive">FilesMatch</code> are not comparable to module specific directives like <code class="directive"><a href="./mod/mod_headers.html#header">Header</a></code> or <code class="directive"><a href="./mod/mod_rewrite.html#rewriterule">RewriteRule</a></code> because they operate on different levels.
+    </p>
+
+
+<h3><a name="merge-examples" id="merge-examples">Some useful examples</a></h3>
 
 <p>Below is an artificial example to show the order of
 merging. Assuming they all apply to the request, the directives in
@@ -499,6 +533,7 @@ E.</p>
 &lt;/Directory&gt;</pre>
 
 
+
 <p>For a more concrete example, consider the following.  Regardless of
 any access restrictions placed in <code class="directive"><a href="./mod/core.html#directory">&lt;Directory&gt;</a></code> sections, the <code class="directive"><a href="./mod/core.html#location">&lt;Location&gt;</a></code> section will be
 evaluated last and will allow unrestricted access to the server.  In