Re: [hybi] #1: HTTP Compliance

[Jamie Lokier <[e-mail]>]

Vladimir Katardjiev wrote:
> I assume the problem/desire/requirement is to reduce the number of
> round-trips required for the establishment of a new connection. The
> "random bytes" are a byproduct of that -- ensure that a WebSocket
> connection's "open" event is fired when the client knows the
> connection is actually open, not just when the connection is "maybe"
> open.

I'm pretty sure the extra random bytes are only to ensure a
non-WebSocket HTTP server will abort the connection, instead of
wrongly processing WebSocket data as a HTTP request.

That's a good goal, but unfortunately it prevents retrying a different
protocol (such as HTTP-based or a different Upgrade protocol), or even
a different WebSocket subprotocol, from being tried.

It doesn't help RTTs.  If anything, the extra random bytes increase
RTTs: When negotation fails, they force the client to use a new
connection for the next attempt.

They also increase RTTs on success, by preventing the pipelining of
initial client messages.

The "open" event happens when the server's negotiation response is
received at the client.  The extra random bytes don't assist that in
any way, that I see.

(You may guess that I don't agree with the extra random bytes.)

> Maybe it'd be good to rethink how the entire thing works. So far,
> the WebSocket handshake itself has been "baked into" whatever
> previous authentication there is/has been. So... Make a proper WS
> handshake. It can be asynchronous (a la SPDY), and thus not require
> an additional RTT. Allow WS data to be sent from the API before open
> is fired, at the risk of being lost. The current API always risks
> data being lost anyway, unless some ack protocol is introduced, so
> this is OK in my view. Fire open after the WS handshake
> finishes. There's no speed loss for expert programmers who desire
> the extra ms boost, while the contract of an established WS
> connection is preserved for amateurs.

All good ideas, imho :-)

Using a "proper WS" handshake was proposed recently by Greg.  Sending
things asynchronously during negotation was proposed by me; and
therefore also allowing send before the API's open completes.

Maybe we need an issue tracker of some kind to focus these ideas! :-)

-- Jamie