On Thu, Jul 01, 2010 at 05:15:05PM +0300, Juhani Åhman wrote: > On Thu, 2010-07-01 at 15:02 +0200, Willy Tarreau wrote: > > > Thanks for the trace, but could you please take the same one between the > > > browser and haproxy ? It's the most important one because it's the one > > > where we should see why nothing happens (maybe a "400 bad request" or > > > something like this). > > > > When I send your trace through haproxy, I see correct exchanges between > > the client and the server. The only thing that *might* be causing trouble > > is the "connection: close" header which is added. Could you please try to > > configure your instance with both following options set : > > > > option http-server-close > > option http-pretend-keepalive > > > > and without "option httpclose" ? > > Here is new trace http://a47.org/ws_packets3 with > > no option httpclose > option http-server-close > option http-pretend-keepalive > > and otherwise the same config I pasted before. > > I still can't get anything through. > > > > > In my case, I get an *exact* copy of the client's request on the server, > > as well as an exact copy of the server's response on the client, and both > > can continue to talk uninterrupted, so I don't know why it does not work > > on your side. BTW I'm on haproxy 1.4.8 too. > > I'm running Ubuntu's unstable binary > (https://launchpad.net/ubuntu/maverick/amd64/haproxy/1.4.8-1), perhaps > there's something wonky in it that's breaking it. I could try compiling > from source later on and test with that.
no there's no reason it would be broken. 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. If the server really *needs* to receive the data before the handshake is complete, then a content length must be provided, and probably that the spec mentions it, or maybe not, in which case it breaks HTTP again :-/ In the mean time, I think that the only thing you can do is to use plain TCP mode. But in TCP mode you can match HTTP traffic if required, and switch to an http backend (for the rest of the traffic). Regards, Willy
