[whatwg/fetch] Lowercasing of scheme in URL in conflict with WPT test for CORS check (Issue #1895)

TimvdLippe created an issue (whatwg/fetch#1895)

### What is the issue with the Fetch Standard?

While investigating Servo's failures for CORS checks (https://wpt.fyi/results/cors/remote-origin.htm?label=master&product=chrome%5Bexperimental%5D&product=edge%5Bexperimental%5D&product=firefox%5Bexperimental%5D&product=safari%5Bexperimental%5D&product=servo&aligned) I discovered a discrepancy between what WPT expects and how the URL standard handles schemes.

In the URL standard, it states that schemes should be lowercased: https://url.spec.whatwg.org/#scheme-state This is also how the Rust URL parser is written: https://github.com/servo/rust-url/blob/b06048d70d4cc9cf4ffb277f06cfcebd53b2141e/url/src/parser.rs#L413

However, the testcase for `HTTP://www1.web-platform.test:8000` expects the CORS check to fail, given that `HTTP` and `http` are not ascii equivalent. However, given that we parse URL schemes as lowercased, we compare `HTTP.lowercase()` to `http` and hence the CORS check passes.

Currently, all major browsers pass this test, yet the specification as written wouldn't. I am not sure if the specification can be aligned to the current expectation and I don't know the implications of removing the `lowercase` requirement for schemes.

I did search for where we initialize the origin (since I wasn't actually sure) and I unfortunately can't find that. The test in question uses `XMLHttpRequest` which uses the URL parser linked above: https://xhr.spec.whatwg.org/#dom-xmlhttprequest-open

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/issues/1895
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/fetch/issues/1895@github.com>