(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, 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.
(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-Protocolspecifically, this is drastically different;Sec-Websocket-Protocolin a request is a comma-separated list of values, butSec-Websocket-Protocolin 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,RequestSecWebsocketProtocolandResponseSecWebsocketProtocol, 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.