New issue
Advanced search Search tips

Issue 855713 link

Starred by 2 users

Issue metadata

Status: WontFix
Owner:
Closed: Jul 2
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug



Sign in to add a comment

CORS issue only if we don't check "disable cache" in dev tools network tab

Reported by prayaag....@gmail.com, Jun 22

Issue description

UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.87 Safari/537.36

Steps to reproduce the problem:
1. Request AWS cloudfront resource from js file. Shows CORS error. 
2. Request same resource with "Disable cache" checked in network tab. Doesn't show CORS error. 
3. Now request the same resource without "Disable cache" checked. Doesn't show CORS error. 
For more please find the attachment. 

What is the expected behavior?
CORS error should not be there. In Firefox it work fine normally. Without opening developer tools or worrying about disable cache. 
As Cloudfront response does include Access-Control-Allow-Origin:*. 
For more please find the attachment. 

What went wrong?
For more please find the attachment. 

Did this work before? N/A 

Does this work in other browsers? Yes

Chrome version: 67.0.3396.87  Channel: stable
OS Version: 10.0
Flash Version:
 
chrome_case.txt
3.8 KB View Download
chrome_case.txt
3.8 KB View Download
Just to confirm. The request attempts were not using disk cache. I tried even after deleting cache. In fact. There are thousands of images. And I have tried dozens of images which I never opened in my browser. But still, the behavior is same. Shows CORS error if "disable cache" is not selected. Shows fine if "disable cache" is selected. 
I again inspected using Fiddler. If I do same action (that request the mentioned CloudFront resource from javascript) in Firefox, it makes a normal request and received correct Access-Control-Allow-Origin = * header in the response (because request includes security header) and so the request is completed fine without any issue. 

In case of chrome when the same image is displayed on the page (not access from javascript) it doesn't include security header in request hence response doesn't have ACAO header. This response is now cached and when next request is made to the same image from javascript it fails with CORS error (If "disable cache" is unchecked). 

This clearly explains why it works with "disable cache" and not without it. 


I think there are a few similar cases in the issue tracker -
Issues  809891 ,  409090 , 741674, 741958
 Issue 809891  comment 15 has some solution, it might be applicable in your case as well (in short, leverage the Vary header).
Well, such solutions are always there. I've already made a workaround fix for us by creating Lambda Edge Function for CloudFront distribution which will always include CORS headers no matter whether browser requested them (with Origin/Security headers) or not. 

The right question is, why does chrome behave like this and other browsers not?
See https://github.com/whatwg/fetch/issues/402#issuecomment-257323396, it seems Firefox uses two different caches for <img> and XHR.
Not an expert here of course. But, I believe it is only more logical to have separate cache. I think the chrome's behavior is simply wrong ill-conceived. Uness there's an important reason why it is doing so, which I am not aware of. 
#7 - having one single cache or multiple separate caches is an implementation detail that should not affect the correctness of your code, in my opinion.
You should be ready for either one of the situations by using the Vary header with the "Origin" value, I believe, which is probably the correct thing to do anyway.

Now, I just hope that CORS headers are also cached...
Labels: Needs-Triage-M67
Components: Blink>SecurityFeature>CORS
Labels: Triaged-ET TE-NeedsTriageHelp
As this issue is out of scope of triaging at TE end, adding 'TE-NeedsTriageHelp' label and requesting someone from Blink>SecurityFeature>CORS team to look into the issue and help in further triaging.

Thanks..
Owner: yhirano@chromium.org
Status: Untriaged (was: Unconfirmed)
yhirano@: Mind triaging this?
Status: WontFix (was: Untriaged)
The spec also recommends to use Vary for complex Access-Control-Allow-Origin. https://fetch.spec.whatwg.org/#cors-protocol-and-http-caches

We don't have separate entries for various Access-Control-Allow-Origin headers because we don't think it's worth doing.

Sign in to add a comment