A WebSocket server must echo exactly one offered subprotocol or the client fails the connection

The optional second argument to the WebSocket constructor becomes the Sec-WebSocket-Protocol request header. The server selects at most one of the offered values and returns it in the response header. Returning a value the client did not offer, or returning several, is a handshake failure and the browser closes the connection with no useful error. Omitting the header entirely is valid and means no subprotocol, leaving ws.protocol an empty string.

Read ws.protocol in the open handler before assuming which message format is in use, because a server that ignores the header and always speaks its newest protocol is a common source of parse errors after a deployment. Since browsers cannot set arbitrary headers on the handshake, this header is also widely abused to carry authentication tokens, which works but overloads a field intended for content negotiation.