Amazon S3 CORS implementation primes cache to reject cross-origin requests |
|||||||
Issue descriptionA web developer friend just reached out to me about what they thought was a Chrome bug, but turns out to (maybe) be an issue with a number of CORS implementations, including S3, which other web devs have run into since CORS was launched. Here's some discussion: - Issue 409090 — opened in 2014, last comment eight hours ago! - https://forums.aws.amazon.com/thread.jspa?threadID=112772 - https://stackoverflow.com/questions/44800431/ - https://stackoverflow.com/questions/31732533/ S3 (and, it sounds like, some common CORS libraries) only adds CORS headers to a response when the request includes an Origin header. If a resource is loaded first without CORS (e.g. in an `img` tag), and later with CORS, the second request hits the cache and gets rejected. Poking through the spec, it looks like S3 should either be sending CORS headers all the time, or send a `Vary: Origin` header when CORS is enabled for a resource. I think it would be great if we could: 1. Come up with a recommendation for how servers should handle CORS headers. 2. Reply to the crbug, and at least one of the Stack Overflow questions, with our recommendation. 3. Ask Amazon to fix S3.
,
Jul 13 2017
Either of the solutions you listed should work. We've been suggesting these solutions for similar questions. If you want to allow multiple origins to use the resource but not everyone (i.e. not by the wildcard), you need to use the Vary header. Otherwise, you can respond to no-cors requests with the wildcard or the single origin you want to accept which the fetch algorithm just ignores for the no-cors requests but will be investigated for future CORS-enabled ones.
,
Jul 13 2017
OK, that's reassuring. Is there anyone at Amazon we could talk to about making their products work like this? A lot of people seem to run into this problem with S3, and I think they offer CORS-specific settings but not a way to set arbitrary response headers.
,
Jul 13 2017
If you don't mind dropping `Restrict-View-Google`, I'd be happy to forward this bug to folks I know at Amazon.
,
Jul 13 2017
Sure thing.
,
Jul 13 2017
,
Jul 14 2017
I'm the friend. Firefox does not fire a cache hit in this case. Since the spec doesn't say if CORS headers are only returned if the Origin header is returned (S3's implementation) I think it is ambiguous what is the correct caching behavior. My guess is Firefox includes the Origin header in its cache key, while Chrome does not. I think a clarification in the spec might be helpful as well. This was a frustrating one to figure out. My fix here was to add crossorigin to the 'img' tag which seems suboptimal.
,
Jul 14 2017
"If the Origin header is sent" is my intended language.
,
Jul 14 2017
Firefox's behavior is interesting. I found a WONTFIX issue on their bug tracker similar to our issue 409090 : https://bugzilla.mozilla.org/show_bug.cgi?id=696430
,
Jul 25 2017
Firefox keys the cache on the credentials mode. I think that's how they avoid the issue.
,
Jul 25 2017
FYI, the section about use of the Vary header has been improved recently by Mike Smith. https://fetch.spec.whatwg.org/#cors-protocol-and-http-caches
,
Nov 10 2017
,
Feb 18 2018
,
Feb 26 2018
Reassigning to mkwst@
,
Apr 19 2018
This also came up in https://bugs.chromium.org/p/chromium/issues/detail?id=809891, which had some communications from reporters to their support.
,
Sep 28
|
|||||||
►
Sign in to add a comment |
|||||||
Comment 1 by sdy@chromium.org
, Jul 13 2017