> -----Original Message----- > From: Nick Kew [mailto:[email protected]] > Sent: Mittwoch, 29. Dezember 2010 10:56 > To: [email protected] > Subject: Re: svn commit: r1053515 - /httpd/httpd/trunk/CHANGES > > > On 29 Dec 2010, at 03:03, [email protected] 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
