- From: Anne van Kesteren <annevk@annevk.nl>
- Date: Thu, 30 Jul 2015 11:40:51 +0200
- To: Mike West <mkwst@google.com>
- Cc: Brian Smith <brian@briansmith.org>, "public-webappsec@w3.org" <public-webappsec@w3.org>, Wendy Seltzer <wseltzer@w3.org>, Dan Veditz <dveditz@mozilla.com>, Brad Hill <hillbrad@gmail.com>
On Thu, Jul 30, 2015 at 10:39 AM, Mike West <mkwst@google.com> wrote: > That's not what I think we agreed on. If it was, the discussion around > `window` and `client` would have been shorter and simpler. :) Come to think of it, it wouldn't work, since you have no reference to a window in those cases. However, it was one of the use cases people had, for podcast applications and such. >> I don't understand the suggestion. When fetch() is used in the service >> worker the context already changes. > > In the case where I'm passing a request through from a document, the > incoming Request's `context` will be something like `image`, and the Service > Worker will copy that Request object and pass it to `fetch()`, which sets a > `context` to `fetch`. Rather than examining the `window` attribute to see if > this is a kind of `fetch` we should allow or deny, we can set some > `originalContext` (or whatever) attribute on the new Request to `image`, and > check that when evaluating the outgoing request. That seems simpler than the > current language in the spec, and less likely to inadvertently change in the > future. I think the window bit is the most important aspect though, since it's what influences whether or not we can show UI. That, combined with mode being "no-cors". "originalContext" captures neither and would be confusing with suggested features such as "destination context" (see Fetch GitHub issues) and such. -- https://annevankesteren.nl/
Received on Thursday, 30 July 2015 09:41:16 UTC