httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nick Kew <>
Subject Re: svn commit: r1053515 - /httpd/httpd/trunk/CHANGES
Date Wed, 29 Dec 2010 11:12:12 GMT

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:
>> Subject: Re: svn commit: r1053515 - /httpd/httpd/trunk/CHANGES
>> On 29 Dec 2010, at 03:03, wrote:
>>> Author: covener
>>> Date: Wed Dec 29 03:03:35 2010
>>> New Revision: 1053515
>>> URL:
>>> 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
View raw message