-
Notifications
You must be signed in to change notification settings - Fork 921
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 our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: Fix maybeWebSocketUpgrade
to return true when Connection/Upgrade header has multiple…
#5958
base: main
Are you sure you want to change the base?
Conversation
|
As for the test, I tried writing it, but it seems to be written only for abstract headers like {"a": "b"}, so I was not sure where to start, so I stopped. However, if you give me a guide, I think I can write it. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi! Thanks for the PR. 😉
Would you mind adding a unit test, please?
@minwoox I wrote one, please check it 😄 |
🔍 Build Scan® (commit: b544f41)
|
It seems like the test case doesn't call |
Oops, I'll check it |
@minwoox Sorry for the confusion. I wrote toArmeria test again and checked that it calls maybeWebSocketUpgrade by debugger. |
Github checks occur some errors but I don't know how I can deal with them. (I think it may be irrelevant to my PR, I ran |
Let me see what happened. In the meantime, would you add e2e tests to see if the fix works on HTTP/1.1 and HTTP/2? |
@minwoox Can you please check my last commit? I added e2e test. |
I don't think so. 😉 |
.add(HttpHeaderNames.PROTOCOL, HttpHeaderValues.WEBSOCKET.toString()); | ||
.add(HttpHeaderNames.PROTOCOL, HttpHeaderValues.WEBSOCKET.toString()) | ||
// It works even if the header contains multiple values | ||
.add(HttpHeaderNames.CONNECTION, HttpHeaderValues.KEEP_ALIVE.toString()) | ||
.add(HttpHeaderNames.UPGRADE, "additional_value"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's revert this change. I realized that HTTP/2 uses the different method so we probably don't need to check for HTTP/2.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, @blue-hope! 👍 👍 👍
@@ -102,7 +102,9 @@ void http1Handshake(SessionProtocol sessionProtocol, boolean useThreadRescheduli | |||
.build(); | |||
final RequestHeadersBuilder headersBuilder = | |||
RequestHeaders.builder(HttpMethod.GET, "/chat") | |||
.add(HttpHeaderNames.CONNECTION, HttpHeaderValues.UPGRADE.toString()); | |||
// It works even if the header contains multiple values |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Question) When I checked, it seems like this test passes with the main branch without the changes in this PR.
I'm curious, were you able to verify the same bug with the HEAD of the main branch? It seems a little odd since ArmeriaHttpUtil#maybeWebSocketUpgrade
is only called for trailers in the server-side which doesn't seem to make sense to me.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, @jrhee17. In toArmeria
released in version 1.28.0, I found that the purgeHttp1OnlyHeaders
process was dropping useless additional headers, and that is what I intended to. I'll do it again on my server and figure out what was the issue.
return true; | ||
} | ||
return HttpHeaderNames.UPGRADE.contentEqualsIgnoreCase(header) && | ||
HttpHeaderValues.WEBSOCKET.contentEqualsIgnoreCase(value); | ||
AsciiString.containsIgnoreCase(value, HttpHeaderValues.WEBSOCKET); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think either websocketxxx
or xxxwebsocket
is a valid header value. How about splitting the value with a comma ,
before checking the equality?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we also add a test case that makes sure it doesn't pick up headers like connection: not-upgrade-lol
and upgrade: madam-websocket
?
gentle ping @blue-hope |
Motivation:
I trouble-shooted and found:
Fix that
WebSocketService
rejects headers that have multiple values #5230So I upgraded my armeria server's dependency from 1.23.1 to 1.26.0
But it still occurs even though I upgraded deps properly.
So I debugged, and found that there are one more conditional statement in
toArmeria
inArmeriaHttpUtil.java
=> I wrote this PR because It is confusing that the multivalue header accepted by
WebSocketUtil
is not accepted by the websocket conditional statement ofArmeriaHttpUtil
. If the two utils perform different roles in different scopes, and the strictness of websocket checks should be different, this PR can be closed. (But the question still remains as to whether multi-value headers should be supported.)Modifications:
WebSocketUtil.java
, change the conditional statement fromequals
tocontains
Result:
Connection: keep-alive, websocket
#5957.