Conform to protocol for identifying websockets handshake requests

[astrieanna]

From the websockets RFC:

1. An Upgrade header field containing the value "websocket",
   treated as an ASCII case-insensitive value.
2. A Connection header field that includes the token "Upgrade",
   treated as an ASCII case-insensitive value.
3. A Sec-WebSocket-Key header field with a base64-encoded (see
   Section 4 of [RFC4648]) value that, when decoded, is 16 bytes in
   length.
4. A Sec-WebSocket-Version header field, with a value of 13.

Currently, we look for an Upgrade header with the case-sensitive value "websocket".

If some but not all of the websockets properties hold, we should response with an appropriate error. Just not identifying non-complying requests as websockets handshakes should work out ok, but if it has any of the headers with "websocket" in the name or value (but does not follow all four), then I think we should response with an error at that point.

The Sec-Websocket-Key property can be determined by counting the total number of characters and the number of =-signs at the end of the value. 16 = 22 + 2=. (Meaning you don't actually have to decode it to figure out whether the length property holds.)

[astrieanna]

More details about handling things based on headers:

/version/
The |Sec-WebSocket-Version| header field in the client's
handshake includes the version of the WebSocket Protocol with
which the client is attempting to communicate. If this
version does not match a version understood by the server, the
server MUST abort the WebSocket handshake described in this
section and instead send an appropriate HTTP error code (such
as 426 Upgrade Required) and a |Sec-WebSocket-Version| header
field indicating the version(s) the server is capable of
understanding.

If they set Sec-WebSocket-Version to something other than 13,
then we send a 426 response with a Sec-WebSocket-Version header set to 13.

This versioning is clearly coupled to the websockets stuff, not the HTTP handling stuff, so the test should be implemented in the websockets.jl file. (So this issue is mostly just me taking notes on the RFC). I think this means that the HTTP handling stuff should call a predicate from the websockets file/module rather than having it's own iswebsocketshandshake function.

[astrieanna]

@danielmendel Wait, when did we add the 426 response?

[despeset]

Whoops!