0

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).

  1. 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.

Community
  • 1
  • 1
Will
  • 2,014
  • 2
  • 19
  • 42
  • A client request for an upgrade to a WebSocket connection can only ever be valid for HTTP 1.1. I think it's fair to say that it is a client error to request this upgrade for HTTP 1.0, since there can be no valid protocol implementation which would accept this request. – gzost Feb 13 '16 at 14:40
  • @gzost True, but -- as I realize now -- the ambiguity I perceive arises from the fact that I fail the connection as soon as I encounter the wrong HTTP version, without checking if this message is even trying to upgrade to WebSocket. Hypothetically the client might have thought (or wanted to test) that the server was a plain HTTP server -- even though I never advertise it as such nor have any HTTP resources, it does run on the HTTP(S) ports (as per RFC6455). I suppose I should parse even non-conforming messages entirely to be sure of their intent, but It's also a PITA and a waste of resources. – Will Feb 13 '16 at 23:12
  • in that case, the 505 better represents what you are doing. – gzost Feb 14 '16 at 10:50

0 Answers0