Re: [w3c/ServiceWorker] A way to specify a pattern of destination URLs to hit/skip SW (#1454)

Yes, this is trying to solve the problems that are same/similar to that of #1195 and #1126.

For implementation I was imagining that we'd add a hidden state variable to the service worker client (e.g. window or workers) but not to the registrations.  The state should be determined and fixed when the client is instantiated (e.g. when a navigation commits for a frame in chrome's implementation for window cases), therefore should not have a racy situation with SW registration update.  Could something like this make sense to you?

Reg: the risk of a SW accidentally caches the magic Response with the header, we can probably make a minor modification to the proposal so that on storing the response to CacheStorage the response header should be discarded / ignored?  Then the header would always only affect the current response (which might come either from the server or might be modified by the service worker on-the-fly).

Reg: the possibility to have a similar mechanism via API: I agree that it'd be reasonable to also explore a potential API surface for this kind of mechanism.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/ServiceWorker/issues/1454#issuecomment-518166861