Add ServiceWorker Static Routing API support

[sisidovski]

We propose ServiceWorker static routing API, which allows developers to configure routing, and offload things ServiceWorkers do. The main spec update is in w3c/ServiceWorker#1701, but some behavior involves the fetch spec change (specifically, "race-network-and-fetch-handler" option).

• At least two implementers are interested (and none opposed):
  • Chrome is proposing this change https://groups.google.com/a/chromium.org/g/blink-dev/c/-SEMMttEqz4
  • Mozilla Service Worker Static Routing API (positive) mozilla/standards-positions#894
• Tests are written and can be reviewed and commented upon at:
  • https://github.com/web-platform-tests/wpt/tree/master/service-workers/service-worker/tentative/static-router
• Implementation bugs are filed:
  • Chromium: crbug.com/40241479
  • Gecko: https://bugzilla.mozilla.org/show_bug.cgi?id=1855580
  • WebKit: https://bugs.webkit.org/show_bug.cgi?id=269893
• MDN issue is filed: Add docs for service worker static routing API mdn/mdn#527
• The top of this comment includes a clear commit message to use.

(See WHATWG Working Mode: Changes for more details.)

---

Preview | Diff

[domenic]

Non-editor LGTM

[annevk]

Wouldn't this return a response without any filtering getting applied? I guess the idea is that these are already filtered responses? Can that be asserted?

[annevk]

As far as I can tell https://w3c.github.io/ServiceWorker/#lookup-race-response-algorithm ends up waiting, which would delay this algorithm. Is that really the intent?

[sisidovski]

Yes, but actually this wouldn't delay the algorithm. When |raceResponse| is not null, the corresponding request is at least in-flight status. The map in "Lookup Race Response" is a map only contains in-flight requests/responses. At this point in 4.1. Main fetch, the actual fetch is not performed yet, we expect waiting for the in-flight request is faster in most cases.

[sisidovski]

Wouldn't this return a response without any filtering getting applied? I guess the idea is that these are already filtered responses? Can that be asserted?

@annevk Sorry to be the slow response. This response is the result of "fetch" in this step in the service worker spec. So these should be filtered appropriately.

[annevk]

Okay, I think that makes sense. Still have a question about the Service Worker side of things though:

If raceNetworkRequestResponse’s status is ok status, then:

How does this work for "no-cors" fetches?

cc @asutherland

[sisidovski]

So, ok status will be filtered for "no-cors" fetches?

If raceNetworkRequestResponse’s status is ok status, then:

What about updating this paragraph to refer internal response? Not sure referring the ok status in internal response is concerned for information leaks, but there're a couple of lines referring internal response in the ServiceWorker spec.

[annevk]

Yes, as per https://fetch.spec.whatwg.org/#concept-filtered-response-opaque status will be 0. It does seem very concerning this would tell you for every subresource whether it has an ok status or not. That's not information we reveal for images today, for instance.