- Notifications
You must be signed in to change notification settings - Fork1.6k
fix: inappropriate connection reuse when using HTTP proxy if the initial CONNECT failed#2072
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Merged
hyperxpro merged 1 commit intoAsyncHttpClient:mainfromjasonjoo2010:fix/http-proxy-connect-failureMar 9, 2025
Merged
fix: inappropriate connection reuse when using HTTP proxy if the initial CONNECT failed#2072
hyperxpro merged 1 commit intoAsyncHttpClient:mainfromjasonjoo2010:fix/http-proxy-connect-failureMar 9, 2025
Uh oh!
There was an error while loading.Please reload this page.
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.Learn more about bidirectional Unicode characters
Thanks for the PR. Can you please add an unit test around this? |
73adc33 to77d254cCompareHi@hyperxpro |
There is an extra CONNECT request needs to send before the real request to the HTTP proxy and the 2nd request only happens if the CONNECT request succeeds. When CONNECT failed, the connection should be dropped as it's not in connected state.Signed-off-by: Jason Joo <hblzxsj@gmail.com>
77d254c tob4859c8Comparehyperxpro approved these changesMar 9, 2025
f194152 intoAsyncHttpClient:main 3 checks passed
Uh oh!
There was an error while loading.Please reload this page.
Thanks a lot! |
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 |
Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Uh oh!
There was an error while loading.Please reload this page.
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 establishedis 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 stateunconnected.There are following circumstances that a CONNECT fails under but not limited to following situations:
There could be 2 following strategies to deal with CONNECT failures on the client side:
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.3in RFC2871:https://www.ietf.org/rfc/rfc2817.txtThe 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.