Docs: Add guarantees about http request.abort

[GeorgeBailey]

I was hoping that there would be language in the docs for http, something like "After a call to abort, no further events (error, response, data, end, etc) will be emitted on either the request or response objects."

I know that is not accurate, so please add to the docs what actually is accurate, and what actual handling I need to put in myself.

For now, I've been removing all the event listeners for error, response, data, end on both the request, and the response (if any) - adding back empty error handlers to prevent the 'unhandled exception' message.

[jasnell]

A PR has been opened for this. Closing the issue, will land the PR once it's reviewed.

[jasnell]

Fixed in b4a0ca2

[GeorgeBailey]

@jasnell, thanks for your attention on this. I see the new wording.

request.abort()

Marks the request as aborting. Calling this will cause remaining data
in the response to be dropped and the socket to be destroyed.

From this I can assume that after req.abort() is called

• No req response event is emitted
• No res data event is emitted.

But there's still some ambiguity of what can still be emitted. I've been coding for worst-case on each of these 3 questions.

• Could there still be a req error?
• Would there still be a res end? (i.e. res data was already emitted before req.abort())
• Would there ever be a res error?

Depending on the answers, application developers may be able simplify their code, otherwise such code is needed to prevent bugs in the applications.