-
Notifications
You must be signed in to change notification settings - Fork 216
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Create a tungstenite client specifying a subprotocol #145
Comments
So, as for Both things are possible to implement with the current version of 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 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 ;) |
Do you have an example on how to do this? Asking as a follow-up to #176 |
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. |
Thanks for the clarification. |
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 toconnect_with_config
but that takes a Vec or a string slice of the protocols the client supports.The text was updated successfully, but these errors were encountered: