--On Friday, July 30, 2004 12:32 AM +0100 Nick Kew <[EMAIL PROTECTED]> 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
