You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cvs@httpd.apache.org by co...@apache.org on 2010/12/29 04:03:36 UTC
svn commit: r1053515 - /httpd/httpd/trunk/CHANGES
Author: covener
Date: Wed Dec 29 03:03:35 2010
New Revision: 1053515
URL: http://svn.apache.org/viewvc?rev=1053515&view=rev
Log:
add a 2.3.9-era CHANGES entry that should have been noted for
mod_headers defaults.
Should I flag this CHANGES entry in any way?
Modified:
httpd/httpd/trunk/CHANGES
Modified: httpd/httpd/trunk/CHANGES
URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/CHANGES?rev=1053515&r1=1053514&r2=1053515&view=diff
==============================================================================
--- httpd/httpd/trunk/CHANGES [utf-8] (original)
+++ httpd/httpd/trunk/CHANGES [utf-8] Wed Dec 29 03:03:35 2010
@@ -76,6 +76,9 @@ Changes with Apache 2.3.9
Fix a denial of service attack against mod_reqtimeout.
[Stefan Fritsch]
+ *) mod_headers: Change default first argument of Header directive
+ from "onsuccess" to "always". [Eric Covener]
+
*) mod_include: Add the onerror attribute to the include element,
allowing an URL to be specified to include on error. [Graham
Leggett]
RE: svn commit: r1053515 - /httpd/httpd/trunk/CHANGES
Posted by "Plüm, Rüdiger, VF-Group" <ru...@vodafone.com>.
> -----Original Message-----
> From: Nick Kew
> Sent: Mittwoch, 29. Dezember 2010 12:12
> To: dev@httpd.apache.org
> Subject: Re: svn commit: r1053515 - /httpd/httpd/trunk/CHANGES
>
>
> On 29 Dec 2010, at 10:46, Plüm, Rüdiger, VF-Group wrote:
>
> >
> >
> >> -----Original Message-----
> >> From: Nick Kew
> >> Sent: Mittwoch, 29. Dezember 2010 10:56
> >> To: dev@httpd.apache.org
> >> Subject: Re: svn commit: r1053515 - /httpd/httpd/trunk/CHANGES
> >>
> >>
> >> On 29 Dec 2010, at 03:03, covener@apache.org wrote:
> >>
> >>> Author: covener
> >>> Date: Wed Dec 29 03:03:35 2010
> >>> New Revision: 1053515
> >>>
> >>> URL: http://svn.apache.org/viewvc?rev=1053515&view=rev
> >>> Log:
> >>> add a 2.3.9-era CHANGES entry that should have been noted for
> >>> mod_headers defaults.
> >>
> >> Whoa! Much confusion seeing and then checking this, then 1053523,
> >> against 2.3 docs before seeing 1053516!
> >>
> >> "Why doesn't my Header work?" is becoming a bit of a FAQ.
> >>
> >> It's also a rather ugly hack for several reasons, of which
> >> the complexity
> >> you're getting to grips with documenting is a symptom.
> I'm wondering
> >> about a couple of changes that might help, but still need to
> >> think through
> >> possible (unintended) consequences.
> >>
> >> 1. Using an output filter with the idiom "do something that
> >> isn't a filter
> >> operation on first-call then remove myself" is ugly.
> How about an
> >> ap_hook_pre_filter hook for functions such as these? With an
> >> AP_FTYPE_* argument (AP_FTYPE_PROTOCOL for mod_headers)
> >> to determine ordering?
> >
> > I don't see why this is needed or why the current way is ugly.
> > The current way seems to work fine and there are other
> filters like the
> > HTTP header filter that work in the same way. IMHO it
> offers a flexible
> > way to do the right thing at the right point of time.
>
> But the current way doesn't work fine, it results in
> complexity and confusion
> as evidenced in Eric's efforts at documenting it, or in some
> of the questions
> we get from puzzled users.
Is this really because mod_headers is working as an output filter
or because "always" doesn't do what you expect? I think these are
two distinct things.
Regards
Rüdiger
Re: svn commit: r1053515 - /httpd/httpd/trunk/CHANGES
Posted by Nick Kew <ni...@webthing.com>.
On 29 Dec 2010, at 10:46, Plüm, Rüdiger, VF-Group wrote:
>
>
>> -----Original Message-----
>> From: Nick Kew [mailto:nick@webthing.com]
>> Sent: Mittwoch, 29. Dezember 2010 10:56
>> To: dev@httpd.apache.org
>> Subject: Re: svn commit: r1053515 - /httpd/httpd/trunk/CHANGES
>>
>>
>> On 29 Dec 2010, at 03:03, covener@apache.org wrote:
>>
>>> Author: covener
>>> Date: Wed Dec 29 03:03:35 2010
>>> New Revision: 1053515
>>>
>>> URL: http://svn.apache.org/viewvc?rev=1053515&view=rev
>>> Log:
>>> add a 2.3.9-era CHANGES entry that should have been noted for
>>> mod_headers defaults.
>>
>> Whoa! Much confusion seeing and then checking this, then 1053523,
>> against 2.3 docs before seeing 1053516!
>>
>> "Why doesn't my Header work?" is becoming a bit of a FAQ.
>>
>> It's also a rather ugly hack for several reasons, of which
>> the complexity
>> you're getting to grips with documenting is a symptom. I'm wondering
>> about a couple of changes that might help, but still need to
>> think through
>> possible (unintended) consequences.
>>
>> 1. Using an output filter with the idiom "do something that
>> isn't a filter
>> operation on first-call then remove myself" is ugly. How about an
>> ap_hook_pre_filter hook for functions such as these? With an
>> AP_FTYPE_* argument (AP_FTYPE_PROTOCOL for mod_headers)
>> to determine ordering?
>
> I don't see why this is needed or why the current way is ugly.
> The current way seems to work fine and there are other filters like the
> HTTP header filter that work in the same way. IMHO it offers a flexible
> way to do the right thing at the right point of time.
But the current way doesn't work fine, it results in complexity and confusion
as evidenced in Eric's efforts at documenting it, or in some of the questions
we get from puzzled users.
And yes, the same comment applies to other filters, which is why I
spoke of the idiom rather than the instance.
It's ugly and hackish because it's a filter function performing a (purely)
non-filtering operation.
>> 2. Specific to mod_headers, we should presumably get better "always"
>> semantics by running a table merge before applying "always" rules.
>
> Not sure if merging is a good idea. I guess later filters / processing
> steps need them separated. So maybe we should simply apply the always rules
> to both tables.
I guess that should have the same effect, and I'll concede your point!
But in principle mod_headers should be last thing before the HTTP
protocol filter converts headers from apr_table to data stream, and
should mark the point beyond which manipulating headers becomes
a bug. The distinction between the two tables is also lost, as the
processing path thereafter can no longer affect the headers sent.
--
Nick Kew
Re: svn commit: r1053515 - /httpd/httpd/trunk/CHANGES
Posted by Eric Covener <co...@gmail.com>.
> So maybe we should simply apply the always rules
> to both tables.
This is the path I was going down, but I think you can only safely
"edit" both tables indiscriminately due to the matching component of
the action.
My first pass was adding an internal flag that suppressed the
set/add/merge-like operations when "always" was looking at the
r->headers_out, performing those only on err_headers_out.
But this still leaves unintuitive behavior for things like merge or
append, where the value is at least as likely to start in
r->headers_out, but could be in neither or both tables. This is why i
finally settled on the idea of changing nothing and trying to document
how 'always' might need to be used to get access to some seemingly
arbitrary pre-existing header values (only when you don't care about
these are the directives mostly intuitive)
--
Eric Covener
covener@gmail.com
RE: svn commit: r1053515 - /httpd/httpd/trunk/CHANGES
Posted by "Plüm, Rüdiger, VF-Group" <ru...@vodafone.com>.
> -----Original Message-----
> From: Nick Kew [mailto:nick@webthing.com]
> Sent: Mittwoch, 29. Dezember 2010 10:56
> To: dev@httpd.apache.org
> Subject: Re: svn commit: r1053515 - /httpd/httpd/trunk/CHANGES
>
>
> On 29 Dec 2010, at 03:03, covener@apache.org wrote:
>
> > Author: covener
> > Date: Wed Dec 29 03:03:35 2010
> > New Revision: 1053515
> >
> > URL: http://svn.apache.org/viewvc?rev=1053515&view=rev
> > Log:
> > add a 2.3.9-era CHANGES entry that should have been noted for
> > mod_headers defaults.
>
> Whoa! Much confusion seeing and then checking this, then 1053523,
> against 2.3 docs before seeing 1053516!
>
> "Why doesn't my Header work?" is becoming a bit of a FAQ.
>
> It's also a rather ugly hack for several reasons, of which
> the complexity
> you're getting to grips with documenting is a symptom. I'm wondering
> about a couple of changes that might help, but still need to
> think through
> possible (unintended) consequences.
>
> 1. Using an output filter with the idiom "do something that
> isn't a filter
> operation on first-call then remove myself" is ugly. How about an
> ap_hook_pre_filter hook for functions such as these? With an
> AP_FTYPE_* argument (AP_FTYPE_PROTOCOL for mod_headers)
> to determine ordering?
I don't see why this is needed or why the current way is ugly.
The current way seems to work fine and there are other filters like the
HTTP header filter that work in the same way. IMHO it offers a flexible
way to do the right thing at the right point of time.
>
> 2. Specific to mod_headers, we should presumably get better "always"
> semantics by running a table merge before applying "always" rules.
Not sure if merging is a good idea. I guess later filters / processing
steps need them separated. So maybe we should simply apply the always rules
to both tables.
Regards
Rüdiger
Re: svn commit: r1053515 - /httpd/httpd/trunk/CHANGES
Posted by Nick Kew <ni...@webthing.com>.
On 29 Dec 2010, at 03:03, covener@apache.org wrote:
> Author: covener
> Date: Wed Dec 29 03:03:35 2010
> New Revision: 1053515
>
> URL: http://svn.apache.org/viewvc?rev=1053515&view=rev
> Log:
> add a 2.3.9-era CHANGES entry that should have been noted for
> mod_headers defaults.
Whoa! Much confusion seeing and then checking this, then 1053523,
against 2.3 docs before seeing 1053516!
"Why doesn't my Header work?" is becoming a bit of a FAQ.
It's also a rather ugly hack for several reasons, of which the complexity
you're getting to grips with documenting is a symptom. I'm wondering
about a couple of changes that might help, but still need to think through
possible (unintended) consequences.
1. Using an output filter with the idiom "do something that isn't a filter
operation on first-call then remove myself" is ugly. How about an
ap_hook_pre_filter hook for functions such as these? With an
AP_FTYPE_* argument (AP_FTYPE_PROTOCOL for mod_headers)
to determine ordering?
2. Specific to mod_headers, we should presumably get better "always"
semantics by running a table merge before applying "always" rules.
Any obvious problems?
--
Nick Kew