Subsequent crossorigin request on image source cahced without CORS fails.
Reported by
tristan....@gmail.com,
May 4 2017
|
||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:54.0) Gecko/20100101 Firefox/54.0 Steps to reproduce the problem: 1. Load an Image in the document, without crossOrigin. 2. After this image has loaded, set an other Image with the crossOrigin attribute set to 'anonymous', to point to the same source. What is the expected behavior? The image should be re-downloaded with the correct CORS permissions. What went wrong? The image doesn't even load, raising an "Access to Image at [URL] [...] has been blocked by CORS policy" error. Did this work before? N/A Does this work in other browsers? Yes Chrome version: 58.0.3029.96 (Official Build) (64-bit) Channel: stable OS Version: OS X 10.9 Flash Version: Shockwave Flash 25.0 r0 When reloading the page and that the image without CORS itself uses the cached version, everything seems fine... Also, this is most probably related to bug #678265[1] though IMM, it's different enough to have it's own report. [1] https://bugs.chromium.org/p/chromium/issues/detail?id=678265
,
May 4 2017
Seems more of a CORS and caching problem than images. Images just happen to be the resource.
,
May 4 2017
,
May 5 2017
Tested the issue on Mac os 10.12.3 using chrome M58 #58.0.3029.96 and firefox browsers and observed as attached in screencast for reference. @tristan.fraipont-- Could you please check attached screencast , after loading the given html file , we observed error message as attached , and confirm us if that is the issue you are facing or provide us the expected result screenshot. Thanks!
,
May 5 2017
@hdodda-- yes that's it. If you check in chrome's console, you'll see the error message for the first image (the one without &1 in the url, which has the same url as the one displayed).
,
May 5 2017
Thank you for providing more feedback. Adding requester "hdodda@chromium.org" to the cc list and removing "Needs-Feedback" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
May 8 2017
Tested the issue on Mac os 10.12.3 , windows 7 and ubuntu 14.04 using chrome M8 #58.0.3029.96 and M60 #60.0.3091.0 and issue is reproduced. Issue is seen from M46 #46.0.2455.0 and behavior is different from M30 to M45 and is a Non-regression issue. Marking it as untraiged for further inputs on this. Thanks!
,
May 8 2017
,
May 9 2017
Hmm. This seems because: 1. The first request is sent without the Origin request header. 2. The server doesn't return the Access-Control-Allow-Origin response header. 3. The response is cached by the disk cache and the MemoryCache. 4. The second request is sent with the Origin request header. 5. The request is served by the disk cache, because the first and second requests matches except for "Origin" header, and the response doesn't contain "Vary: Origin". (The cached response in MemoryCache is not used)
,
May 9 2017
Closing as WontFix: Because the server returns different responses (i.e. with or without an Access-Control-Allow-Origin response header) depending on the Origin request header, the server should return "Vary: Origin" response header, or return "Access-Control-Allow-Origin: *" response header always, to make the response correctly cached (or not cached). Similar issues have been reported (and closed as WontFix, e.g. Issue 409090 ). |
||||||||
►
Sign in to add a comment |
||||||||
Comment 1 by kavvaru@chromium.org
, May 4 2017