[w3c/ServiceWorker] Can we make to avoid to invoke ServiceWorker _by default_ for if user code call `event.addRoutes(rules)` in `install` event handler? (Issue #1712)

Motivation

`event.addRoutes(rules)` was introduced by #1701 whose motivation is explained in https://github.com/WICG/service-worker-static-routing-api to reduce the overhead to intercept by ServiceWorker.

According to the motivation, I seem our ideal status resolved by this API is ServiceWorker works as _opt-in mode_ if a user code calls `event.addRoutes()`.

I think almost combinations of `RouterRule` would be nice to work like _opt-in_ semantics. However, there are some cases that are not intuitive combinations.

For example, the explainer illustrates [Bypassing ServiceWorker for particular resources](https://github.com/WICG/service-worker-static-routing-api#bypassing-serviceworker-for-particular-resources) case. This case say that ServiceWorker to behave as just as _opt-out_ for some network request path

```js
// This example is cited from the explainer.
// I think this shows opt-out behavior semantics.
// -----

// Go straight to the network and bypass invoking "fetch" handlers for URLs that start
// with '/videos/' and '/images/'.
addEventListener('install', (event) => {
  event.addRoutes([{
    condition: {
      urlPattern: new URLPattern({pathname: "/images/*"})
    },
    source: "network"
  },
  {
    condition: {
      urlPattern: new URLPattern({pathname: "/videos/*"})
    },
    source: "network"
  }]);
});
```

On the other hands,  if `RouterRule.source` is `"fetch-event”` or cache, ServiceWorker would work like as _opt-in_ for registered conditions [by the spec](https://w3c.github.io/ServiceWorker/#on-fetch-request-algorithm).

```js
// By the current spec, this indicates ServiceWorker should wake up
// and intercept for URLs with `/assets/`. I seem this shows opt-in behavior semantics.
addEventListener('install', (event) => {
  event.addRoutes([{
    condition: {
      urlPattern: new URLPattern({pathname: "/assets/*"})
    },
    source: "cache"
  },
```

If I don't misunderstand the spec, I think this API semantics inconsistency may confuse a developer. 

## Idea

I also propose a rough idea to resolve this behavior inconsistencies.

1. Introduce a new internal mode that ServiceWorker behaves like a _pass through mode_.
   1. Under this mode, ServiceWorker only works with registered conditions.
   2. For other (non-registered) conditions, ServiceWorker does not startup. 
2. Make ServiceWorker to _pass through_ mode if user calls `event.addRoutes()` once in the `install` event handler.
   1. Luckily, `event.addRoutes()` is a newly introduced API. That method does not exist on old UAs. If user code does not call  `event.addRoutes()`, ServiceWorker can work as a traditional style that intercept for all network requests implicitly.
   2. For UAs that had been shipped `event.addRoutes()` (Google Chrome), they can just ignores some patterns of conditions to keep a backword compatibility.

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

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