Re: [whatwg/fetch] Aborting a fetch: The Next Generation (#447)

Okay, so, one thing I think is kind of muddying this design a bit, in terms of solutions that work for SW `fetch` events and `fetch()`-initiated requests:

Service workers **shouldn't** have **control** over *incoming __requests__*.

They can do whatever they want with the *response* the SW builds, of course. If the SW wishes to "abort" an incoming request, it can respond with an appropriate 5XX(?) code denoting "Request Terminated".

And of course, a SW can control requests *initiated the service worker*, using `fetch()` - that's no different from the non-SW `fetch()` use case.

But, as far as the *incoming request* goes, I think it's a sensible level of abstraction to *leave* that read-only, beyond control - the solution should be seen as something that *can* differ from `fetch()`, it *must* differ (though the solution for `fetch()` may take on a superset of the incoming-request-introspection).

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/issues/447#issuecomment-270438848