Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

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

Conversation

@jasonjoo2010
Copy link
Contributor

@jasonjoo2010jasonjoo2010 commentedMar 9, 2025
edited
Loading

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. AHTTP/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 stateunconnected.

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 inSection 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
Copy link
Member

Thanks for the PR.

Can you please add an unit test around this?

@jasonjoo2010jasonjoo2010force-pushed thefix/http-proxy-connect-failure branch from73adc33 to77d254cCompareMarch 9, 2025 16:38
@jasonjoo2010
Copy link
ContributorAuthor

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

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>
@jasonjoo2010jasonjoo2010force-pushed thefix/http-proxy-connect-failure branch from77d254c tob4859c8CompareMarch 9, 2025 17:22
@hyperxprohyperxpro merged commitf194152 intoAsyncHttpClient:mainMar 9, 2025
3 checks passed
@hyperxpro
Copy link
Member

Thanks a lot!

@jasonjoo2010
Copy link
ContributorAuthor

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

Reviewers

@hyperxprohyperxprohyperxpro approved these changes

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

2 participants

@jasonjoo2010@hyperxpro

[8]ページ先頭

©2009-2025 Movatter.jp