Re: [hybi] I-D Action:draft-ietf-hybi-thewebsocketprotocol-01.txt

[Greg Wilkins <[e-mail]>]

On 23 September 2010 08:47, John Tamplin <[e-mail]> wrote:
> On Thu, Sep 23, 2010 at 11:36 AM, Ian Fette (イアンフェッティ)
> <[e-mail]> wrote:
>> I will try to put together a -02 by the end of the week and see how far I get, and then let's see how we can move forward.
>
> I can help with that if you need it as well.
>
>> In my mind, some of the pressing issues remaining are Issue 4 (http://trac.tools.ietf.org/wg/hybi/trac/ticket/4), and any
>> ideas anyone has (including NPN, or proposing an alternate that still meets the required properties) would be helpful.
>
> I thought a couple of people posted that the simple solution of
> requiring the WS server to not read the random bytes until it had
> written the 101 response header solved the problem of otherwise
> functional proxies causing the WS server to hang?

It may solve "the problem" of a particular intermediary, but I don't
think it justifies the existence of those random bytes on the wire as
not HTTP and not Websocket data.

The inclusion of those bytes was never discussed or justified.  There
is still no rigorous explanation of what benefit they provide that
could not be provided with an early ping/pong like:

   Client Handshake (with nonce)  --->
                  <---- Server handshake
                  <---- Ping (with hash of nonce)
   onOpen called
   Pong ------>

This give no extra round trip before the client onopen is called and
verifies that at least server->client websocket data can be sent.   If
client->server data cannot be sent, then the pong will not be received
and the connection will be shutdown.   Note that a ws connection can
fail at any time, so this provides no extra error handling burden on
applications as they have to handle this case anyway.


cheers