Chrome can't load cached responses for statics when missing CORS headers

On chrome, I’ve sometimes seen an issue where the CSS isn’t loaded. Looking at the responses for the CSS there’s no CORS headers in the response:

Age: 583098
Cache-Control: max-age=315360000, immutable
Connection: keep-alive
Date: Thu, 02 Aug 2018 10:35:25 GMT
Expires: Wed, 26 Jul 2028 16:23:50 GMT
Server: AmazonS3
Vary: Accept-Encoding
Via: 1.1 c31d49af55fff364fbd11e21a32f7fcb.cloudfront.net (CloudFront)
X-Amz-Cf-Id: 4XuBVKTsYSjZMOP4N-D6BKMykZiFEAKmN_3qmiqDoE1cmYrzb6EeEA==
x-amz-version-id: Jx_OHlhrHy8mZwyTzxdwMZaEFoaw7Rav
X-Cache: Hit from cloudfront

I also see the following in the console:

Access to CSS stylesheet at 'https://addons-amo.cdn.mozilla.net/amo-1e82033f757cb2138991a4cf400ee756.css' from origin 'https://addons.mozilla.org' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'https://addons.mozilla.org' is therefore not allowed access.

Digging into this further it appears that if a cached response has no cors headers then it will fail to load the second time if CORS headers are required.

A hard refresh fixes the issue.

I’m not sure how it gets into this state, but a way to reproduce the problem can be carried out as follows.

• Find the URL for the current CSS file loaded on addons.mozilla.org.
• Load that in a new Chrome incognito window to prevent existing caches messing things up (It’s the same origin (the CDN’s) so no CORS headers will be in the response)
• This file will then be cached
• Now request AMO from https://addons.mozilla.org (different origin need CORS to load for SRI)
• Note there’s no CSS and the CSS load was denied.

I think to fix this we’d need to add Vary: Origin.

See also this bug https://bugs.chromium.org/p/chromium/issues/detail?id=409090

[muffinresearch]

I’ve tested this out on -dev and it looks to solve the problem for chrome.

Since statics via the CDN should be returning:

Access-Control-Allow-Origin: *

I think the way the origin is being set on the request is probably OK as long as it’s only applied to static resources from the CDN.

/cc @willdurand @kumar303 @diox in-case you have other thoughts.

[kumar303]

FYI: this change triggered a couple minutes of downtime in production for some users (on multiple browsers) while the deployment of https://github.com/mozilla-services/cloudops-deployment/pull/2451 was pushed to the CDN ahead of code deployment.

This was confusing because the site looked broken; it loaded without styles.