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

> > Is this discarded as an unknown value, or does it activate the feature with no matching URLs (same as 'none')?
> 
> I'd vote for discarding but can be cool with either.

Yeah, discarding seems good.

> > Is this allowed?
> > ```
> > Service-Worker-Fetch-Scope: /imgs/, /script/
> > ```
> > 
> > 
> > …and will fire fetch events for subresources starting `/imgs/` or `/script/`, or will it treat the whole thing as one URL `/imgs/, /script/`?
> 
> Didn't mention this in the initial post as I didn't have strong opinion. (Could be open to either)

We should treat:

```
Service-Worker-Fetch-Scope: /imgs/, /script/
```

…and…

```
Service-Worker-Fetch-Scope: /imgs/
Service-Worker-Fetch-Scope: /script/
```

…the same ([due to how headers work](https://fetch.spec.whatwg.org/#concept-header-list-get)). So I guess it would fire fetch events for subresources starting `/imgs/` or `/script/`.

> > It's difficult to express "bypass the service worker for urls starting `/video/`". I guess you could support `Ignore-Fetch` and `Fetch-Scope`, but if both headers are used in the same request it could get pretty complicated.
> 
> Error out and ignore if both are given?

Maybe. Depends if we'd want to support:

```
Service-Worker-Fetch-Scope: /profile/
Service-Worker-Bypass-Scope: /profile/imgs/
```

You could say longest match wins. Not sure what happens with:

```
Service-Worker-Fetch-Scope: /profile/
Service-Worker-Bypass-Scope: /profile/
```

…though.

> > The controlled page may have been served by an earlier version of the service worker (due to `skipWaiting`), no service worker, or another registration (due to `clients.claim`). So there's no certainty around the rules the client is following.
> 
> Yep, you're right that there could be a race. My impression around skipWaiting has been that it inherently adds some race, and therefore it could be probably okay to have the race like this, but maybe not. I'm interested in learning how concerning/critical does this race look to you (and everyone)!

It's more that you're taking over a page that may have some fetch behaviour dictated by an older service worker. This is certain to happen if you use `skipWaiting`. I dunno if that means it's a race or not.

Maybe it doesn't matter because:

* If you use `skipWaiting`, you're now controlling a page that was loaded via an old service worker, so this isn't totally new.
* We already split fetch control between the service worker and page headers (eg CSP).

But I think it's much easier to understand if the fetch event handler and "when to use the fetch event" have the same lifetime.

The benefit of tying it to the client is you can give different clients different instructions. Is that useful @n8schloss?

> > If you end up with items in the cache with the `Service-Worker-Fetch-Scope` header, you might end up applying rules unintentionally.
> 
> I'm wondering if making this header always stripped away when cached could introduce more or less confusion.

It's definitely a different confusion! 😀

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