On Thu, Jul 30, 2015 at 10:26 AM, Anne van Kesteren <annevk@annevk.nl> wrote: > On Thu, Jul 30, 2015 at 10:01 AM, Mike West <mkwst@google.com> wrote: > > What is your understanding of what we agreed on earlier in the thread? > > That the service worker can also fetch insecure resources on its own > without them being passthrough. E.g. to populate the cache in > anticipation of such requests. That's not what I think we agreed on. If it was, the discussion around `window` and `client` would have been shorter and simpler. :) Passthrough requests seems like a reasonable loophole for folks to drive through. Preemptive requests expand the scope past a point I think we should support, given the goal of killing mixed content. It's not something I'm particularly interested in doing. On Thu, Jul 30, 2015 at 10:27 AM, Anne van Kesteren <annevk@annevk.nl> wrote: > On Thu, Jul 30, 2015 at 10:12 AM, Mike West <mkwst@google.com> wrote: > > Anne, how do you feel about adding such a property that gets set on copy? > > 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. -mike
Received on Thursday, 30 July 2015 08:39:59 UTC