New issue
Advanced search Search tips
Starred by 2 users

Issue metadata

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

Sign in to add a comment

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

Reported by, Jun 22 2018

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:
3.8 KB View Download
3.8 KB View Download

Comment 1 by, Jun 22 2018

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.

Comment 2 by, Jun 23 2018

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.

Comment 4 by, Jun 23 2018

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).

Comment 5 by, Jun 24 2018

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?

Comment 6 by, Jun 24 2018

See, it seems Firefox uses two different caches for <img> and XHR.

Comment 7 by, Jun 24 2018

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.

Comment 8 by, Jun 24 2018

#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...

Comment 9 by, Jun 24 2018

Labels: Needs-Triage-M67

Comment 10 by, Jun 25 2018

Components: Blink>SecurityFeature>CORS

Comment 11 by, Jun 25 2018

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.


Comment 12 by, Jul 2 2018

Status: Untriaged (was: Unconfirmed)
yhirano@: Mind triaging this?

Comment 13 by, Jul 2 2018

Status: WontFix (was: Untriaged)
The spec also recommends to use Vary for complex Access-Control-Allow-Origin.

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