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

[Willy Tarreau <[e-mail]>]

On Thu, Sep 23, 2010 at 09:53:21AM -0700, Greg Wilkins wrote:
> 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.

The only valid advantage that I've seen (explained by hixie) was to
validate the ability to talk in both directions. But with the new
framing, you proposed the ping+pong which appeared a lot better to
me because not only does it validate the ability to talk, it also
validates the ability to speak the WebSocket protocol, which is
even more important.

>  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.

The connection will not necessarily be shutdown in this case. Gateways
that don't understand "upgrade" might only see a GET, and not forward
anything from the client to the server, but only a respose from the
server to the client until the server closes. And unfortunately, the
client has no way to know if its data are delivered.

I think it is reasonable to send the ping from the client first,
provided that we add "Connection: close" in order to prevent anyone
in between from considering the added data as a possible pipelined
request. 

Another thing I really like with a ping+pong opening is that it can
easily be reused and extended for non-HTTP handshakes (even raw TCP).

>   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.

100% agree, and that's something that should clearly be stated in the doc.
I too often hear people say "my application *requires* HTTP keep-alive", so
we should be clear that anyone can break the connection without prior notice.

Regards,
Willy