Skip to content

Fixup: Add support for Sec-WebSocket-Protocol to HTTP::WebSocketHandler#1637

Merged
spuun merged 8 commits intomainfrom
fixup-add-sec-websocket-protocol
Jan 23, 2026
Merged

Fixup: Add support for Sec-WebSocket-Protocol to HTTP::WebSocketHandler#1637
spuun merged 8 commits intomainfrom
fixup-add-sec-websocket-protocol

Conversation

@spuun
Copy link
Member

@spuun spuun commented Jan 21, 2026

WHAT is this pull request doing?

This fixes some parts that #1621 missed.

The specs added in #1621 did only verify that the websocket handler picked the right client handler based on Sec-WebSocket-Protocol. What they didn't verify was if Sec-WebSocket-Protocol was sent back to the client.

Because of how Crystal's HTTP::WebSocketHandler and HTTP::Server:Response#upgrade works I just copied HTTP::WebSocketHandler to make my own fixed version. crystal-lang/crystal#16574 would fix this in the stdlib.

HOW can this pull request be tested?

Run specs

@spuun spuun requested a review from a team as a code owner January 21, 2026 11:52
Copy link
Member

@viktorerlingsson viktorerlingsson left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

handle_sub_protocol and pick_protocol seems to behave differently here. pick_protocol returns the first match, but handle_sub_protocol overwrites on each match and keeps the last one. That could cause a mismatch, no?

@viktorerlingsson
Copy link
Member

viktorerlingsson commented Jan 22, 2026

I don't know if it matters much in this context, but we parse through the headers twice for the same info now (in handle_sub_protocol and pick_protocol (and basically duplicate the same string check). Could we get away with doing that just once and passing the information instead?

Besides that, I think it looks good!

@spuun
Copy link
Member Author

spuun commented Jan 22, 2026

I don't know if it matters much in this context, but we parse through the headers twice for the same info now (in handle_sub_protocol and pick_protocol (and basically duplicate the same string check). Could we get away with doing that just once and passing the information instead?

Besides that, I think it looks good!

Yeah, I know. I tried to keep it simple and wait for crystal-lang/crystal#16574 , but we might as well do it better and see what that PR ends up with.

Copy link
Member

@viktorerlingsson viktorerlingsson left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM! 👍

@spuun spuun merged commit 1b04701 into main Jan 23, 2026
18 checks passed
@spuun spuun deleted the fixup-add-sec-websocket-protocol branch January 23, 2026 08:40
viktorerlingsson pushed a commit that referenced this pull request Jan 28, 2026
…er (#1637)

This fixes some parts that #1621 missed.

The specs added in #1621 did only verify that the websocket handler
picked the right client handler based on `Sec-WebSocket-Protocol`. What
they didn't verify was if `Sec-WebSocket-Protocol` was sent back to the
client.

Because of how Crystal's `HTTP::WebSocketHandler` and
`HTTP::Server:Response#upgrade` works I just copied
`HTTP::WebSocketHandler` to make my own fixed version.
crystal-lang/crystal#16574 would fix this in the
stdlib.
kickster97 pushed a commit that referenced this pull request Feb 6, 2026
…er (#1637)

This fixes some parts that #1621 missed.

The specs added in #1621 did only verify that the websocket handler
picked the right client handler based on `Sec-WebSocket-Protocol`. What
they didn't verify was if `Sec-WebSocket-Protocol` was sent back to the
client.

Because of how Crystal's `HTTP::WebSocketHandler` and
`HTTP::Server:Response#upgrade` works I just copied
`HTTP::WebSocketHandler` to make my own fixed version.
crystal-lang/crystal#16574 would fix this in the
stdlib.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants