- From: Anne van Kesteren <notifications@github.com>
- Date: Sun, 05 Jul 2015 03:55:29 -0700
- To: whatwg/fetch <fetch@noreply.github.com>
- Message-ID: <whatwg/fetch/issues/70/118611728@github.com>
Currently request has an associated client. It's null for client requests, which seems broken. Within Fetch client is used for: * Queuing tasks in the correct event loop. * Adding fetches to the correct fetch registry. * Inheriting HTTPS state. * Determining the request does not come from a service worker. (Not all APIs set the "skip service worker flag", e.g. `fetch()` doesn't. We could change this, but see the next point for why it might not matter.) Outside of Fetch it is used by CSP and Referrer. For these we want that the policy used is that associated with the service worker, which means client and dialog window need to be distinct things. (If @sleevi, @mikewest, and @jeisinger could confirm, that'd be great.) I think this means that aside from client, a request also needs a concept of "dialog window". For `fetch()` we could base it on the client of the `Request` object passed in (works for documents and service workers; for others workers that would fail nicely since the passed in request's client could never be a document client). And then we would allow overriding it to null. We could also allow overriding it to a different client, but perhaps we should not do that for v1, might get a tad complicated. Although some if that is complicated already due to `<iframe>` and `window.open()` and passing `Request` objects around. I guess we should carefully consider where the "dialog window" comes from in that case. That's the last thing that warrants some more thought. --- Reply to this email directly or view it on GitHub: https://github.com/whatwg/fetch/issues/70#issuecomment-118611728
Received on Sunday, 5 July 2015 10:55:56 UTC