On Thu, Jul 01, 2010 at 04:47:33PM +0200, Willy Tarreau wrote:
> However I think I have found some clue. In the trace you sent, the data
> was sent from the server along with the headers, though no intermediate
> proxy nor reverse-proxy would do that because you only know you're forwarding
> a websocket connection once you get the response. So I'll have to recheck the
> recent websocket spec updates and maybe discuss with Ian Hickson about
> possible
> issues.
Well, I got a response from Ian. In short, he says that the HTTP breakage
is intentional in order to ensure that there is no intermediate between the
client and the server, that it was a design mistake to make the protocol
look like HTTP and that you have to use another port for your WebSocket
traffic !
I'm trying to make him realize what what he says implies, but it's not
easy, as it's not the first time that the HTTP compatibility is intentionally
broken. There are people in the working group who believe they have a clue
about security and who try to ensure that the handshake is very difficult
because they believe it strengthens the protocol, which is terribly wrong.
After all, there are already other protocols making use of HTTP+something
else after an Upgrade header which work correctly simply because they
respect HTTP semantics :-/
What a waste of energy. In the end, I think that websocket adoption might
be broken into two sets :
- the ones who need a load balancer and/or a reverse proxy and who will
prefer to stick to their current protocols instead of using websocket
- the ones who need a load balancer and/or a reverse proxy and who will
hack them to support it anyway and who'll run into security issues
I don't think there will be many users without such equipments in front
of them, so the correctly working implementations will not be the most
deployed ones. That's a shame because the original goal of the protocol
*was* to put an end to current ugly hacks, and it seems it will finally
fail because there's nobody concerned about HTTP in this working group !
Thus, I don't know what to say. I could just forward you Ian's recommendation,
which is to use another port for your websocket, eventhough I find this
stupid and counter-productive. But if the protocol takes this direction,
I don't know what to do with it...
Willy
