fetch
fetch copied to clipboard
whatwg
aborting locked request body
In https://fetch.spec.whatwg.org/#abort-fetch it says:
If request’s body is not null and is readable, then cancel request’s body with error.
However, there is no check for whether the body is "locked" which means that "cancel" can throw, which doesn't seem to be taken into account here (only whether or not the stream is readable).
The problem I see here is that in:
- Add the following abort steps to requestObject’s signal: . 1. Set locallyAborted to true.
- Abort fetch with p, request, and responseObject.
- Terminate the ongoing fetch with the aborted flag set.
We abort fetch before terminating fetch. If we did this in the opposite order then terminate could release the lock so that cancelling the body doesn't throw.
For reference here is what I'm trying to do:
https://github.com/nodejs/undici/blob/0badd390ad5aa531a66aacee54da664468aa1577/lib/api/api-fetch/index.js#L151-L187
https://github.com/nodejs/undici/blob/0badd390ad5aa531a66aacee54da664468aa1577/lib/api/api-fetch/index.js#L85-L94
We lock the stream in the "incremently read" algorithm which is called from "To transmit request’s body" algorithm. My concern is whether there's a window between that and checking the stream is not locked in the Request constructor during which someone else could lock the stream. For correctness, we need to ensure that we have the stream locked the whole time once we've taken ownership of it.
"incrementally read" has a note that getting a reader will not throw an exception but if JavaScript can run between creating the Request and calling "incrementally read" then that note would be incorrect.
What is currently step 40.2 of the Request constructor addresses that concern, by creating a proxy of the stream ensuring that it is in fact locked before the constructor returns. (And yeah, code can run between it returning and transmission happening. Transmission is after "in parallel".)