0

I'm using 1.6.29.7-3343 for css and images with Apache 2.2.15 (Unix) on RHEL 6. My pagespeed.conf config is here: https://gist.github.com/jhirbour/a66b0efe58c8d109b90e

As part of our PCI our compliance company says we're supposed to add the following to all served content on our site.

X-Frame-Options: DENY

I've added this to httpd.conf and it works for html/php pages.

Header always append X-Frame-Options DENY

So here's the problem mod_pagespeed seems to strip all http headers and I can't seem to find a way to add this header in (or to tell it NOT to strip it out (since apache is adding it).

Is this something I can fix with MOD_PAGESPEED_OUTPUT_FILTER ?

I DID find this: https://github.com/pagespeed/ngx_pagespeed/issues/612 which looks sort of related (at least to the internals of how mod_pagespeed might work)

2 Answers2

0

The bug report you referenced is about ngx_pagespeed, which shared a lot of code with mod_pagespeed, but probably not in this case. The interaction with the Apache header-manipulation code is specific to mod_pagespeed.

Can you be more specific about your observation? Were the headers stripped on a resource (css, image, JS) or on an HTML file?

If it was a resource, was the URL rewritten to have ".pagespeed." in the name?

Also, the version of mod_pagespeed you are using is quite old. Would you consider upgrading to at least our stable branch, which is currently on 1.8.31.5?

  • I'm not sure about upgrading right now as some components for our legacy framework we're using don't work in later versions of php. I'll look into installing and upgrade. As for more details: the headers were stripped out for CSS files. The file name was file1.css+file2.css (something similar). – Johnny Octothorpe Nov 03 '14 at 15:32
0

Short answer: this is likely fixed in 1.7 (and you are on 1.6). I don't think your PHP constraints should prevent you from upgrading mod_pagespeed. Just don't upgrade your other packages.

This is https://code.google.com/p/modpagespeed/issues/detail?id=811 which I have not marked as completely fixed, because we still have a potential issue with headers when using LoadFromFile.

Normally the way PageSpeed resources get served is that we cache the response headers from the origin, and don't run mod_headers again when we serve the cached, optimized result.

So what should we do for combined resources? Should we serve the union of all the headers on the origin resources? What if some of them have different values? I settled on putting the resources from the origin CSS files on the combined result only if they match in name and value, and this was implemented in this change:

https://code.google.com/p/modpagespeed/source/detail?r=3589

Hope this helps! -Josh