Clarifying abort behaviours

[guybedford]

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.

[lukewagner]

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-body returned by incoming-response.consume be documented to be a "child" of the incoming-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., the input-stream returned by incoming-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]

please consider browser/JCO and behavior of fetch & AbortController, especially with streaming request/response.