Re: [whatwg/fetch] Add abort reason to abort fetch (PR #1343)

I think that's about right! I didn't realize the fetch controller was shared with the handle fetch algorithm; indeed, with that fact, it becomes clearly the right coordination point.

Minor comment:

> In [handle fetch](https://w3c.github.io/ServiceWorker/#on-fetch-request-algorithm), create an AbortController, and when we create the Request object, associate it with that AbortController's signal

Right now in handle fetch, when we create a Request object in step 24.3.2, we never set its signal. But later in 24.3.19, we treat the signal as if it exists. So that's bad. Probably we should update 24.3.2 to use https://fetch.spec.whatwg.org/#request-create so that an AbortSignal is properly created.

Also, in spec land, we don't need to create an AbortController. We can just mess with the signals directly. So just that update should suffice.

So in summary, I think the changes look like this:

- Change "abort fetch" to accept an error (like this patch)
- Change "abort" for fetch controllers to accept an error (like this patch)
- In the "Add the following abort steps", grab signal's reason, serialize it, and store it on the controller. (Similar to this patch's steps 4, 14, and 15, but nested under step 12 instead. Also if serializing throws an exception, probably we should censor to "AbortError" DOMException instead of rejecting p.)
- Rename this patch's "cloned error" to "serialized abort reason" for clarity, and change its type to "null or a serialization from StructuredSerialize".
- Update Service Worker spec:
  - Change 24.3.2 to use "create a Request"
  - Change 24.3.19 to deserialize and use controller's serialized abort reason if it is non-null and deserializing doesn't throw; otherwise a "AbortError" DOMException.

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

Message ID: <whatwg/fetch/pull/1343/c1212843202@github.com>

Received on Friday, 12 August 2022 08:06:34 UTC