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

We often hear a demand for specifying certain set of destination URLs to be intercepted by SW (e.g. #1026, #1373), and this is yet another (lightweight) proposal to address a subset of these using HTTP response headers (therefore it's ephemeral & scoped only to the current navigation). 

**Proposal: Service-Worker-Fetch-Scope header**
* Allows website to return `Service-Worker-Fetch-Scope: <url-scope>` HTTP response header to main resource requests, so that they can express what URLs should be hit by their SW for the service worker client that is instantiated by the main resource. `<url-scope>` can be either “none” or a scope URL.
* When this is specified, the `service-workers` mode of all subresource fetch requests from the service worker client that do NOT prefix-match the given scope 
 is set to `”none”`, i.e. this makes only the subresource requests that match the scope hit the Service Worker.

**Examples:**
* Example 1: A site returns `Service-Worker-Fetch-Scope: ‘/sw_cache/’` to document requests so that only the subresources whose URL start with `/sw_cache/` are intercepted by the SW.
* Example 2: A site starts to return `Service-Worker-Fetch-Scope: “none”` after a certain period so that it can skip SW after that. (This could be _slightly_ more efficient than scripting this in SWs as UA can skip routing requests entirely, esp. if UA can see it in NavPreload response before/during starting a SW)

Alternative can be a header that works opposite, e.g. `Service-Worker-Ignore-Fetch` or something, while I've heard some sentimenet that allowlisting urls could be handier.

Technically this can be a subset of Declarative Routing proposal (#1373) and can potentially be subsumed by the proposal if we decide to implement it.  Motivation of this proposal is to see if we can have a smaller, incremental iteration that can be easier to experiment with.

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

Received on Wednesday, 31 July 2019 02:36:10 UTC