New issue
Advanced search Search tips
Note: Color blocks (like █ or █) mean that a user may not be available. Tooltip shows the reason.

Issue 689575 link

Starred by 3 users
Status: Duplicate
Merged: issue 661782
Owner: ----
Closed: Feb 2017
Cc:
█ tyoshino@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux
Pri: 2
Type: Bug



Sign in to add a comment

Chrome isn't CORS-blocking a JSON request on the Twitter community meetup page like other browsers

Reported by wisniews...@gmail.com, Feb 7 2017 
UserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.87 Safari/537.36

Example URL:
https://dev.twitter.com/community/meetups

Steps to reproduce the problem:
Visit the URL in Chrome, and a map is displayed (unlike in other browsers, making this a web compatibility issue).

What is the expected behavior?
Unclear.

What went wrong?
The URL tries to load a JSON file from https://ton.twimg.com from a script loaded from https://dev.twitter.com. Chrome does not trigger a CORS check, but other browsers do, and it appears that CORS headers on the servers disallow the access.

I suspect that Chrome is in error here, but I cannot say for certain as I'm not an expert on the CORS spec.

Did this work before? N/A 

Chrome version: 55.0.2883.87  Channel: n/a
OS Version: 
Flash Version: Shockwave Flash 24.0 r0

Please see the webcompat.com comment at https://github.com/webcompat/web-bugs/issues/4243#issuecomment-277398170 for more context.

Comment 1 by mitay...@mozilla.com, Feb 7 2017

Labels: Hotlist-Interop

Comment 2 by ajha@chromium.org, Feb 8 2017

Labels: Needs-Milestone

Comment 3 by csharrison@chromium.org, Feb 8 2017

Cc: tyoshino@chromium.org
Components: -Internals>Network Blink>Loader
Hm, it seems like this is in issue with Chrome M56, but is fixed on Dev channel (M58).

Adding Blink>Loader where all the CORs experts live, but I'm inclined to WontFix. tyoshino@, can you verify?

Comment 4 by yhirano@chromium.org, Feb 9 2017

Components: Blink>Network
The original (same-origin) request has "x-request-with" header. It's redirected to another origin. With Chrome 56, the header is dropped from the redirect request somehow. That makes the redirect request simple, and the server returns 200. With ToT Chrome, the header is kept, so a preflight is made but it's rejected from the server.

Comment 5 by yhirano@chromium.org, Feb 9 2017

Mergedinto: 661782
Status: Duplicate (was: Unconfirmed)
So this is a dup of  issue 661782  fixed by https://crrev.com/75318e021b295e4285017b661f7cf9ae41efc85d .

Comment 6 by csharrison@chromium.org, Feb 9 2017 

Thanks for following up, yhirano :)
►

Sign in to add a comment