Re: [hybi] Shipping WebSockets

[Willy Tarreau <[e-mail]>]

On Wed, Dec 15, 2010 at 05:21:56AM -0600, Zhong Yu wrote:
> I'm leaning towards a distinct, non-HTTP approach, with some HTTP
> resemblance conservatively and carefully added to it. My proposal will
> be somewhere close to Mark's approach #2 and #3.
> 
> From a purist's stand, WS should be distinct. It should not be easily
> confused as HTTP(or other protocols) by existing or future programs.

I don't completely agree with you. We're discussing on a list whose
name means "bidirectional HTTP". And "old" draft here from Sal already
mentions WS as one of the bidirectional HTTP protocols :

   http://tools.ietf.org/html/draft-loreto-http-bidirectional-00

And this presentation does so too :

   http://www.ietf.org/proceedings/74/slides/apparea-3.pdf

So the work was really initiated by the wish to get something very
closely tied to HTTP.

> However there are strong pressures to have *some* HTTP-ness in WS.
> People want some existing HTTP components to work with WS with no(or
> little) modification. People want to keep some HTTP features in WS
> without reinventing an alien syntax.
> 
> An apparent answer to these demands is to make WS looks almost like
> HTTP, even make it 100% HTTP compliant. This answer is not only over
> reaching, but also improbable to achieve.

No, at least two mechanisms in HTTP explicitly permit this (CONNECT
for proxies and Upgrade for servers). It's just that we've found some
non-100% compliant implementations that risk to break in a bad way.
Instead of using dirty tricks to make the thing even less compliant
and having more reasons to see it randomly fail, we're trying to make
it compliant and to use tricks to ensure most of the non-compliant ones
will cleanly fail.

Protocol compliance is an important point because it gives an argument
to customers to ask their providers for fixing their products. While you
can sometimes wait several years for a feature upgrade (eg: "please, when
will you support websocket ?") it can be a lot faster when you say "hey,
your crap is subject to CVE-2011-XXXX and my users can exploit it to
corrupt its cache, hurry up to bring a fix".

Another advantage is that instead of having to check multiple docs, the
implementer only has to get back to his beloved HTTP spec and discover
that he did not correctly process the 1xx responses and that he just has
to find a way to get that fixed.

I did it in haproxy, in the past, 1xx would have been considered as 2xx
or 3xx. The fix only took a few hours, tests included. And fixing that
magically brought compatibility with the protocols transported over an
upgrade request.

That's why in my opinion protocol compliance can achieve faster deployment
and adoption than relying on a stack of invalid syntaxes that will make
some valid components break without any incentive for the editors to fix
them.

Regards,
Willy