On Wed, Jan 5, 2011 at 10:43 AM, Ben Noordhuis <[email protected]> wrote:
> > I guess we should eliminate FIXUP_HEADERS_OUT, FIXUP_HEADERS_ERR, and
> > MOD_EXPIRES.
>
Are there any other similar header-mucking-filters I need to kill?
> Moreover, expires_insert_filter runs as APR_HOOK_MIDDLE which means it
> runs
> > after my content-generator, which means that it won't have been inserted
> by
> > the time when I want to set my caching headers.
>
> You can remove it from your handler, scan
> r->output_filters->frec->name to find the filter.
>
I'm not following you. mod_expires.c has this:
static void expires_insert_filter(request_rec *r) {
...ap_add_output_filter("MOD_EXPIRES", NULL, r, r->connection);...
}
static void register_hooks(apr_pool_t *p) {
/* mod_expires needs to run *before* the cache save filter which is
* AP_FTYPE_CONTENT_SET-1. Otherwise, our expires won't be honored.
*/
ap_register_output_filter("MOD_EXPIRES", expires_filter, NULL,
AP_FTYPE_CONTENT_SET-2);
ap_hook_insert_error_filter(expires_insert_filter, NULL, NULL,
APR_HOOK_MIDDLE);
ap_hook_insert_filter(expires_insert_filter, NULL, NULL,
APR_HOOK_MIDDLE);
}
So if I try to remove the 'expires' filter from my handler (which runs
early) then mod_expires will have a handler that runs later that inserts it
after my module has completed. Hence:
> I guess that means I have to insert a new late-running hook that kills
> > undesirable output filters. Does that wind up being simpler?
>
> The above is probably easier but whatever ends up being the most
> readable / maintainable, right?
>
And also functional :) which, evidently, my current solution is not, at
least in the presence of mod_perl and mod_php.
Your solution has the advantage of being more robust when upstream filters
write directly to the network. I just wish I didn't have to depend on my
copies of string literals from .c files I don't control. But as you said
core-filters will hopefully not change internal string constants often. I
just coded it up and it seems to work :)
-Josh
