httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Erenkrantz <>
Subject Re: Ideas for Smart Filtering
Date Sun, 01 Aug 2004 10:02:19 GMT
--On Sunday, August 1, 2004 10:54 AM +0100 Nick Kew <> wrote:

> (btw, if you think AP_FTYPE_RESOURCE should be AP_FTYPE_CONTENT_SET,
> that's another weakness of the architecture.  If we need to transcode
> *before* a content filter, then we can't use CONTENT_SET.
> Solution: this needs to be configurable).

Best configurable via C code not our one-off-XML configuration syntax.  ;-)

(How about moving our config syntax to Python?  Whitespace matters!  j/k)

> The point is that content-length *is* set by many handlers, and has to be
> unset by filters.  The second point is that there *are* a bunch of bugs
> arising from that (e.g. mod_deflate in 2.0.x vs recent fixes in 2.1-HEAD).
> The KISS principle tells us that simplifying the task of filtering
> content will reduce the bug count.


> Instead of requiring every filter to worry about that, we let filters
> simply declare their behaviour.

My point is they won't know what their behavior is until after they start 

>> going to provide any real benefits.  Nothing can make use of that knowledge
>> anyway because they have to account for all cases!  So, any benefit for
>> corner-case optimization is lost by the increase in complexity just added.
> No, the whole point is to *reduce* complexity!

I wish, but I'm not seeing how it'll reduce the complexity.  I think the 
complexity in managing the state transitions would overwhelm it.  -- justin

View raw message