pagespeed css fetched by CDN result in cache-control:private,max-age=300

[GoogleCodeExporter]

Consider an HTML file:
  http://www.example.com/foo.html
with content
  <link rel=stylesheet type=text/css href=//example.cdn.com/foo.css />
which where foo.css content is
  .foo { background: url(/foo.jpg) }
The CDN is configured to fetch it from static.example.com.

The resulting fetch of the optimized CSS file
    http://example.cdn.com/foo.css.pagespeed.cf.HASH.css
will be served with response-header Cache-Control:private,max-age=300

This defeats one of the benefits of mod_pagespeed.


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

0.10.22.6

On what operating system?

Original issue reported on code.google.com by jmara...@google.com on 12 Sep 2012 at 8:04

• Blocking: #401, #335

[GoogleCodeExporter]

In this testcase, there is also a rewrite-mapping:
   ModPagespeedMapRewriteDomain example.cdn.com static.example.com

The source of the problem is that when the CDN does the origin-fetch of
http://static.example.com/foo.css.pagespeed.cf.HASH.css two bad things happen.
   1. The HTTP cache lookup will miss because the domain is different from
      what mod_pagespeed cached at the time it rewrote the HTML.  This is
      suboptimal.
   2. The relative image URL is resolved as http://static.example.com/foo.css.
      It optimizes that, and the resulting CSS file will have the wrong hash, because
      the original CSS file was optimized the image as http://example.cdn.com/foo.jpg.
The cache-miss (1) means mod_pagespeed has to reconstruct the rewritten 
resource from the original CSS file.  The md5-sum of the new optimized file 
will be different because the embedded image URL will have a different domain.  
Differing md5-sums cause mod_pagespeed to assume there is a content difference 
and, to avoid poisoning caches, will serve the result with cc:private/300.

The bug here as that mod_pagespeed needs to apply MapRewriteDomain to resource 
fetches.  So even though Jon did the right thing and put in the 
rewrite-mapping, mod_pagespeed ignored it.

Even when we fix this bug, though, this is likely to be a FAQ and we should 
make sure the need for this is given in our FAQ and in the rewrite_css doc.

Original comment by jmara...@google.com on 12 Sep 2012 at 8:13

[GoogleCodeExporter]

Original comment by jmara...@google.com on 12 Sep 2012 at 8:13

• Changed state: Started

[GoogleCodeExporter]

Original comment by jmara...@google.com on 12 Sep 2012 at 8:20

• Now blocking: #401

[GoogleCodeExporter]

Is this related to issue 335?

Original comment by sligocki@google.com on 12 Sep 2012 at 8:21

[GoogleCodeExporter]

Original comment by jmara...@google.com on 14 Sep 2012 at 7:25

• Now blocking: #335

[GoogleCodeExporter]

Yes I think it's related to issue 335.

Also I'll note that the full symptoms experienced by the user were not 
reproduced locally.  This may be due to some interaction with Cloudflare, but 
actually my #1 suspicion at this point is spriting.

The user had enabled spriting.  Now we are trying with spriting off and a small 
hand-patch to work around this problem, and the site seems very stable to me.

Original comment by jmara...@google.com on 14 Sep 2012 at 7:58

[GoogleCodeExporter]

This issue as stated is addressed in 
http://code.google.com/p/modpagespeed/source/detail?r=2010, however there was 
another bug affecting the site with this same symptom due to spriting.  That 
one is still open: http://code.google.com/p/modpagespeed/issues/detail?id=507

Original comment by jmara...@google.com on 28 Sep 2012 at 2:55

• Changed state: Fixed

[GoogleCodeExporter]

Original comment by jmara...@google.com on 28 Sep 2012 at 2:56

• Added labels: Milestone-v23, release-note

[GoogleCodeExporter]

Dear jmara,

Is it possible to fix this issue, without updating mod_pagespeed?

Original comment by christia...@gmail.com on 4 Mar 2014 at 2:40