Caching headers are not set correctly on some sites

[GoogleCodeExporter]

On http://law.thu.edu.tw/ we are seeing the wrong caching header, and the 
'repair' header that our module adds early is not removed.

What is the expected output? What do you see instead?

Expected:  Cache-Control:               max-age=31536000
Actual:    Cache-Control:               public, max-age=600
           X-Mod-Pagespeed-Repair   max-age=31536000

What version of the product are you using (please check X-Mod-Pagespeed
header)?

0.9.14.0-349

Please provide any additional information below, especially a URL or an
HTML file that exhibits the problem.

Note the following modules loaded into Apache on this site:

Include "/usr/local/apache/conf/mod_mono.conf"
Include "/usr/local/apache/conf/php.conf"
Include "/usr/local/apache/conf/includes/errordocument.conf"
Include "/usr/local/apache/conf/jk.conf"
Include "/usr/local/apache/conf/mod_bandwidth.conf"
Include "/usr/local/apache/conf/modsec2.conf"

Original issue reported on code.google.com by jmara...@google.com on 5 Jan 2011 at 6:09

[GoogleCodeExporter]

Specifically, this happens for the resource 
http://law.thu.edu.tw/css/logo.jpg.pagespeed.ce.qkyelvh-0e.jpg, other 
mod_pagespeed resources (such as 
http://law.thu.edu.tw/css/general.css+wforms.css+editor.css.pagespeed.cc.3TbMcNt
ELw.css) are correct.

Original comment by sligocki@google.com on 5 Jan 2011 at 6:18

[GoogleCodeExporter]

With latest trunk version. this issue still there. And it seems...

happens in all jpg file. for example:
http://law.thu.edu.tw/files/news/60x80xcache.87_193d1f4d.jpg.w60_h80.jpg.pagespe
ed.ic.KITPy9Mmhb.jpg

its header shows:

X-Mod-Pagespeed-Repair  max-age=31536000
Cache-Control   public, max-age=600

in all js file. for example:
http://law.thu.edu.tw/inc/js/sorttable.js.pagespeed.ce.b4cbdpCtFL.js


its header show only:

Cache-Control   public, max-age=600

no Repair header.

Original comment by ericker...@gmail.com on 6 Jan 2011 at 2:29

[GoogleCodeExporter]

first I disable mod_security, this issue still there. I think 
mod_security(modsec2.conf) didn't affect.

and then I disable all Dynamic Module & its config ( you'd mention above)
this issue still there.

so maybe Dynamic Module didn't affect ?

Original comment by ericker...@gmail.com on 6 Jan 2011 at 2:45

[GoogleCodeExporter]

I think I've find out what affect that.

apache's cache/disk cache make this. when I delete entire Cache section, 
everything back to normal.(you may check post_virtualhost_global.conf in 
conf.tgz) 

well, apache's cache is really weird on my site. so I decide to disable it for 
a while and see if anything goes normal.

Original comment by ericker...@gmail.com on 6 Jan 2011 at 2:58

[GoogleCodeExporter]

Thanks for investigating -- I should have updated you before you went to the 
trouble.

I have engineered an alternative approach to forcing the extended caching 
headers that should be more resilient to other poorly behaved Apache modules.

It isn't in the trunk yet -- it is done but awaiting review.

I will updated this bug as 'fixed' when it is checked in.


It is certainly interesting, though, that cache/disk_cache combined with 
mod_pagespeed causes this problem.  I was thinking it was most likely mod_php, 
mod_perl, or the bandwidth enforcer.  But in any case I think once my change is 
in, it will work properly with any of these modules.

Original comment by jmara...@google.com on 6 Jan 2011 at 3:10

[GoogleCodeExporter]

I have a candidate fix for this issue checked into the trunk:

http://code.google.com/p/modpagespeed/source/detail?r=360

If possible, please update and let me know if the caching-headers problem is 
resolved on your site.  Note that we have a binary release coming shortly and 
this will *not* be in it -- it'll have to be in the next one.

Original comment by jmara...@google.com on 6 Jan 2011 at 11:12

[GoogleCodeExporter]

I've move to latest trunk version now. It seems okay. I'll test disk cache 
later.

btw, mod_pagespeed_beacon issue still there.

Original comment by ericker...@gmail.com on 7 Jan 2011 at 3:55

[GoogleCodeExporter]

I believe this problem should be fixed in the latest source/binary release.

Original comment by jmara...@google.com on 14 Jan 2011 at 6:56

• Changed state: Fixed
• Added labels: release-note

[GoogleCodeExporter]

Was this fixed in 0.9.14.6-358? I have the same problem, some files have 
Cache-Control: max-age=31536000 and some Cache-control: public, max-age=600

Original comment by ionut.ne...@gmail.com on 17 Jan 2011 at 12:44

[GoogleCodeExporter]

Correct: this was fixed in 0.9.14.6.  Is it still a problem for you with that 
release, or are you trying to determine if an upgrade will help you?

Original comment by jmara...@google.com on 17 Jan 2011 at 1:07

[GoogleCodeExporter]

I'm not sure if it's a problem, I'm not sure if modpagespeed should also be 
able to change the cache-control of the files that it didn't modify -> 
http://www.webpagetest.org/result/110117_2C_7QZ/1/details/

Original comment by ionut.ne...@gmail.com on 17 Jan 2011 at 10:42

[GoogleCodeExporter]

Reading more on extend_cache, it says it should also "extend cache lifetimes 
for all resources that are not otherwise optimized."

I added ModPagespeedForceCaching On and it still doesn't extend the cache to 
31536000 for files that are not optimized by mod_pagespeed.

Original comment by ionut.ne...@gmail.com on 18 Jan 2011 at 1:19

[GoogleCodeExporter]

I took a look at your site in firebug and all the resources are rewritten by 
mod_pagespeed, and they all have the expected max-age setting of 1 year.

However, webpagetest uses IE, and based on the waterfall diagram you showed, 
you have some special-purpose CSS files for use with IE.  Those should be 
cache-extended too, subject to the following limitations:

1. We don't currently optimize resources loaded via Ajax or via CSS @Import 
statement.
2. We don't currently optimize any resource that is not in mod_pagespeed's own 
cache.  So if you don't have a steady stream of IE users then the IE-specific 
CSS files may fall out of our cache.  Using a repeat count with webpagetest 
would probably help.

Original comment by jmara...@google.com on 18 Jan 2011 at 2:59