httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Erenkrantz <jus...@erenkrantz.com>
Subject Re: Ideas for Smart Filtering
Date Sun, 01 Aug 2004 01:33:41 GMT
--On Friday, July 30, 2004 12:32 AM +0100 Nick Kew <nick@webthing.com> wrote:

> It generated an interesting discussion, including some interesting
> alternative ideas, last night on IRC.  Perhaps it can lead to a
> general-purpose module for 2.0 and an architecture update for 2.2?
>
> http://www.apachetutor.org/dev/smart-filter

In the future, can you *please* include the actual content rather than pasting 
a URL?  This made your idea really difficult to read this until I returned to 
a stable network connection.  (IRC isn't a suitable replacement for email!)

Yet, I'm not sure I understand the intent of your proposal.  Is it that you 
don't like the fact that each filter has to make a decision on whether it 
should stick around?  So, what you are proposing to do is to abstract those 
two decisions into separate functions - i.e. decide whether to accept, and 
another to perform the filter?

> ap_register_smart_filter(name, match, filter_func, ctx, protocol_flags)
>
> Now when the harness name is inserted in the filter chain, and there is a
> match with match, lookup_handler (referenced above) will returh our
> filter_func for filter name.

I'm not sure what 'match' is in this context.

> protocol_flags is an OR of flags such as
>
>     * AP_FILTER_NO_TRANSFORM (filter passes content through unchanged -
> required when Cache-Control: no-transform applies)
>     * AP_FILTER_PRESERVE_LENGTH (filter is a 1-1 mapping of bytes)
>     * AP_FILTER_NO_BYTERANGES (filter won't work on byteranges)
>     * AP_FILTER_NO_PROXY (don't use in a proxy)
>     * AP_FILTER_NO_CACHE (don't let the document be cacheable downstream -
> probably wants refining)
>     * AP_FILTER_NO_LOCAL_CACHE (don't let it be cacheable here)

What is the point of protocol_flags?  Why should the filter be forced to 
pre-declare these decisions?   Why can't I determine that dynamically?  I 
think it'd be a bad idea to key such HTTP/1.1 protocol issues in the filter 
API.  I think we should maintain protocol-agnosticism where possible.

So, to sum up: splitting out the decision whether the filter should run from 
it's filter function sounds fine.  But, I think the Filter* directives 
abstract too much in this particular case.  Let the filter itself decide.  -- 
justin

Mime
View raw message