1526453 - CORS in Linux Broken (65.0) (works on Windows 65.0)

Status: RESOLVED INCOMPLETE

(Core :: DOM: Security, defect)

Description

[andrew]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36 Vivaldi/2.2.1388.37

Steps to reproduce:

I am a developer of web services and clients. In my production environment I have API endpoint at api.fakedomain.com and client at another.fakedomain.com. CORS is enabled on the server. In development environment I have client HTTP served from localhost:3000, API server at localhost:8080. I am making API requests using native fetch() with /url/endpoint/query?filter={"json stringified":"query"}

Actual results:

In Windows, all API requests work fine in both prod and dev with OPTIONS preflight visible on developer tools. In Linux, I have numerous requests work EXCEPT ones of the form:

Projects/Tracker?filter={"where":{"parentCode":{"inq":["VER-18-0010","TMO-18-0007","VER-18-0021","TMO-18-0069"]}}}

If I build the options object and URL from the console, and call fetch there, I get:

TypeError: NetworkError when attempting to fetch resource. [Learn More]

with the Learn More link pointing to a page on MDN about not being able to assign object properties on objects that have had Object.preventExtenions() called.

Expected results:

Like every other JSON fetch with stringified JSON in the query, this should have a preflight fired off, pass, and retrieve the data. Instead I get an error.

Comment 1

[andrew]

The user agent above is from Vivaldi, not the bug environment (Firefox 65.0 Linux)

Comment 2

[Matthias Versen [:Matti]]

There should not be a difference between linux and windows because it's the same code.

Comment 3

[andrew]

Do you have a suggestion on how I might test further? I used a UA switcher on FF under Linux to attempt to eliminate differing CORS behavior on the server. I could provide an express gist that responds to a GET on the relevant path, along with the accompanying fetch() call for Firefox.

While I agree with your assertion in principle my data is currently telling a different story.

Thanks, Matthias.

Comment 4

[Daniel Veditz [:dveditz]]

Is it any Linux machine? I don't see any obvious linux-specific use of .preventExtensions() in our code. Do you have any WebExtensions installed on the non-working one?

Comment 5

[Jonathan Kingston [:jkt] he/him]

Hey Andrew,

Would you be able to provide a simple test case for us to look at, we can't reproduce this. Are you doing something other than the URL in the fetch as normally a GET doesn't need a preflight?

I suspect the help from MDN isn't related here because this is such a generic error.

Have you also tested for the same behaviour in other browsers?

Thanks
Jonathan