search

eidheim / Simple-WebSocket-Server

A very simple, fast, multithreaded, platform independent WebSocket (WS) and WebSocket Secure (WSS) server and client library implemented using C++11, Boost.Asio and OpenSSL. Created to be an easy way to make WebSocket endpoints in C++.
MIT License
800 stars 278 forks source link

Support for the Sec-WebSocket-Protocol field #86

Closed MatrixManAtYrService closed 7 years ago

MatrixManAtYrService commented 7 years ago

RFC 6455 specifies a field to be included in the connection request and used to indicate which user-defined protocol should be used on the socket.

I am trying to create a websocket connection to a server that (I think) requires that field. I have created a gist with more detail here:

https://gist.github.com/MatrixManAtYrService/fba771f56ef130deef535a6e7dd4717a

I plan to modify WsClient to add support for this field, but I was hoping you could look over my gist and let me know if the modification I have proposed is:

Thanks!

eidheim commented 7 years ago

Thank you for the excellent writeup. If I follow you correctly, it seems that Sec-Websocket-Protocol is missing in the client handshake (and probably in the server handshake response as well). But this field is optional (see https://tools.ietf.org/html/rfc6455#section-4.2.1), and handshakes should work without it. If not, it might be an error in the server's implementation.

I'm open to making changes here, though, I am not entirely sure of the advantages of the subprotocols that can be listed in Sec-Websocket-Protocol.

eidheim commented 7 years ago

Also, you can play around with the client handshake here: https://github.com/eidheim/Simple-WebSocket-Server/blob/master/client_ws.hpp#L366

MatrixManAtYrService commented 7 years ago

According to the team that knows the device I'm connecting to, the handshake does work without it. It's just that when data comes through the socket, it isn't properly categorized on the other end (the desired callback never gets called).

It seems to me that differentiating protocols based on the connection URL (like SWSS does) is pretty much equivalent to differentiating based on the Sec-Websocket-Protocol field, our problem is that we have two parties, each using the other method.

If I end up adding the ability to use Sec-Websocket-Protocol, I'll put it in a pull request so you can decide if you want to integrate it. If we end up fixing it on the server side I'll comment back here in case somebody else runs across this. Either way, it's not your bug, so I'll go ahead and close this.

Also, I just wanted to say that I think you're great--definitely one of my favorite people on github. If all the software that we pay for was as high quality and well supported as the software that you make available for free, we'd be much better off. Thank you.