New issue
Advanced search Search tips

Issue 831147 link

Starred by 2 users

Issue metadata

Status: Duplicate
Merged: issue 825567
Owner: ----
Closed: Apr 2018
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 2
Type: Bug-Regression



Sign in to add a comment

file:// and CORS communication

Reported by engin.ay...@enda.com, Apr 10 2018

Issue description

Chrome Version       : 65.0.3325.181
OS Version: OS X 10.13.3
URLs (if applicable) :
Other browsers tested:
  Add OK or FAIL after other browsers where you have tested this issue:
     Safari:
    Firefox:
    IE/Edge:

What steps will reproduce the problem?
1. Open a web page that does a CORS request via file://
2. Try to make a communication

What is the expected result?
The communication to work given the CORS headers are proper


What happens instead of that?
It does not work.

(It broke an app that has been used for years.)


Please provide any additional information below. Attach a screenshot if
possible.
Chrome, like FF, sends "Origin: null" in the Request header.

My server implementation sends back response with header "access-control-allow-origin: null".

Chrome refuses this response and gives the following error in the console: "'Access-Control-Allow-Origin' header has a value 'null' that is not equal to the supplied origin. Origin 'null' is therefore not allowed access."

I think that means, according to Chrome null is not equal to null.

Per https://html.spec.whatwg.org/multipage/origin.html#concept-origin-opaque: "An opaque origin
An internal value, with no serialization it can be recreated from (it is serialized as "null" per serialization of an origin), for which the only meaningful operation is testing for equality."

I believe this should work.

UserAgentString: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36



 

Comment 1 by f...@opera.com, Apr 10 2018

Components: Blink>SecurityFeature>CORS
Labels: -Type-Bug -Pri-3 Pri-2 Type-Bug-Regression

Comment 2 by mek@chromium.org, Apr 10 2018

More specifically why this should work is:
https://fetch.spec.whatwg.org/#cors-check explicitly compares "request’s origin, serialized and UTF-8 encoded" with the header, rather than trying to parse an origin out of the header and comparing origins. So while generally two opaque origins aren't equal, in the specific CORS case "null" should be considered equal to all opaque origins.
As test case:
1) Please download and extract the attached file. It is a snapshot of the website: test-cors.org
2) Open test-cors.org.html file in the extracted folder in Chrome. URL should begin with file://
3) In the Server panel on the right, select Local.
4) Click Send Request.
5) Observe the console for error messages.

Then visit https://www.test-cors.org/ and repeat the above process, this time the URL is https.

You can observe the difference.
test cors.zip
74.9 KB Download

Comment 4 by f...@opera.com, Apr 10 2018

Mergedinto: 825567
Status: Duplicate (was: Unconfirmed)

Sign in to add a comment