Repository navigation
Clarifying abort behaviours #812
Description
It could be worth further clarifying the drop & abort behaviours at various stages of the lifecycle of a request and response concretely, since these are observable implementation details in HTTP.
Specifically -
- Should the destructor for a FutureIncomingResponse that has not resolved abort the request?
- A drop of a FutureIncomingResponse should probably also therefore also invalidate the outgoing body, so that any writes or finish calls shouldn't work.
- Should dropping an incoming-response or incoming-body or input-stream for a response also cause the connection to be immediately aborted?
And similarly for the server handler cases as well.
Activity
lukewagner commentedon Nov 20, 2023
For the first and third bullets, you're right, we need to document these cases and I would tentatively answer "yes" to behavior you suggest.
For the second bullet, I think that questions boils down to asking: should the
incoming-bodyreturned byincoming-response.consumebe documented to be a "child" of theincoming-response(where the general rule is: you have to drop all child resources before dropping the parent resources, or else you trap). We do this for other such nested cases (e.g., theinput-streamreturned byincoming-body.stream), so I'd expect we'd do it here, but is there a reason not to in this case @elliottt or @pchickey ?pavelsavara commentedon Mar 2, 2024
please consider browser/JCO and behavior of
fetch&AbortController, especially with streaming request/response.