On Tue, May 08, 2012 at 06:14:15PM +0200, Benedikt Fraunhofer wrote: > > For such border-line uses, you need to enable "option http-no-delay". By > > great! that did it.
Fine, thanks for your feedback. > Does haproxy even discard the PUSH Flag on tcp-packets? or is > microsoft simply not sending it? It cannot know if there was a PUSH since only the kernel knows it. Haproxy does not receive packets but data. However the "http-no-delay" option ensures that a PUSH is emitted on output segments so that none of them waits anywhere. > > 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" :) :-) Anyway not respecting standards is what causes trouble in real life. > > 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. Some of them will still be able to do it, many proxies do inspect HTTPS right now by spoofing certificates. And on the server side, you cannot easily offload SSL to a proxy or install a load balancer (you needed one with a specific option to keep the latency low). > 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.[...] exactly. > or is tunnel mode something different and keeps the inner working of > assembling and merging packets in the "http-mode" Haproxy switches to a tunnel mode when it sees a CONNECT request succeed or a 101 response to an Upgrade request. When in tunnel mode, it basically falls back to TCP mode and forwards data as fast as possible between both sides without inspecting anything. > 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. No, I really don't want to change the TCP behaviour based on a content-type. It's not normal at all, the lower layers have no reason to adapt to contents. It's somewhat a violation of the layering model that we must not perform at all. Regards, Willy
