Unlike general custom headers, which are not supported in browsers and SockJS, the Sec-WebSocket-Protocol header is
supported in every client implementation. This header allows to send a list of web socket subprotocols that the client wants to speak over the web socket. This is useful, but also sometimes necessary in some servers (see issue https://github.com/joffrey-bion/krossbow/issues/497 for more details).
Currently, though, Krossbow forbids any header in the browser and SockJS clients, even though the subprotocols list is technically supported in both.
Also, the subprotocol cannot be set via its header name in the JDK11 client implementation, it has to use a particular API, so we should treat it as a special case.
The Ktor and OkHttp clients do not have a special API for it, but it would still be worth providing protocols separately in the WebSocketClient.connect() function.
The Spring client has a special syntax sugar to set this specific header.
Unlike general custom headers, which are not supported in browsers and SockJS, the
Sec-WebSocket-Protocol
header is supported in every client implementation. This header allows to send a list of web socket subprotocols that the client wants to speak over the web socket. This is useful, but also sometimes necessary in some servers (see issue https://github.com/joffrey-bion/krossbow/issues/497 for more details).Currently, though, Krossbow forbids any header in the browser and SockJS clients, even though the subprotocols list is technically supported in both.
Also, the subprotocol cannot be set via its header name in the JDK11 client implementation, it has to use a particular API, so we should treat it as a special case.
The Ktor and OkHttp clients do not have a special API for it, but it would still be worth providing protocols separately in the
WebSocketClient.connect()
function.The Spring client has a special syntax sugar to set this specific header.