https://tools.ietf.org/html/rfc6455#section-4.4html
This section provides some guidance on supporting multiple versions
of the WebSocket Protocol in clients and servers.
Using the WebSocket version advertisement capability (the
|Sec-WebSocket-Version| header field), a client can initially request
the version of the WebSocket Protocol that it prefers (which doesn't
necessarily have to be the latest supported by the client). If the
server supports the requested version and the handshake message is
otherwise valid, the server will accept that version. If the server
doesn't support the requested version, it MUST respond with a
|Sec-WebSocket-Version| header field (or multiple
|Sec-WebSocket-Version| header fields) containing all versions it is
willing to use. At this point, if the client supports one of the
advertised versions, it can repeat the WebSocket handshake using a
new version value.
The following example demonstrates version negotiation described
above:
GET /chat HTTP/1.1
Host: server.example.com
Upgrade: websocket
Connection: Upgrade
...
Sec-WebSocket-Version: 25
Fette & Melnikov Standards Track [Page 26]
RFC 6455 The WebSocket Protocol December 2011 The response from the server might look as follows: HTTP/1.1 400 Bad Request ... Sec-WebSocket-Version: 13, 8, 7 Note that the last response from the server might also look like: HTTP/1.1 400 Bad Request ... Sec-WebSocket-Version: 13 Sec-WebSocket-Version: 8, 7 The client now repeats the handshake that conforms to version 13: GET /chat HTTP/1.1 Host: server.example.com Upgrade: websocket Connection: Upgrade ... Sec-WebSocket-Version: 13