Re: [w3c/ServiceWorker] should FetchEvent.request.signal reflect abort status of outer request? (#1544)

> It seems like this is still relevant: when I open a new tab and browse to a ServiceWorker-handled URL with a long-lived request, and then close that tab, the request.signal does not seem to be aborted in the ServiceWorker.

Another basic problem, with long-lived requests but without the need to close the tab: the SSE

> It seems from #1620 that the specification does have some integration already, albeit it a little vague. E.g., is the cancelation only forwarded if it has happened by the time we reach the step that forwards it? Why not signal it sooner if it happened sooner? It also seems that we should probably not forward anymore once `respondWith()` is fulfilled?

I'm also self-asking about another idea than to reflect the signal abortion... what about to resolve/reject (optionally with a value) on the `respondWith()`'s promise

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

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