Order of the keys for the challenge

[aprilmay]

The protocol mentions that the challenge must be computed with concatenation of the keys as "sent on the wire" (the client should shuffle the headers). The current version always takes the order Sec-WebSocket-Key1, Sec-WebSocket-Key2.

[rlotun]

Hmm, according to http://www.whatwg.org/specs/web-socket-protocol/:

 Fields in the handshake are sent by the client in a random order; the
 order is not meaningful.

Can you elaborate on what part of the spec you're referring to?

[aprilmay]

Client: page 26, point 42
Server: page 37, point 8

This was really poor design choice and useless pain to implement (web browsers do not even bother to shuffle the headers, that's why your server works with them), but quite clear in the spec imho.

Finally, this draft is depreciated (security concerns raised by ieee hybi group members) and lots of discussions are still going on. Currently no clear view yet where websockets are going.

[aprilmay]

In the twisted websocket client ( http://bitbucket.org/aprilmay/txwebsocketclient/ ), two challenges are maintained (keys shuffled of not).

See lines 388 to 404 of
https://bitbucket.org/aprilmay/txwebsocketclient/src/5193c6b8c948/websocket_client.py

[w-tbury]

I am glad I found this, as I had just started working on a WebSocket server toy project today. It is disappointing that this draft is expiring as I see WebSockets being one of the more interesting and important changes with HTML5. I hope they will keep everyone informed with the changes they plan for the future.