You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cvs@httpd.apache.org by el...@apache.org on 2016/02/16 13:32:08 UTC
svn commit: r1730673 - /httpd/httpd/trunk/docs/manual/sections.xml
Author: elukey
Date: Tue Feb 16 12:32:08 2016
New Revision: 1730673
URL: http://svn.apache.org/viewvc?rev=1730673&view=rev
Log:
Expanding sections.xml to address Bug: 58789
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=1730673&r1=1730672&r2=1730673&view=diff
==============================================================================
--- httpd/httpd/trunk/docs/manual/sections.xml (original)
+++ httpd/httpd/trunk/docs/manual/sections.xml Tue Feb 16 12:32: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>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>
@@ -510,12 +510,17 @@ 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>
There is actually a
@@ -559,6 +564,35 @@ 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">
+<Directory "/">
+ Header set foo one
+ <FilesMatch ".*">
+ Header set foo two
+ </FilesMatch>
+</Directory>
+
+<Directory "/var/www">
+ Header set foo three
+</Directory>
+
+</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"
type="section">Directory</directive> sections, the <directive
Re: svn commit: r1730673 - /httpd/httpd/trunk/docs/manual/sections.xml
Posted by Luca Toscano <to...@gmail.com>.
Hi Eric!
2016-02-18 15:24 GMT+01:00 Eric Covener <co...@gmail.com>:
> I know I used "foo", but it might be better for the docs to use
> something more descriptive for the name and value of the example
> header.
>
Yep I liked foo since it is always mentioned in programming examples, so I
thought it could have been good to keep. I'll add another term!
> some kind of markup problem in "Some useful merge examples to
> practice". it could also use example directives/values that made it
> easier to identify the moral ("subdir" etc)
Got it, I'll add more examples. I kept the ones already there since the
moral was in the newly created section, but maybe other ones might be
needed.
Luca
Re: svn commit: r1730673 - /httpd/httpd/trunk/docs/manual/sections.xml
Posted by Eric Covener <co...@gmail.com>.
I know I used "foo", but it might be better for the docs to use
something more descriptive for the name and value of the example
header.
some kind of markup problem in "Some useful merge examples to
practice". it could also use example directives/values that made it
easier to identify the moral ("subdir" etc)
On Wed, Feb 17, 2016 at 12:18 PM, Luca Toscano <to...@gmail.com> wrote:
> New version in http://httpd.apache.org/docs/trunk/sections.html#merging
>
>
> 2016-02-16 16:42 GMT+01:00 Luca Toscano <to...@gmail.com>:
>>
>> Update from the dev irc channel: I had a chat with Eric and he explained
>> to me with a lot more details how configuration and execution really work
>> for a module. The next step is for me to amend my patch and update bugzilla.
>>
>> Luca
>>
>> 2016-02-16 15:22 GMT+01:00 Eric Covener <co...@gmail.com>:
>>>
>>>
>>> The merging strategy is determined by the module implementing the
>>> repeated directive, e.g. mod_headers. The moral of this PR is that
>>> htacess and directory are the same, and wrapping directives in things
>>> like files/filesmatch generally gives those directives higher
>>> priority/precedence then unwrapped directives because it delays the
>>> processing of those directives.
>>
>>
>
--
Eric Covener
covener@gmail.com
Re: svn commit: r1730673 - /httpd/httpd/trunk/docs/manual/sections.xml
Posted by Luca Toscano <to...@gmail.com>.
New version in http://httpd.apache.org/docs/trunk/sections.html#merging
2016-02-16 16:42 GMT+01:00 Luca Toscano <to...@gmail.com>:
> Update from the dev irc channel: I had a chat with Eric and he explained
> to me with a lot more details how configuration and execution really work
> for a module. The next step is for me to amend my patch and update bugzilla.
>
> Luca
>
> 2016-02-16 15:22 GMT+01:00 Eric Covener <co...@gmail.com>:
>>
>>
>> The merging strategy is determined by the module implementing the
>> repeated directive, e.g. mod_headers. The moral of this PR is that
>> htacess and directory are the same, and wrapping directives in things
>> like files/filesmatch generally gives those directives higher
>> priority/precedence then unwrapped directives because it delays the
>> processing of those directives.
>>
>
>
Re: svn commit: r1730673 - /httpd/httpd/trunk/docs/manual/sections.xml
Posted by Luca Toscano <to...@gmail.com>.
Update from the dev irc channel: I had a chat with Eric and he explained to
me with a lot more details how configuration and execution really work for
a module. The next step is for me to amend my patch and update bugzilla.
Luca
2016-02-16 15:22 GMT+01:00 Eric Covener <co...@gmail.com>:
>
>
> The merging strategy is determined by the module implementing the
> repeated directive, e.g. mod_headers. The moral of this PR is that
> htacess and directory are the same, and wrapping directives in things
> like files/filesmatch generally gives those directives higher
> priority/precedence then unwrapped directives because it delays the
> processing of those directives.
>
Re: svn commit: r1730673 - /httpd/httpd/trunk/docs/manual/sections.xml
Posted by Eric Covener <co...@gmail.com>.
On Tue, Feb 16, 2016 at 7:32 AM, <el...@apache.org> wrote:
> +<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>
The merging strategy is determined by the module implementing the
repeated directive, e.g. mod_headers. The moral of this PR is that
htacess and directory are the same, and wrapping directives in things
like files/filesmatch generally gives those directives higher
priority/precedence then unwrapped directives because it delays the
processing of those directives.