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

Okay, so as I understand it, the general use case we're trying to satisfy are the use cases discussed in https://github.com/w3c/ServiceWorker/issues/1195 and https://github.com/w3c/ServiceWorker/issues/1026 where a (mega)site is using the ServiceWorker for latency optimization.  The sites have no interest in involving the ServiceWorker if it doesn't make things faster.
  - Sometimes this means bypassing some fetches, but not all fetches.  Which is why being able to specify a prefix for which the ServiceWorker will be involved is very useful.
  - Sometimes this means disabling the ServiceWorker in its entirety until the ServiceWorker has brought its local cache up-to-date.
  - These mechanisms avoid needing to register new ServiceWorkers and skipWaiting() and claim() and all of the complexities those entail.

From an implementation perspective, there's 2 key things going on:
1. Adds a hidden state variable to the registration that is effectively either special value "all" (current behavior), a string prefix, or a special value "none".  This state variable impacts the "handle fetch" algorithm.
2. Adds a processing step to "fetch" somewhere after HTTP fetch step 5 that looks for the header "Service-Worker-Fetch-Scope" and enqueues a task to update the new registration variable for the controlling registration of a client, or if the fetch was from a ServiceWorker, to the registration to which the ServiceWorker belongs.

The 2nd part seems fairly problematic.  It adds complexity to fetch and would seem to result in a lot of potential for ordering races, plus the ability for a ServiceWorker to accidentally disable itself by caching a magic Response with the "Service-Worker-Fetch-Scope" header and serving it up.  And it's not clear that it adds much more beyond exposing an API to the ServiceWorkers to manipulate the new hidden prefix.

In particular, for the case where a ServiceWorker needs to bring itself up-to-date, it seems like the ServiceWorker should know and be able to decide when it's up-to-date.  And it also seems like the ServiceWorker would need to know it's not up-to-date in order to start updating itself.  So why not just have the server tell the SW it's out-of-date in the navigation preload response and then the ServiceWorker uses an API to manipulate the state variable at that point, and then set it back when it's updated.

It does sound reasonable to think about exposing such a mechanism via API (so the 1st half of the implementation plus API exposure instead of response headers) if we aren't able to gain traction on static routing at TPAC.

-- 
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-517441813