WebSocket peers exchange messages. A message is composed of one or more frames. The (*Conn).Read and (Codec).Receive methods return a single frame. There is no mechanism to detect message boundaries or otherwise compose frames into a message. To use this package, an application must provide its own framing or assume that the peer sends single frame messages. My guess is that most applications assume that the peer sends single frame messages because that's what browsers and the websocket package do. This assumption is not true of all peers.
This is fairly fatal. RFC 6455 is fairly specific that implementations must NOT be sensitive to frame boundaries, as proxies are permitted to break content up into separate frames if they so desire. I've no great love of WebSocket in general, but this failing means that the golang x/net implementation is worthless to me.
This is the main reason why github.com/gorilla/websocket is what most folks recommend for websockets, not the x/net implementation. Even the x/net/websocket docs say at the top:
This package currently lacks some features found in an alternative and more actively maintained WebSocket package:
There have been various discussions over the years about fixing the x/net API or bringing gorilla/websocket into x/net or something else, but they never really panned out.
Related issue: #18152
Another alternative library now is: https://github.com/nhooyr/websocket
Most helpful comment
This is the main reason why github.com/gorilla/websocket is what most folks recommend for websockets, not the x/net implementation. Even the x/net/websocket docs say at the top:
There have been various discussions over the years about fixing the x/net API or bringing gorilla/websocket into x/net or something else, but they never really panned out.