On Wed, 22 Sep 2004, Justin Erenkrantz wrote: > --On Wednesday, September 22, 2004 5:01 PM +0100 Nick Kew <[EMAIL PROTECTED]> > wrote: > > > I've said it before and I'll say it again: AddOutputFilterByType is > > fundamentally unsatisfactory. This confusion is an effect, not cause. > > Suffice to say, I disagree. > > > * Configuration is inconsistent with other filter directives. The > > relationship with [Set|Add|Remove]OutputFilter is utterly unintuitive > > and, from a user POV, broken. > > I think it's really clear from the user's perspective. I think the problem > comes in on the developer's side.
It seems to me heavily counterintuitive that mixing ByType directives with anything else means that the ByType filters *always* come last. And that Remove won't affect them, but will affect others. > > * Tying it to ap_set_content_type is, to say the least, hairy. > > IMO we shouldn't *require* modules to call this, and it's utterly > > unreasonable to expect that it will never be called more than once > > for a request, given the number of modules that might take an interest. > > Especially when subrequests and internal redirects may be involved. > > We have *always* mandated that ap_set_content_type() should be called rather > than setting r->content_type. (I wish we could remove content_type from > request_rec instead.) Indeed. But that doesn't prevent it being called multiple times, perhaps from different modules. So using it to insert filters leaves lots of potantial for trouble. > > * It's a complexity just waiting for modules to break on it. > > Anything that depends upon content-type like this is going to be hairy because > there may be several 'right' answers during the course of the request. Indeed. mod_filter addresses this by configuring at the last moment, so any earlier set_content_type()s are irrelevant. I don't suppose it's a panacaea for everything, but I do think it's a significant improvement on what we have. > > I've made some more updates to mod_filter since I last posted on the > > subject, and I'm getting some very positive feedback from real users. > > For 2.2 I'd like to remove AddOutputFilterByType entirely, replacing > > it with mod_filter. > > I've yet to see a clear and concise statement as to how mod_filter will solve > this problem in a better and more efficient way. (Especially from a user's > perspective, but also from a developer's perspective.) >From the user's perspective, it's simply more powerful and flexible. Works with any request or response headers (not just content-type) or environment variables. Gets rid of constraints on ordering, like AddOutputFilterbyType filter always coming after other filters regardless of ordering in httpd.conf. Example: I have a user who wants to insert mod_deflate in a reverse proxy, but only for selected content-types AND not if the content length is below a threshold. How would he do that with the old filter framework? >From a developers perspective, I wrote it for myself, and have at least two other developers using it operationally in their product. Time will tell what others may use it for. > I will also comment that I looked in the mod_filter code the other day and was > disappointed that it doesn't follow our coding style at all or even have > comments that help people understand what it is trying to do inside the .c > file. When was that? I made quite a lot of updates to the style towards conforming (like eliminating tabs and realigning some braces) before committing to CVS, but I'm willing to believe I need to look more carefully. -- Nick Kew
