x/net/websocket: messages not exposed in package API

[gopherbot]

by lorresylvan@yahoo.com:

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.

[ianlancetaylor]

Comment 1:

Labels changed: added repo-net, release-none.

[gopherbot]

Comment 2 by albert.jin:

Why has this still not been accepted? The new Chrome 38 with its WebSocket
implementation that does actually send multiple-frame messages. The max frame size is
possibly 131072 bytes.

[gdamore]

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.

[cespare]

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:

https://godoc.org/github.com/gorilla/websocket

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.

[nhooyr]

Related issue: #18152

Another alternative library now is: https://github.com/nhooyr/websocket