Re: [slightlyoff/ServiceWorker] Never fail for navigation requests (#892)

@wanderview I think we need to look at this more closely. Looking at the handle fetch spec, it seems like a synchronous error, before calling `respondWith` will result in it returning "null" back to fetch spec.

It looks like the fetch spec doesn't handle null being returned, but it needs to, as this is what happens if no fetch events are called, or `respondWith` isn't called.

We need to figure out what we want to happen if:

* An error is thrown in the fetch listener and `respondWith` is not called (at the moment, I think the request will proceed to network)
* An error is thrown in the fetch listener and `respondWith` is called (at the moment, this depends on the value passed to `respondWith`)
* The resolved value passed to `respondWith` is not a response (at the moment, network error)
* The promise passed to `respondWith` rejects (at the moment, network error)

I think there are legitimate response to return errors/null to subresource requests. Eg, I might have a route that is only served by `caches.match`, and if there's no match I expect the image load to fail, or my `fetch()` call to reject.

"Rescuing" navigations is a bit magical, and I wouldn't expect it to happen with devtools open, but it might rescue non-developer users. Right now I can't think of cases where you'd want a navigation to fail, but there might be. This could be done per navigation, or maybe even disable fetch events for a particular service worker if it continually fails (this would be per service worker, so the next installed SW would not have fetches disabled).

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