- From: Jeffrey Yasskin <jyasskin@google.com>
- Date: Thu, 24 Jul 2014 08:52:23 -0700
- To: Mike West <mkwst@google.com>
- Cc: Devdatta Akhawe <dev.akhawe@gmail.com>, Joshua Peek <josh@joshpeek.com>, Ilya Grigorik <igrigorik@google.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>, Anne van Kesteren <annevankesteren@gmail.com>, Jake Archibald <jakearchibald@google.com>, Alex Russell <slightlyoff@google.com>
On Thu, Jul 24, 2014 at 2:02 AM, Mike West <mkwst@google.com> wrote: > +Ilya for the client hint. > +Josh Peek from GitHub for the question WAY down at the bottom. > > > On Thu, Jul 24, 2014 at 4:04 AM, Devdatta Akhawe <dev.akhawe@gmail.com> > wrote: >> For request headers, how about a "CH-Context: ServiceWorker"? That makes >> more sense to me than "Service-Worker: script" and it also follows the >> client hint format. > > This seems like a reasonable way of pushing the data up to the server, and > it's probably useful for server-side response prioritization regardless: > Ilya? WDYT? I've spec'ed this suggestion at https://github.com/slightlyoff/ServiceWorker/pull/384. Feel free to tell us to spec something else, of course. >> For response, since SW shouldn't wait on CSP2.1, how about a simple header >> that someone can send to disable all SWs registered on the domain? >> "ServiceWorker: None" or something like that? > > There's no reason this would need to block on CSP v.Next if we think it's > the right thing to do. The Service Worker spec can define a new directive, > and we can merge it into CSP whenever we get around to it. That's what > Manifest is doing right now, in fact: > http://w3c.github.io/manifest/#content-security-policy > > >> Although, I do wonder: is it really that hard to ask github to let devs >> set >> content type sometimes? > > Maybe. Josh? :) It's also not just github that provides hosting by letting people put files in a directory. We'd need to at least spec another file extension to indicate "javascript-for-service-worker".
Received on Thursday, 24 July 2014 15:53:12 UTC