Re: [hybi] Proposal: HTTP upgrade process

[Vladimir Katardjiev <[e-mail]>]

Hm. It seems I accidentally sent out the wrong version of the mail. I didn't intend to sound as if I was arguing for the eight bytes themselves. What I thought I wrote in addition was that the intention was for the 8 bytes to be functionally part of the WS stream, so figure this:

1) HTTP Upgrade request
2) 101 response
3) 8 bytes random req
4) WS OK response

Since this would be 2 RTTs (1-2 + 3-4), in -76, 1&3 and 2&4 were baked into each-other. I don't necessarily agree with that; I'd prefer separation of concerns, but I was mainly intending to explain why those eight bytes found their way into the text in the first place.

Vladimir

On 17 aug 2010, at 11.07, Shelby Moore wrote:

> [snip]
> 
>> 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.
> 
> 
> But then forcing every proxy in the universe to be upgraded with a
> specific code path every time someone else uses HTTP Upgrade to create a
> new protocol with "early fail" hack:
> 
> http://www.ietf.org/mail-archive/web/hybi/current/msg03203.html
> 
> If not failing after WebSocket "open" event is a high priority, then
> "officially" (admittedly imperfect and flexible process) declared
> concensus was we need to find another transport option, rather than hack
> the HTTP spec.
> 
> Maybe this is off-topic for this thread is I think about "process", not
> the details of the technical debate.
> 
> [snip]