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

Ensured Netty provider uses CONNECT when proxying ws#657

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

Conversation

@jroper
Copy link
Contributor

The WS standard requires that clients use the CONNECT method when proxying WebSockets, even if they aren't using SSL. The Grizzly provider already supported this, but the Netty didn't.

I also implemented a test that tested this case.

I've made this change and PR against the 1.8.x branch, master is significantly different but briefly reading the code it looks like the bug is there as well. If you'd prefer it against master first, and then backported, or want me to submit another PR against master/1.9.x, let me know.

The WS standard requires that clients use the CONNECT method whenproxying WebSockets, even if they aren't using SSL.  The Grizzlyprovider already supported this, but the Netty didn't.I also implemented a test that tested this case.
This needed to be done both for the Grizzly and the Netty provider.Since this is essentially the same configuration parameter as theuseRelativeURIsWithSSLProxies, I reused that parameter, but I renamed itto useRelativeURIsWithConnectProxies to reflect its true meaning sinceit's no longer used just for SSL, and I deprecated the old parameter.
@jroper
Copy link
ContributorAuthor

I've attached a second commit to this pull request, it ensures that when proxying websockets using the CONNECT method, a relative path is used. This slightly changed the meaning of theuseRelativeURIsWithSSLProxies configuration parameter, so I renamed it to reflect it's new meaning,useRelativeURIsWithConnectProxies, and deprecated the old parameter.

Let me know if you'd prefer these two commits to be squashed.

@slandelle
Copy link
Contributor

@jroper Thanks! Could you squash the commits please? I'll then port on 1.9 and master.

slandelle pushed a commit that referenced this pull requestJul 30, 2014
Ensured Netty provider uses CONNECT when proxying ws
@slandelleslandelle merged commit237ba25 intoAsyncHttpClient:1.8.xJul 30, 2014
@slandelleslandelle added this to the1.8.13 milestoneJul 30, 2014
@slandelleslandelle self-assigned thisJul 30, 2014
@jroper
Copy link
ContributorAuthor

I guess you don't want me to squash the commits anymore?

@slandelle
Copy link
Contributor

Nope, thanks :) I thought you were offline at this time and I wanted to port this ASAP on the other branches.

@jroperjroper deleted the websocket-proxy-connect branchJuly 30, 2014 08:13
@slandelle
Copy link
Contributor

@jroper I guess you need me to release 1.8.13?

@jroper
Copy link
ContributorAuthor

No rush, we fixed this for a customer but that customer can use their own builds until you release it.

@muymoo
Copy link

That customer is very happy. Tested in a corporate environment and ws/wss worked for me. Thanks!

@slandelle
Copy link
Contributor

Thanks for your feedback, and thanks again to@jroper for the fix!

cs-workco pushed a commit to cs-workco/async-http-client that referenced this pull requestApr 13, 2023
* Fix HTTP2StreamChannel leak* Update code comments.
Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment

Reviewers

No reviews

Assignees

@slandelleslandelle

Projects

None yet

Milestone

1.8.13

Development

Successfully merging this pull request may close these issues.

3 participants

@jroper@slandelle@muymoo

[8]ページ先頭

©2009-2025 Movatter.jp