Re: [hybi] Proposal: HTTP upgrade process

[Vladimir Katardjiev <[e-mail]>]

On 16 aug 2010, at 03.23, Greg Wilkins wrote:

> All,
> 
> there has been a lot of posting about the -76/-00 style handshake,
> it's HTTP compliance issues, it's fast fail (or otherwise)
> characteristics, it security features etc.    I don't think any of the
> conversations have been very productive nor is there any apparent
> convergence on a solution.
> 
> [snip for length]
> Instead of contributors having to make the case of why the random
> 8-bytes etc. should be excluded from the protocol, those that support
> random bytes should clearly make the case for their inclusion.   We
> need to identify the issues with a simple upgrade request, and then
> discuss various solutions as to how to address these - it may be that
> the random 8 bytes solution is the best solution, but if so, then
> there can be no harm in conducting a process that verifies this is the
> case.

That's (relatively) easy. From Ian's omnibus WebSocket Feedback mail on April 15:

>> If the handshake messages are to contain content, then they MUST have 
>> headers to indicate the content length to be legal HTTP: in this case, a 
>> Content-Length header would be appropriate
> 
> The idea here is that the 8 random bytes are part of the post-Upgrade Web 
> Socket connection, not the GET request, so that any intermediaries will 
> fail to send the data along if they do any interpretation, thus failing 
> early. If we included them in the Content-Length then unfortunately the 
> early failure mode of intermediaries would be lost.

If memory serves, it was also used for checking if the server programmer is also capable of following instructions and generating hashes, a notion that might not be required if the working assumption is no longer that every script implements its own WebSocket stack. This would leave the main reason for those eight bytes a sort of "fail-early" test, so that a WebSocket connection will terminate before the "open" event has been fired in the browser. This is considered preferable to firing the "open" event after a successful handshake, but then losing the connection because, oops, after all it was an incompatible intermediary.

The reason it was baked into the same request package was to avoid having an additional RTT. That is, after the 101 response was received, send a WebSocket-specific frame to the server and await a reply to receive a guarantee that the connection has been successfully established and can transfer WebSocket frames.

> 
> Note that I'm not saying that we should immediately publish a -01
> draft with the handshake reverted, as I think it would be sufficient
> for us just to restart our discussions from that simpler base (but I
> would not object to a reset -01 draft either).

If it is just for these eight bytes I don't see why. As Maciej pointed out, -75 had its own share of problems, so I don't see why we should trade one for the other.

Cheers,
Vladimir