httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Erenkrantz <>
Subject Re: AddOutputFilterByType oddness
Date Fri, 24 Sep 2004 07:21:09 GMT
--On Thursday, September 23, 2004 12:43 PM +0100 Nick Kew <> 

> Basically it does the lookup/dispatch once per filter in the filterchain
> per request.  It checks that filter's providers until it finds a match.
> So for anything you could do with an [Add|Set]OutputFilter[ByType]
> that's one lookup per request.

Okay, so if I have three rules and ten filters, we'll be doing thirty checks, 
right?  And, this will happen even if mod_filter isn't configured - as 
mod_filter still needs to check ten times that it doesn't have anything to do, 
right?  Hmm.  How expensive is this again?

> mod_filter takes the content-type as it is at that point in the chain.
> Isn't the real nightmare where a filter calls ap_set_content_type and
> some AddOutputFilterByTypes are in effect?  I guess what *really* bothers
> me is the idea of adding filters *as a side-effect*.

How wouldn't it be a side-effect?  It's intentional from the admin 
perspective, but a side-effect from the developer's perspective.

>>	  And, then
>> mod_deflate needs to be conditionally added (sub-case #1: it needs to be
>> added for 'text/plain'; sub-case #2: it needs to be added for 'text/html').
>> How and where is it added?  Are you inserting dummy filters?
> I'm not sure I follow.  It will dispatch to deflate based on the
> content-type (or other dispatch criterion) as it is at that point
> in the chain.

The question is at which point in the chain does deflate get added?

> So if the handler sets application/xml but that goes through an XSLT
> filter which sets it to text/html, then mod_filter sees application/xml
> if it's before the XSLT filter in the chain, or text/html after it.
> How can AddOutputFilterByType expect to cope with that?

I thought you suggested that mod_filter could easily handle this case.  I'm 
still not seeing how.

> But FWIW I have that working locally with
> FilterDeclare   filter1 Content-Type    CONTENT_SET
> FilterDeclare   filter2 Content-Length  CONTENT_SET
> FilterProvider  filter1 filter2 $text
> FilterProvider  filter2 DEFLATE >4000
> FilterChain     filter1
> to deflate all "text/*" documents of 4k or greater.

Can I comment that I think a clearer configuration syntax is going to be 
needed if we are going to axe all of the current filter directives?

AddOutputFilterByType, for all of its internal oddness, is a simple directive 
for an administrator to understand.  So, perhaps keep 'AddOutputFilterByType' 
and having it internally converted to a mod_filter directive.  But, I'm just 
not overly excited about moving all filter configuration directives to 
something akin to mod_rewrite.  Ouch.  -- justin

View raw message