[hybi] Revised WebSocket Feedback

[Vladimir Katardjiev <[e-mail]>]

Heya,
 
So, after some implementation work it's time to channel some responses.

First, a copy/paste error. Page 31 seems to be missing Sec-WebSocket-Key2.

Same page, you probably meant | instead of " in 
	
	(such as |Cookie")

Also, this might be just my reading comprehension, but the following paragraph caused a double-take

	if a server assumes that its clients are authorized
      on the basis that they can connect [...] then the server
      should also verify that the client's handshake includes the
      invariant "Upgrade" and "Connection" parts of the handshake, and
      should send the server's handshake before changing any user data.

Checking Upgrade and Connection is redundant if Sec-WebSocket-* are present from a browser PoV;that was the point of them, no? Furthermore, it is not evident that by /sending/ a reply you're preventing cross-protocol attacks. I guess you meant by reading the client's handshake (which just happens to be a part of the "sending reply" section).

Right, time to graduate from reading comprehension into actual questions. The big addition obviously Sec-WebSocket-Key1/2. Are there any fundamental limitations on where spaces can and should occur in the header? According to my interpretation as it stands, the following string is a perfectly valid key: "    4abcd". Is this intended? And, if so, can the leading (or trailing, if so inclined) spaces cause issues when parsing by proxies/existing stacks?

Also, I must've missed the big discussion, but what's the rationale of having two key headers. One I can buy, but since it should already be impossible to create a Sec-* header from a browser, AND it is impossible to add spaces to the header value, AND it is a GET with a body, it's already triple impossible (impossibler? impossiblest?) for XHR/CORS to forge. If someone has a handy link to where this suggestion was born it'd be appreciated, because this seems like quite a bit of computation involved.

The junk characters in the handshake also seem redundant. If you already need to verify the correct number of spaces this means you are checking for spaces already. As for the garbage characters, all they made me do was replace("[^0-9]", '') instead of replace(' ', '') so I'd say they didn't alter the functionality of my code other than take up more CPU cycles.

The closing handshake is also interesting. Maybe state in 5.3. that the server shouldn't disconnect on 0xFF (instead of may; it still may, but is discouraged from doing so since it may cause data loss. If the target audience really is the kind of programmer you need to verify their code by actually ensuring they read the spaces, then make the default level of the protocol ensure data integrity, because that's what they'll see in the lab network).

Finally, and probably my smallest serious gripe, but what's up with the mix of references to ASCII and UTF-8 as characters. It is all technically correct, to nobody's surprise, but it's distracting to read. I hope it's just a transitional thing and it'll eventually be UTF-8 throughout but it was just too boring to do it all at once.

Cheers,
Vladimir

PS, some notes that border on the psychopathic crazy programmer in a dark dungeon mindset. These can be safely ignored.

Page 20:  EXAMPLE: For example

Acknowledgement: OK!

Page 22: -> If the byte is 0x3A (ASCII :)

The internet has damaged me so badly this was a smiley face.