fix: inappropriate connection reuse when using HTTP proxy if the initial CONNECT failed

[jasonjoo2010]

What This MR Resolves

A CONNECT request is needed to sent to the HTTP proxy first before the actual client request to establish the tunnel on the proxy. A HTTP/1.1 200 Connection established is expected for the initial CONNECT request. Only when the CONNECT is successful, the client continues sending the actual request through the "tunnel". And when CONNECT failed, the connection remains the initial state unconnected.

There are following circumstances that a CONNECT fails under but not limited to following situations:

• The destination is not whitelisted.
• The dest domain can't be resolved(timeout/SERVFAIL/NX/etc.).
• The dest IP can't be connected(timeout/unreachable/etc.).

There could be 2 following strategies to deal with CONNECT failures on the client side:

1. Close the connection before return to the caller.
2. Mark this connection "unconnected" and put it into the pool. Then retry the CONNECT next time it's picked out of the pool.

The 2nd one needs to add extra state to Channel in the manager which brings bigger change to the code.
This MR employs the 1st strategy to resolve it. The issue is described in #2071 .

Readings

The CONNECT is documented in Section 5.3 in RFC2871: https://www.ietf.org/rfc/rfc2817.txt

The proxy won't actively terminate the connection if the CONNECT failed if keep-alive is enabled. Unless the tunnel is established and there is any communication failures in the middle. Therefore the client needs to deal with this error by its own.

[hyperxpro]

Thanks for the PR.

Can you please add an unit test around this?

[jasonjoo2010]

Hi @hyperxpro
Added a test for this scenario, pls take a look, thanks

[hyperxpro]

Thanks a lot!

[jasonjoo2010]

Thanks for merging, this issue can be closed now #2071

May I back port this fix to 2.12.4? As 2.12.x is still commonly used