Is it possible to tweak HTTP response headers just before or after MPS takes over?

15 views
Skip to first unread message

Chris Weekly

unread,
Jul 24, 2015, 4:43:11 PM7/24/15
to mod-pagespeed-discuss
Hi,
Given CentOS5 or CentOS6, Apache 2.4, mod_pagespeed v1.9.32.4-7251 (aka stable) ...
is it possible to manipulate HTTP response headers "just in time", either to fix them up on the way "in" (eg on behalf of a webapp servlet container which apache is fronting), or to patch MPS's output on the way "out", just before the response goes down the wire. My use case relates specifically to response headers like Cache-control and Vary. In other situations SetEnvIf has been helpful in executing early enough to beat relatively early directives from other modules... but MPS (not running as a separate proxy server) seems to be somewhat "greedy" in being 1st on the way in and last on the way out. I haven't found any workarounds.

If anyone has insight here, I'd really appreciate it. I'd happily reciprocate w/ some relatively deep mod_rewrite knowledge, if that's of interest.

Thanks and Regards,
Chris W
 
 

 

Jeff Kaufman

unread,
Jul 27, 2015, 7:07:22 AM7/27/15
to mod-pagespeed-discuss

What changes would you like to make?

--
You received this message because you are subscribed to the Google Groups "mod-pagespeed-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mod-pagespeed-di...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/mod-pagespeed-discuss/2d03f43a-6e76-4371-b760-84ceb9139c09%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Chris Weekly

unread,
Jul 28, 2015, 4:44:32 PM7/28/15
to mod-pagespeed-discuss, jef...@google.com
Hi Jeff,
Thanks for your response.
I'd like the ability to set HTTP response headers coming from a webapp (which is fronted by Apache -- the same instance / process where MPS is running) just before MPS sees them, to "patch them up", so to speak.
One example would be a dynamic HTML response from the webapp which includes restrictive cache-control resp headers, eg "private", which I understand would prevent MPS from optimizing it.
I want the webapp to keep indicating intended (non)cacheability, but to allow MPS to do its work on the page.
Specific example:
webapp says "max-age=0" -> [TBD apache-based fixup changes this to max-age=300] -> MPS sees max-age=300 (which it interprets and remembers as a 5-min TTL) and optimizes the page, then sets its standard cache-related resp headers (ie max-age=0) and passes it down -> proxies -> browsers.
   
Until/unless the webapp is updated to rely on MPS to handle Cache-control responses on its behalf, I want to edit the headers (in Apache, in conf assoc w/ MPS presence) to allow MPS to do its work.
 
In a similar vein, there are some resp headers I'd like to edit just AFTER mps is done rewriting, but before the resp goes down the wire.

Other use cases include normalizing overly-broad "Vary" responses; accounting for non-standard proxies (like Akamai); etc.
I'm fluent w/ mod_rewrite, mod_headers, ap24 expr etc... but not with the deepest aspects of internal tables and other arcana.

Is it possible to do this kind of fixup?
I'm hopeful others have encountered these use cases...

Thanks in advance for any experiences / insights here!

Sincerely,
Chris 

Jeff Kaufman

unread,
Jul 31, 2015, 12:36:57 PM7/31/15
to Chris Weekly, mod-pagespeed-discuss
PageSpeed is happy to optimize uncacheable html; did you see something indicating otherwise?

In general, PageSpeed takes control of its output headers and actively tries to keep other modules from changing them because PageSpeed's output should be as open as possible and no more.  The main thing we're trying to work around are existing Apache configs that do things that are correct for the site as is but when are applied to PageSpeed output cause problems.

If you have a particular change you'd like to make, though, because PageSpeed is doing the wrong thing for your situation, could you describe more what you want?  It may be a PageSpeed bug, in which case we could fix it for everyone and not just you.
Reply all
Reply to author
Forward
0 new messages