So, I now have mangos supporting (with self tests!) both websocket and websocket over TLS (1.2). This is in the “websocket” branch of mangos here: https://github.com/gdamore/mangos/tree/websocket <https://github.com/gdamore/mangos/tree/websocket> As I previously indicated, this uses the Sec-Websocket-Protocol field, but it only passes the *server’s* protocol, using the format like Sec-WebSocket-Protocol: rep.sp.nanomsg.org <http://req.sp.nanomsg.org/> This means that a req socket doing a dial would send that “rep” value. This is analogous to HTTP protocol negotiation, where the server protocol is selected. In theory if the client was willing to accept multiple different protocol types, it could so indicate as an array, and wait for the server to choose just one of them. However, this is inappropriate for current SP protocols. I’m going to make the change to nanomsg to perform the same protocol handling, and I will also update the RFC for websocket. I’ll verify they are are interoperable, and assuming that they are, I will submit a PR. As far as I can tell, this approach has the least amount of controversy, greatest convenience, and frankly strictest adherence to RFC 6455 and supporting sock WebSocket APIs (particularly HTML5) well. (Admittedly I cannot think of a reason to support WebSocket *except* to support JavaScript clients running in a browser…) One small bit of sadness… the Go websocket framework does not support omitting the Origin: header, so I set it to a garbage value — “x://“ — clearly an invalid URL. I’ll probably make that settable via a nicer API, but I have to extend mangos API somewhat to improve support for setting transport options. (The current method is very unsatisfactory, and I don’t want to add more to it until I’m done with the rework of it.) Anyway, if anyone has any complaints about this approach, I’d like to hear it. I really want to wrap this up so that I can move onto other enhancements for mangos (including TCP mux support, and a bunch of other stuff that is in my queue.) - Garrett