Hello Willy, 2012/5/8 Willy Tarreau <w...@1wt.eu>:
> For such border-line uses, you need to enable "option http-no-delay". By great! that did it. > default, haproxy tries to merge as many TCP segments as possible. But in > your case, the application is abusing the HTTP protocol by expecting that Does haproxy even discard the PUSH Flag on tcp-packets? or is microsoft simply not sending it? > wrong but it's not the first time microsoft does crappy things with HTTP, > see NTLM). HTTP is such a versatile protocol, and, as already being sung by some "some of them want to be abused" :) > Please note that such protocols will generally not work across > caches or anti-virus proxies. Well. In this case, all proxies on the client side will only see https traffic; they should not be able to inspect that. > With "option http-no-delay", haproxy refrains from merging consecutive > segments and forwards data as fast as they enter. This obviously leads > to higher CPU and network usage due to the increase of small packets, > but at least it will work as expected. I'm following the mailing-list and saw that you did something different for web-sockets? [...]because haproxy switches to tunnel mode when it sees the WS handshake and it keeps the connection open for as long as there is traffic.[...] or is tunnel mode something different and keeps the inner working of assembling and merging packets in the "http-mode" I dunno if that's important but maybe one should do that for "Content-Type:application/rpc", too, but anyhow it easy to throw in the option and i'm more than happy that i can stay with my setup and have client-stickiness for dryout-purposes. And congrats to your new president :) Thx again and again Beni.
