Handle fall through requests

[jungkees]

Question:

The key thing to note is that the https://fonts.example.com Service Worker is granted a "saving throw" for matching requests. Once https://example.com's Service Worker lets the request go to the network, https://fonts.example.com finally gets the chance to handle the fetch.

What happens if https://example.com's SW does not fetch the resource but respondWith a cached (or custom) response? In this case https://fonts.example.com SW gets dispatched the event?

Or if https://fonts.example.com SW claimed its willingness to handle the fall through requests, is the fetch event dispatched to only https://fonts.example.com SW?

[mkruisselbrink]

I think what we're trying to say is that the fonts service worker in these examples will only get a fetch event when a request would have otherwise hit the network. So either the example.com SW didn't handle the fetch event for a font resource at all, or potentially even tries to fetch something from https://fonts.example.com in response to a completely unrelated event. So I imagine this would basically be an extra step after step 2 in https://fetch.spec.whatwg.org/#concept-http-fetch, where if response is null, a fetch event is send to potentially intercepting service workers like the fonts service.

[jungkees]

I spent time on it and might have understood the purpose and the expected behavior of the fallthrough requests.

Seems like we need some work with Fetch as you mentioned. I'd imagine Fetch may define fallthrough request concept (or fallthrough request flag). And for the requests made with the fetch() method in a service worker, Fetch may make it a fallthrough request (or set the fallthrough request flag) and invoke SW's Handle Fetch. Then, Handle Fetch can take care of the rest of the steps I guess.