Re: [hybi] Proposal: HTTP upgrade process

["Shelby Moore" <[e-mail]>]

[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]