On Thursday 25 May 2006 06:56, Ruediger Pluem wrote: > This is because the filters (and thus the contexts of at least some > filters) get initialized in ap_invoke_filter_init which is a static > function in config.c. ap_invoke_filter_init gets only called by > ap_invoke_handler (also in config.c)
I think you've just supported my view, that the filter_init step is a Bad Thing and should be dropped. The offending code in mod_filter is a grotty - and evidently incomplete -hack to work around it. > . But if we deliver content from the > cache we do this inside the quick handler hook, which is run *before* > ap_invoke_handler. Although we call ap_run_insert_filter in the mod_cache > quick handler we do *not* initialize the filters there. Which begs the question: why are we attaching output filters to mod_cache? > 1. In mod_filter do a sanity check if the filter context has been > initialized. If not remove ourselves from the chain and simply pass the > brigade. This could be done by the following simple patch: If we have cached contents, it should presumably come from after any content-level filters, anyway. So a cautious +1, with the caveat that if anyone is using mod_filter to configure connection-level filters, it might not be the ideal fix. > Or does somebody sees a need for an error message here if the context is > not initialized? Possibly a debug message. Sod's law says someone will attach a filter to mod_cache output then need to debug why it doesn't work. > 2. Convert ap_invoke_filter_init from a static function to a public > function that is part of the API and let mod_cache call it after > ap_run_insert_filter. Which would imply filtering on cached docs. If we're going to do that, let's attach it to the normal handler, not quick_handler. -- Nick Kew
