On Wed, Sep 29, 2010 at 01:59:50PM -0500, Alan Gutierrez wrote:
> >You're probably aware that the WebSockets specification is still
> >changing a lot and that both the handshake and the framing are still
> >under active development. So unless you're developping with the goal
> >of participating to the development of the protocol, it could be a
> >waste of time to start a big development on this.
> I disagree, of course. So, if we can agree to disagree, and you will
> allow me to waste my time, I'd like to work on getting HAProxy ready for
> WebSockets.
I generally prefer when I disagree with people because that's when I
can have the most constructive exchanges ;-)
Anyway, to get back on the subject, you might then be interested in
joining the working group (h...@ietf). The rework of the handshake
is currently being discussed. It was deliberately choosen not to fix
the current bugs one at a time but rather all at once in order to
try to achieve something totally satisfying instead of something
barely satisfying that would probably not move on once fixed. If I
remember correctly, the next version of the draft should propose a
fixed handshake.
If you want to make WebSocket drafts -76 to current work through a
reverse proxy (including haproxy), you have to fix a small point in
the way the server handles the handshake since draft 76 which made it
incompatible with HTTP. The spec currently says the server should emit
all the response at once, but it will not get the client's nonce yet
("key3" in the spec) through a reverse proxy until it sends the HTTP 101
response. So you must make your server first send all the response
headers when it gets the request headers, and only then read "key3",
compute the hash and send that back. Several persons have already done
this with great success since that sequencing is HTTP compliant.
It would be nice to know what other reverse proxies currently support
the GET+Upgrade / 101+Upgrade mechanism right now. I've checked Pound
a few months ago and it did not appear to do so, though I suspect it
might be very easy to implement there too. I have no idea for nginx,
which is probably one of the components which will host it very often
given its ability to support very large amounts of concurrent connections.
Normally, reverse proxies which work with the current handshake (fixed
as above) should be compatible with the next one because the intent was
clear on that point : the handshake MUST be HTTP compliant. So it's not
a wasted time at all to try to identify the products that need to be
upgraded so that they are ready when the spec gets ratified. Probably
that someone should check with Robert and Igor for the two products
above.
> >>Questions:
> >>
> >> * Is the STunnel in Ubuntu Lucid ready to go? (Maverick?) Can it be
> >>made to work?
> >I have no idea on this point.
>
> The answer is no. I added the patch to a fork of the latest packaging.
>
> * http://github.com/bigeasy/stunnel
> * https://launchpad.net/~bigeasy/+archive/node-stack/+packages
>
> I've not tested them at the time of this writing, but the patch applied
> cleanly and the project built. I'll report back if encounter any
> problems. Until then people are free to use this package (at their own
> risk.)
OK, thanks for the feedback.
Regards,
Willy
