Consider forwarding errors from req if they occur after a response

[domenic]

knox, an S3 library I maintain, has run into issues a few times wherein we send a request to S3, and this request fires both 'error' and 'response' events. This confuses our users, who think that only one of those two events should occur. It also beguiles our request-to-callback translation logic, which given a request and a callback tries to call back with either the response for the success case, or the error in the error case. When both cases occur, we're in trouble.

From IRC:

isaacs> Domenic_: yeah, the socket error might happen mid-response
isaacs> Domenic_: maybe we should put the error event on the resp object, in that case? i thinkw e just only proxy to the req

It would be quite nice if requests only ever emitted one of either 'error' or 'response', instead of sometimes both. I would imagine the expected behavior, if an error happens mid-response, would be to emit the 'response' but then re-emit the 'error' on that response.

However:

isaacs> Domenic_: the tricky thing is that a lot of times, people JUST put a error handler on the req object.
isaacs> Domenic_: so now, those errors would be unhandled.
isaacs> Domenic_: and for safety, you'd have to listen on both

[jasnell]

@domenic ... any further thoughts on this one?

[domenic]

Willing to give up on this, probably way too breaking these days.