Re: [whatwg/fetch] WIP: Cancelation (#523)

I think we should spec this by giving requests their own internal abort signal. If a signal object is provided to the request, the internal abort signal will listen to this and reflect changes. This internal signal will be the one that's posted to the service worker.

Aside from chaining to the two signals together, I don't think we should use "Add the following abort steps to the signal", and instead check the signal's flag step by step:

1. Do a small chunk of work.
1. If signal's abort flag is set, *abort somehow*.
1. Do another small chunk of work.
1. If signal's abort flag is set, *abort somehow*.
1. Another chunk of work.
1. If signal's abort flag is set, *abort somehow*.

Etc etc.

This means we can be super explicit about how abort is handled & when. However, this could lead to an overly verbose spec, so I wonder if we could do something like:

1. Let abortCheckpoint be the following steps:
    1. If signal's abort flag is not set, abort these substeps.
    1. Reject p with an "{{AbortError}}" {{DOMException}} and abort these steps.
1. Run abortCheckpoint then do a small chunk of work.
1. Run abortCheckpoint then do another small chunk of work.
1. Run abortCheckpoint then do yet another small chunk of work.

-- 
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/pull/523#issuecomment-307128896