Cached non CORS response conflicts with new CORS request

Question

Gist:

I have a page that uses tag loading of an image from s3 (HTML img tag) and I have a page that uses xmlhttprequest. The tag loading gets cached without the CORS headers and so the xmlhttprequest sees the cached version, checks it's headers and fails with a cross origin error.

Details:

edit: Fails in both safari 5.1.6 and chrome 21.0.1180.89. Works fine in Firefox 14.

Using S3's new CORS, I setup a CORSRule as so:

<CORSRule>   <AllowedOrigin>*</AllowedOrigin>   <AllowedMethod>GET</AllowedMethod>   <AllowedMethod>HEAD</AllowedMethod>   <MaxAgeSeconds>0</MaxAgeSeconds>   <AllowedHeader>*</AllowedHeader> </CORSRule> 

If I request an image from S3 without setting the origin in the request headers I get back the image without any CORS headers in the response.

This get's cached and subsequent CORS requests (one's that do set the origin in the request header) get rejected as the browser uses the non CORS version form the cache.

What's the best way to solve this? Can I set something so the non CORS version never gets cached? Should I differentiate the CORS requests by appending a ?some_flag to the url of the request?

Ideally I'd have S3 ALWAYS send back the needed CORS headers even if the request doesn't contain "origin".

Answer 1

I ran into the same problem. As @monsur said, the problem is that S3 doesn't set teh "Vary: Origin" header, even though it should. Unfortunately, as far as I know there is no way to get S3 to send that header. However, you can work around this by adding a query string paramater to the request such as ?origin=example.com when you need CORS. The query string forces the browser not to use the cached resource.

Ideally, cloudfront and S3 would send the Vary:Origin header when CORS is enabled and/or Webkit would implicitly vary on the Origin header, which I assume Firefox does since it doesn't have this problem.