On Sat, Jun 08, 2002 at 01:02:32AM -0700, Greg Stein wrote: > This feels totally extraneous to me. The 'insert_filter' hook is defined to > run *right before* the handler is called. It is the absolute latest hook. It > would seem there is no difference between using that one and any kind of > init-filter hook.
Nope, the insert_filter hook would be run unconditionally even if the filter isn't present. Therefore, unless each module were to walk through the filter chain *itself* to determine if its filter was in the chain or not, there is a lot of wasted time. Also, AIUI, hooks are only valid one per file, so we couldn't have separate setup funcs per input and output filters. mod_include wouldn't want to set r->no_local_copy for *every* request. It'd only want to do so when it is present and we're about to serve the page. > (in fact, filter initialization is/can also be done as the filter is > inserted. the caller can initialize the context for use by the filter) The issue is that if we were to call this before the handlers were invoked, then it could potentially be called too early or too often. I'm thinking of subrequests here - if the data isn't going to be generated, then why bother initializing the context? > Just what is the benefit of this relative to inserting a filter with a > specific context, and/or by using the insert_filter hook. How can mod_include when it is only present as a filter indicate that the request is dynamic and can't honor If-Modified-Since et al requests? In this case, it has to set r->no_local_copy = 1. And, it must do so before the handlers begin because they can call ap_meets_conditions() anywhere. If you have any ideas how to solve this, I'd love to hear it. -- justin
