What is Sec-WebSocket-Key for?

Question

In section 1.3 \"Opening Handshake\" of draft-ietf-hybi-thewebsocketprotocol-17, it describes Sec-WebSocket-Key as follows:

To prove that the

Answer 1

I'm inclined to agree.

Nothing of importance would change if the client ignored the value of the Sec-WebSocket-Accept header.

Why? Because the server is not proving anything by doing this calculation (other than that it has the code to do the calculation). Just about the only thing it rules out is a server that simply replies with a canned response.

The exchange of headers (e.g. with fixed 'key' and 'accept' values) is already sufficient to rule out any accidental connection with something that is not at least trying to be a WebSocket server; and if it's trying, the requirement that it do this calculation is hardly an impediment to its succeeding.

The RFC claims:

".. the server has to prove to the client that it received the client's WebSocket handshake, so that the server doesn't accept connections that are not WebSocket connections."

and:

"This helps ensure that the server does not accept connections from non-WebSocket clients .."

Neither of these claims make any sense. The server is never the one rejecting the connection because it is the one computing the hash, not the one checking it.

This sort of exchange would make some sense if the magic GUID were not fixed, but were instead a shared secret between client and server. In that case the exchange would allow the server to prove to the client that it had the shared secret without revealing it.