You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
So, these headers are sorta weird in that they have different forms depending on whether they're in a request or a response. For Sec-Websocket-Protocol specifically, this is drastically different; Sec-Websocket-Protocol in a request is a comma-separated list of values, but Sec-Websocket-Protocol in a response is one single value picked out from that list. So, that makes it tricky to add as a Header, since there aren't any existing headers that have multiple forms like that. The way I did it in writing some websocket handshake code was to just have 2 separate types, RequestSecWebsocketProtocol and ResponseSecWebsocketProtocol, which works, but is verbose and kinda clunky. I was wondering, for theoretically eventually adding these to headers, if anyone had any ideas for better ways to do this? Or if maybe just having one SecWebsocketProtocol type is good enough, maybe with strict constructors that are explicit about constructing a list vs a handshake agreement.
The text was updated successfully, but these errors were encountered:
(prior art #88)
So, these headers are sorta weird in that they have different forms depending on whether they're in a request or a response. For
Sec-Websocket-Protocol
specifically, this is drastically different;Sec-Websocket-Protocol
in a request is a comma-separated list of values, butSec-Websocket-Protocol
in a response is one single value picked out from that list. So, that makes it tricky to add as aHeader
, since there aren't any existing headers that have multiple forms like that. The way I did it in writing some websocket handshake code was to just have 2 separate types,RequestSecWebsocketProtocol
andResponseSecWebsocketProtocol
, which works, but is verbose and kinda clunky. I was wondering, for theoretically eventually adding these toheaders
, if anyone had any ideas for better ways to do this? Or if maybe just having one SecWebsocketProtocol type is good enough, maybe with strict constructors that are explicit about constructing a list vs a handshake agreement.The text was updated successfully, but these errors were encountered: