Re: [hybi] Proposed way forward for WebSockets

[Willy Tarreau <[e-mail]>]

On Tue, Jul 27, 2010 at 02:40:40AM -0400, John Tamplin wrote:
> On Tue, Jul 27, 2010 at 2:13 AM, Anne van Kesteren <[e-mail]> wrote:
> 
> > On Tue, 27 Jul 2010 06:56:27 +0200, Greg Wilkins <[e-mail]>
> > wrote:
> >
> >> I would add 4: to support  the deployment of future extended versions of
> >> the protocol.
> >>
> >> Thus having a mechanism for versions and feature negotiation is key in a
> >> 1.0
> >>
> >
> > Feature negotiation is there, by means of new headers.
> 
> 
> If that is the intention, it would be good to state that in the protocol,
> especially since an earlier version specifically outlawed additional headers
> and there is confusion over the interpretation of the current version's
> stance on additional headers.

Yes indeed, that should be clarified. And BTW, saying "Upgrade: WebSocket/1.0"
would be *a lot* better than "Upgrade: WebSocket". And BTW, all Upgrade examples
in RFC2616 suggest such a version, so there is nothing unusual in doing that.
It's also what will a server know what it should consider in a handshake.

> > Breaking backwards compatibility so that you need to support two or more
> > versions forever seems like a bad idea.
> 
> 
> The alternative is simply breaking old implementations if there is no
> versioning and you find you need to make incompatible changes.  Including
> versioning now is small insurance against such a requirement.

Right, it costs nothing right now to advertise the version and to define how
each end should react to an unknown version.

> I think it is worth considering keep-alives for the initial version -- the
> alternative, if implemented at the application level, is a mess of
> incompatible implementations that can't be pooled or limited by the browser
> (such as on a phone that needs to curtail network activity to conserve
> battery) without interfering with legitimate traffic, since the browser
> can't identify it.

Indeed, and many protocols relying on long-lived sessions provide a ping
function because this is the only way to test the whole chain. Having it
available does not mean browsers will have to implement it, it just means
that when such a ping request is seen, a ping response must be emitted,
which is not something terribly difficult to implement.

Regards,
Willy