CORS preflight request and window

[yutakahirano]

https://fetch.spec.whatwg.org/#cors-preflight-fetch defines preflight as follows.

Let preflight be a new request whose method is OPTIONS, URL is request’s current URL, initiator is request’s initiator, destination is request’s destination, origin is request’s origin, referrer is request’s referrer, referrer policy is request’s referrer policy, mode is "cors", tainted origin flag is request’s tainted origin flag, and response tainting is "cors".

Note that preflight's window is not set, which means its value is "client". For usual requests the value is replaced with request's client or "no-window" in https://fetch.spec.whatwg.org/#concept-fetch but https://fetch.spec.whatwg.org/#cors-preflight-fetch calls https://fetch.spec.whatwg.org/#concept-http-network-or-cache-fetch directly and preflight's window remains "client", which is somewhat an unexpected input there.

I believe 407 should result in preflight failure, so we should set preflight's window to "no-window".

[yutakahirano]

@annevk do you have any opinions?

[annevk]

There's #1132 by @estark37 still which seems related. From that perspective it would make sense for CORS preflights not to be able to handle it I think. Though Private Network Access is reusing CORS preflights for navigations as well (exact layering TBD) at which point it probably should work?

Overall I would not expect it to be different from the request following the preflight (if successful) so perhaps this is simply a field we should make sure to copy when setting up the preflight?