should FetchEvent.request.signal reflect abort status of outer request?

[wanderview]

Consider a service worker script that looks like:

  self.addEventListener('fetch', evt => {
    evt.respondWith(fetch(evt.request));
  });

And that the controlled page does the following:

  const controller = new AbortController();
  fetch(url, { signal: controller.signal });
  if (some_condition) {
    controller.abort();
  }

Should the fetch() initiated by the service worker script be aborted in this case? I think it would be good to do so.

I'm unsure this is what the spec says, though. It seems that in Handle Fetch we create a Request from an inner request in step 21.3.2:

https://w3c.github.io/ServiceWorker/#on-fetch-request-algorithm

The fetch spec, however, does not have an abort signal on the inner request:

https://fetch.spec.whatwg.org/#concept-request

Its only present on the exposed Request object:

https://fetch.spec.whatwg.org/#request-signal

This implies that Handle Fetch effectively strips the AbortSignal from the request when generating FetchEvent.request. Is that intentional?

[wanderview]

@jakearchibald @annevk do you have opinions here?

[annevk]

I would not mind exposing and forwarding the signal, but at that point you have a (potentially) cross-process signal bridge. It seems that would require some new language to define properly.

I definitely think we should expose a fetch being terminated in some fashion to the service worker and there are existing open issues on that (probably also filed by you). E.g., I don't think the server worker knows if fetches are getting terminated when a document is unloaded.

[wanderview]

I don't see that a cross-process signal bridge is a problem as long as we make updating the service worker exposed signal async.

The other problem I have with the signal infrastructure is that it only exposes when the signal itself is aborted, but not when the fetch is stopped/aborted for internal reasons.

[wanderview]

E.g., I don't think the server worker knows if fetches are getting terminated when a document is unloaded.

If we surfaced internal abort reasons on the exposed signal it would satisfy this case.

FWIW, the context for why I was looking at this was that I wanted to write a test showing cache.addAll() aborted outstanding requests when one failed. But it seems impossible to do so in WPT right now.

[jakearchibald]

Should the fetch() initiated by the service worker script be aborted in this case? I think it would be good to do so.

My intention was 'yes', but maybe I spec'd it wrong. Fwiw, I have tests for this, but they weren't merged. Who should I nudge about this? https://github.com/web-platform-tests/wpt/pull/7674/files

[annevk]

See also whatwg/fetch#153.

[wanderview]

We tried to make this work in firefox a few years ago, but looks like it never landed: https://bugzilla.mozilla.org/show_bug.cgi?id=1394102

[annevk]

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?

[JakobJingleheimer]

Piping in with my 2¢: it's very unexpected and undesirable for a ServiceWorker to not only be unable to abort a request but also that the AbortSignal is silently ignored / fails silently.

Is there any chance of this moving forward?

[hedgehog125]

Is there any update on this? I've been thinking of experimenting with offline video/audio streaming and it's looking like I'll need some weird workarounds at the moment. Do you think the handling for browser triggered aborts will be implemented at the same time as AbortSignals? At least in the spec?

[paralin]

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.