Create a tungstenite client specifying a subprotocol

[Redrield]

Currently there is no way for a WS client using tungstenite to connect to a server that requires a Sec-WebSocket-Protocol header, as the text request generated doesn't add any additional headers besides those required for a generic websocket connection by the RFC.

I'm open to implementing this, but I wanted feedback around providing a potentially higher-level API than just making people pass a Request to connect and having added the header themselves, while that is an option it may be worthwhile to provide a connect_with_protocols() function, that acts similar to connect_with_config but that takes a Vec or a string slice of the protocols the client supports.

[daniel-abramov]

So, as for Sec-WebSocket-Protocol on the client side, I think it's already possible to do so, because you can actually pass arbitrary headers to the request. On a server side it gets a bit more complicated, because the only sensible thing we could do to comply with the RFC is to basically send the same Sec-WebSocket-Protocol back, unless the user utilizes a custom callback to filter the Sec-WebSocket-Protocol.

Both things are possible to implement with the current version of tungstenite if you use a custom request on the client side and a custom callback on the server side. There is unfortunately no "automation" that tungstenite currently does, so it's strictly a user logic. This also means that we do not validate Sec-WebSocket-Protocol on the server or client, i.e. we do not verify that the format of this header is correct (as specified in RFC).

Probably the simplest thing we could do here is just to add some sanity checks on the client side when we detect that the user has passed a custom Sec-WebSocket-Protocol header and react on the response from the server accordingly by changing the corresponding place in our code

On the server side we probably do not need to change anything in that regard, since if the user expects some custom protocols, we expect that there will be some custom callback, handling these protocols. If there is no such feedback, we don't send anything back from the server, which will result in a failed handshake (as expected). Alternatively, we could just forward the protocols as is on a server side, but I'm not sure it's a good approach.

Also I think that this issue is a duplicate of #107 , so let's continue our discussion there if you don't mind ;)

[mpbraendli]

So, as for Sec-WebSocket-Protocol on the client side, I think it's already possible to do so, because you can actually pass arbitrary headers to the request.

Do you have an example on how to do this? Asking as a follow-up to #176

[daniel-abramov]

Hope I'm not too late. Sure, the connect function as well as other client functions accept an abstract type that implements a certain trait that just returns the request. You can e.g. create a custom request specifying the required headers. They will be forwarded to the server.

[mpbraendli]

Thanks for the clarification.