Hi,
Currently, mod_pagespeed <http://code.google.com/p/modpagespeed/> runs
before mod_headers by registering as:
ap_register_output_filter(
kModPagespeedFilterName, instaweb_out_filter, NULL,
static_cast<ap_filter_type>(AP_FTYPE_RESOURCE + 1));
mod_headers registers with:
ap_register_output_filter("FIXUP_HEADERS_OUT",
ap_headers_output_filter,
NULL, AP_FTYPE_CONTENT_SET);
with:
./include/util_filter.h: AP_FTYPE_RESOURCE = 10,
./include/util_filter.h: AP_FTYPE_CONTENT_SET = 20,
We've been accumulating some motivation to run *after* mod_headers, rather
than *before*. The reason is that mod_pagespeed currently has to rewrite
content without knowing the resolved content-type based on the Headers
directives in the user's configuration files. In particular, we don't
really know definitively whether browsers will treat content as XHTML or
HTML without seeing the accurate content-type. We can & do parse the
DOCTYPE if there is one, but that's not really the Source Of Truth as far
as browsers are concerned: the mimetype is.
Unfortunately, mod_deflate.c is also registered at AP_FTYPE_CONTENT_SET:
ap_register_output_filter(deflateFilterName, deflate_out_filter, NULL,
AP_FTYPE_CONTENT_SET);
mod_pagespeed really needs to run before mod_deflate. mod_pagespeed needs
HTML in the clear, and we don't want to spend CPU-cycles re-inflating what
mod_deflate just shrunk.
But I'm at a loss to understand what dictates the order between mod_headers
and mod_deflate. They are registered at the same position. Is it just
that they don't really care which position they run at? Is there anything
sane that mod_pagespeed could do to ensure this order:
1. mod_headers
2. mod_pagespeed
3. mod_deflate
Should we do something like have a tiny filter function that runs at
AP_FTYPE_RESOURCE+1 and queues mod_headers to run and then the real
mod_pagespeed filter function but *removes* mod_deflate? Then in the real
mod_pagespeed filter function we could queue up mod_deflate to get the
ordering we want?
Or is that insane &/or dangerous?
Thanks!
-Josh
