Destroy socket on unsuccessful CONNECT#46
Conversation
|
What difference between this pr and #21 ? Which solution is better in your opinion? |
|
@Hamper, good question. I think it depends on your use case. #21 adds the socket to the If the proxy in question keeps the connection with the client open in case of error - when a connection whit the upstream can't be established - then the client will be able to reuse this connection to issue a new Keeping in mind the proxy might close its side of the connection with the client when the upstream connection can't be established it seems more reasonable to me making the client explicitly close its end of the connection with the proxy in this case. |
|
I've just found this bug after three weeks debugging why our services were being brought down by AppDynamics which uses the I believe this PR is the correct solution. #21 looks buggy to me. There is no expectation that sockets making Is there any chance we could get this merged in and published? I'm not sure who the maintainer is here. Is it @mikeal perhaps? If assistance is required, I'm happy to volunteer. |
|
@insightfuls, there is already exist repo with merged all pull requests |
|
Thanks @seiya-git, however it doesn't really do any good to the ecosystem until/unless it's published to NPM so modules which consume it (such as |
When the proxy server replies with
statusCode !== 200to theCONNECTrequest the socket is left half open and sits inCLOSE_WAITstate until the process quits.This change makes sure sockets are destroyed when the proxy server is unable to establish a connection with the upstream server.
Here's a simple test to illustrate the problem:
Running from request/tunnel-agent:
Running from alltherooms/tunnel-agent: