Re: [whatwg/fetch] Add unsafe-no-cors mode (PR #1533)

In the documentation for the new mode, we should probably also mention that the request is made from a context that is in some way "detached" from the document/client environment settings object.

Regarding the rest of the spec, this entails at least two things:
  1. Changing how the response process algorithms are scheduled. Right now, for example, the "process response" algorithm is [called](https://fetch.spec.whatwg.org/#ref-for-fetch-params-task-destination%E2%91%A2) by [queueing a fetch task](https://fetch.spec.whatwg.org/#queue-a-fetch-task) on either a global object or a parallel queue, which seems to kind of break in the unsafe-no-cors model. We have no notion of a "browser process" in the spec, meaning callers of unsafe-no-cors requests couldn't pass in browser-process-specific scheduling primitives; I think in specs in general, we've been treating the "browser process" as if it were just a bunch of per-caller parallel queues, as we do for much of the navigation and session history infra in HTML. Given that, should we somewhere assert (and also document under the introduction of the new mode) that the associated [task destination](https://fetch.spec.whatwg.org/#fetch-params-task-destination) for unsafe-no-cors fetches _must be_ a parallel queue?
  2. Handling request's [client](https://fetch.spec.whatwg.org/#concept-request-client). As mentioned on our last VC, the spec has many assumptions around "client", especially with its interaction with other members. One specific example: a requests' `origin` defaults to the string "client", and assumes that the request's actual `client` is non-null in this case, which crashes [fetch](https://fetch.spec.whatwg.org/#concept-fetch) step 10 if you make an unsafe-no-cors fetch without manually setting request's `origin`. But that's an awkward requirement, since I think you mentioned your PR has logic that automatically ensures the `Origin` header isn't sent anyways. This is emblematic of the larger problem: Do you have a plan for handling the many uses of a request's _client_ with this "new" type of request? Should we audit them all, or take a snapshot of the Document's ESO at some point? (As Anne mentioned, request's "client" should be something like a "snapshot" anyways, although I don't know if that's explicit anywhere. Also (aside) it seems weird that a request's "window" is pretending to have access to the actual `Window` object when we're not fetching on the Document's main thread)

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/pull/1533#issuecomment-1325762475
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/fetch/pull/1533/c1325762475@github.com>