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 (hybi#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
Received on 2010/09/29 22:34
This archive was generated by hypermail 2.2.0 : 2010/09/29 22:45 CEST