Re: [w3c/ServiceWorker] Add a Service-Worker-Exclude Header (Issue #1690)

> Would the route added in the second event be ignored?

For that case, I think the second event will be ignored because the rule will be added upon addRoutes() and evaluated from the beginning.  Since a path "/.well-known/secret/*" should be covered by "/.well-known/*", the first rule is matched and executed, and the second rule won't be evaluated.

Let me go back to the original proposal on the `Service-Worker-Exclude` header.

Please correct if I understand wrong but I feel `Service-Worker-Exclude` is not oppose concept to `Service-Worker-Allowed`.  As far as I read the examples in the specification (https://w3c.github.io/ServiceWorker/#service-worker-script-response) and Chromium code (https://source.chromium.org/chromium/chromium/src/+/main:content/browser/service_worker/service_worker_new_script_loader.cc;l=303;drc=27d34700b83f381c62e3a348de2e6dfdc08364b8), it relax or restrict the `scope` option given by the `register()` on `register()`'s evaluation.  The `scope` given via the `register()` option should be used for matching during the navigation.  If we follow the concept, `Service-Worker-Exclude` should be used for restricting the `scope` option given via the `register()`, and evaluated at that time.  Therefore, I feel the name misleading.

To realize the expectations, I suppose there are three ways:
1. expand the `scope` option in the `register()` to allow it have excluded paths.
2. expand the ServiceWorker static routing API to follow subsequent subresource load (as discussed in https://github.com/WICG/service-worker-static-routing-api/issues/7)
3. new header given with the ServiceWorker main script to mention what paths should be excluded from the ServiceWorker scope. (Yoav might prefer this way upon https://github.com/w3c/ServiceWorker/issues/1690#issuecomment-2612333273)

I feel 1. is straight forward to realize the concept, but it brings scope matching more complex.
For 2., it is known that it currently needs another syntax for supporting subsequent subresource requests.  However, the area is actively evolving and may easy to add a new syntax there.
For 3., a platform provider may prefer this way, but it also adds yet another place users need to care if the ServiceWorker is not applied as expected.  Unlike Javascript APIs, finding invalid rules can be cumbersome.

I am leaning on 2., but I would like to listen to how others think on this.

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

Message ID: <w3c/ServiceWorker/issues/1690/2614959834@github.com>