Subject: [hybi] New WebSocket handshake

From: Mykolas Juraitis <[email-masked]>
Date: Thu, 4 Mar 2010 16:28:39 +0000

Hello all,

I would like to express my opinion about new proposed WebSocket handshake
using header fields Sec-WebSocket-Key1, Sec-WebSocket-Key2 and MD5 sum of
their values (after extracting numbers, division by space count, etc.)
As far as I understand one reason of this new mechanism is to prove that
server had not just skipped handshake headers until first frame (starting
with byte 0) but parsed them and understood that this particular connection
is WebSocket connection.
First, I want to point out that forcing server to read and understand
headers does not requite introducing complex computations like MD5. For
example, header field Sec-WebSocket-Key could contain random character
sequence (for instance "xyz") and server could be required to send reversed
sequence back to client ("zyx"). That would prove that server parsed
handshake headers provided client would always send new random sequence on
each connect. Such method would be much more simple to implement and would
be less computation intensive.
Socond, I believe that forcing server to parse headers is not good idea at
all. From my own experience I know that not all applications need to
validate if connection is from "genuine" WebSocket or not. For example, if
server streams free realtime data (like stock information or news) on port
other than 80 (http) then server implementor is interested to create new
connections as fast as possible and in as easy way as possible. Goal of such
server is to distribute data not to protect if from any abuse so, if
somebody invents way to extract data from such server using XMLHttpRequest
of HTML form submit, it is not a problem but a feature because it would
allow to access new data by legacy technologies and help to distribute data
which is the original goal.
Now if server need to know that client is using "genuine" WebSocket
connection from browser, client version, identity and so on, then it is
possible to implement that as an application layer protocol. For example,
client can send special keys in the first frame of WebSocket protocol if
server expects such authentication or identification. This would allow web
developers to implement their own solution for specific problems rather than
complication WebSocket protocol and trying to make one size fits all
solution.
I believe a lot of web developers expected "raw" socket access from
WebSocket. This hope is dead now and I am not trying to resurrect it. Old
WebSocket proposal looked like reasonable compromise between "raw" socket
and some specific solution. I would suggest to keep WebSocket protocol as it
is already successfully implemented in Google Chrome. Mozilla Firefox
implementation is finally nearing to completion after 14 months of
discussions and reviewing. Introducing new handshake could delay
integration indefinitely.

Regards,
Mykolas