https://bz.apache.org/bugzilla/show_bug.cgi?id=48364
Dave Taylor <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected]. | |uk --- Comment #17 from Dave Taylor <[email protected]> --- Apologies for resurrecting an oldish bug, but I've hit this in Apache 2.2.27 (and from looking at the relevant bits of code in 2.2.29 I can't see anything that's changed that would fix it). >From a bit of investigation it looks like what happens is: 1. mod_cache, in its quick handler, adds an output filter CACHE_SAVE to the request. 2. action_handler() in mod_actions calls ap_internal_redirect_handler() using the path that was set up in the "Action" directive. 3. ap_internal_redirect_handler() in turn calls internal_internal_redirect() to create a new request_rec, which strips off *all* the resource-specific output filters - including CACHE_SAVE. 4. ap_internal_redirect_handler() then *doesn't* call ap_run_quick_handler() for the new request_rec, so mod_cache doesn't get a look at the new request at all. N.b. this is different to the behaviour of ap_internal_redirect(), but perhaps deliberately so? So it might be possible to resolve this by allowing ap_internal_redirect_handler() to run the quick handler against the new request_rec (but that might have unintended consequences for quick handlers in other modules than mod_cache?) Or it could perhaps be resolved by backporting CacheQuickHandler to 2.2.x so that mod_cache doesn't have to run "quick". Or I may have misunderstood what's going on entirely(!) -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
