CORS problems with Amazon S3 on the latest Chomium and Google Canary

Question

Our website is having problems loading CSS and JS resources on a Amazon S3 bucket with the very latest version of Chromium (Version 33.0.1722.0 - 237596) and Chrome Canary.

Answer 1

In all likelihood, you're running into a very well-known problem with S3/CloudFront/CORS. The best solution I've been able to find is to have an app that proxies between S3 and CloudFront, always adding the appropriate CORS headers to the objects as they come back.

S3 + CloudFront are broken when it comes to serving CORS assets to different web browsers. The issue is two-fold.

• Not all browsers require CORS for web fonts and other static assets. If one of these browsers makes the request, S3 won't send the CORS headers, and CloudFront will cache the (unhelpful) response.
• CloudFront doesn't support the Vary: Origin header, so it has issues with using * for the AllowedOrigin value, and will only cache the first of multiple AllowedOrigin values.

In the end, these two issues make S3 + CloudFront an untenable solution for using CORS with a (fast) CDN solution — at least, out of the box. The bulletproof solution is to create a simple app that proxies the requests between S3 and CloudFront, always adding the requisite CORS headers so that CloudFront always caches them.

Request against a “Cold” cache

• ← Browser requests a static asset from CloudFront.
• ← CloudFront misses, and hits its origin server (a Proxy App).
• ← The Proxy App passes the request to S3.
• → S3 responds back to the Proxy App.
• → The Proxy App adds the correct CORS headers (whether S3 had sent them or not). The Proxy App responds back to CloudFront.
• → CloudFront caches the result and responds back to the browser.

Request against a “Warm” cache

• ← Browser requests a static asset from CloudFront.
• → CloudFront hits, and responds back to the browser.

Yes, this is a well-known, widespread issue:

• https://forums.aws.amazon.com/message.jspa?messageID=445325
• https://forums.aws.amazon.com/thread.jspa?messageID=404768
• https://forums.aws.amazon.com/message.jspa?messageID=346287
• https://forums.aws.amazon.com/message.jspa?messageID=278230
• https://forums.aws.amazon.com/thread.jspa?messageID=388132
• https://twitter.com/kindofwater/status/350630880651395072
• Amazon S3 CORS (Cross-Origin Resource Sharing) and Firefox cross-domain font loading
• https://coderwall.com/p/ub8zug
• http://timwhitlock.info/blog/2012/09/web-fonts-on-amazon-s3/
• http://www.yodi.sg/solve-load-font-face-cloudfront-amazon-s3-and-firefox-ie-caused-by-cors-access-control-allow-origin/
• And many more!

I can say that our S3 and CloudFront teams are well-aware of the issues discussed here. By writing up a simple app that can act as a proxy between S3 and CloudFront, you can manually inject all of the correct CORS response headers before CloudFront caches them.

If you always work in Firefox, then you likely won't notice the issue — CloudFront will always be caching your CORS-enabled responses. If you work primarily in Safari or Chrome, you'll see it much more often when you switch back to a browser which requires these headers (Firefox and IE). Also, if you have separate development/staging/production environments, you're likely to run into the multi-origin issues more often.