CORS policy on cached Image

Question

In chrome 22 & safari 6.

Loading images from s3 for usage in a canvas (with extraction as a primary intent) using a CORS enabled S3 bucket, with the following code:<

Answer 1

Described behavior seems logical since cache entry key is a target URI (see 7234 Hypertext Transfer Protocol (HTTP/1.1): Caching). To fix the issue and effectively use cache you need to make image hosting server give same response in both cases.

One option is to make user agent send Origin HTTP header in first request too (given that response with key targetUri is not in a cache already):

<img src="targetUri" crossorigin="anonymous" />

Another option is to configure image hosting server to send CORS related HTTP headers regardless of whether request contains Origin HTTP header. For more information see S3 CORS, always send Vary: Origin discussion on StackOverflow.

Also you can inform user agent that responses are sensitive to Origin request HTTP header using Vary response HTTP header. The downside is that probably user agent will use Vary header only as a response validator (and not as a part of a cache entry key) and store only single response instance for a target URI which makes harder to effectively use cache. For more information check The State of Browser Caching, Revisited article by Mark Nottingham.

Answer 2

The problem is that the image is cached from a former request, without the required CORS headers.Thus, when you ask for it again, for the canvas, with the 'crossorigin' specified, the browser uses the cached version, doesn't see the necessary headers, and raises a CORS error. When you add the '?_' to the url, the browser ignores the cache, as this is another URL. Take a look at this thread: https://bugs.chromium.org/p/chromium/issues/detail?id=409090

Firefox and other browsers do no have that problem.

Answer 3

What CORS settings are you applying? This post suggests that wildcards in AllowedOrigin are parsed (rather then being sent verbatim, this appears to be undocumented behaviour); and the Access-Control-Allow-Origin header value is then cached for subsequent requests, causing issues similar to what you're reporting.