According to the WebSocket RFC (RFC6455#section-4.2.1):
If the server, while reading the handshake, finds that the client did not send a handshake that matches the description below [...], the server MUST stop processing the client's handshake and return an HTTP response with an appropriate error code (such as 400 Bad Request).
- An HTTP/1.1 or higher GET request, including a "Request-URI" [RFC2616] that should be interpreted as a /resource name/ defined in Section 3 (or an absolute HTTP/HTTPS URI containing the /resource name/).
[etc...]
When the client's handshake message instead specifies HTTP/1.0 (or perhaps an even lower version number?), I'm not sure if responding with HTTP/1.1 400 \r\n\r\n is appropriate given its definition (RFC7231#section-6.5.1):
The 400 (Bad Request) status code indicates that the server cannot or will not process the request due to something that is perceived to be a client error (e.g., malformed request syntax, invalid request message framing, or deceptive request routing).
I suppose that whether or not the HTTP version number being too low is to be considered a client error depends on how to interpret a client handshake message:
Either...
- A client handshake message is a plain HTTP1.1 message (which can cause a future upgrade to WebSocket if it includes a certain set of HTTP headers).
...or...
- A client handshake message is actually not an HTTP1.1 message but actually a message that is part of the WebSocket standard and which merely masquerades as an HTTP1.1 message.
If the latter, a status code of 400 makes sense, because the client is in clear violation of the WebSocket standard.
If the former, a status code of 400 doesn't make sense, because the message is valid as an HTTP message; and a status code of 505 might be preferable: (RFC7231#section-6.6.6)
The 505 (HTTP Version Not Supported) status code indicates that the server does not support, or refuses to support, the major version of HTTP that was used in the request message. The server is indicating that it is unable or unwilling to complete the request using the same major version as the client, as described in Section 2.6 of [RFC7230], other than with this error message. The server SHOULD generate a representation for the 505 response that describes why that version is not supported and what other protocols are supported by that server.
Then again, I don't like the idea of returning a 5XX class status code, because it more or less suggests that the server is at fault for throwing the error...
EDIT: As I mention in a comment below, most of the ambiguity probably arises from the fact that I don't check whether the client even meant to upgrade to WebSocket at all.