About to issue 1.4.16, anything pending ?

Hi,

a few minor issues were reported since 1.4.15 so I'm planning to issue 1.4.16 with the fixes. I just wanted to ensure that no patch was missing before the release, so if you have anything pending that's not there or that I might have lost/forgotten, please email me. Similarly, if you are working on something you'd like to get merged and want a few days delay, please tell me so, there's no emergency as we just have very minor fixes.

The first issue concerns HTTP chunking. In fact it's not a haproxy issue but the problem appears through haproxy. One user reported that a non-standard protocol between two servers pretending to be HTTP was causing extremely slow transfers via haproxy while it was OK without it. The fact is that those servers make use of HTTP chunking in a bidirectional fashion, while this is absolutely not permitted at all, as there is no guarantee that both directions will work in parallel at all, nor that the request path won't be broken when the response starts flowing.

The problem through haproxy was the optimization to get as many packets as possible merged into large ones, because the application was sending one small chunk and expecting the other side to reply with a small one. But when haproxy was emitting that, it was telling the system "don't send it too fast, more is coming", resulting in 200 ms delay after each send(). Thus, I have implemented a new "http-no-delay" option which disables the optimization for such abnormal usages, since it was the only issue.

While working on this, I noticed two minor issues that were magnified by the no-delay mode :

• each chunk caused two send() calls to be performed, one for the chunk itself and another one for its size. In the no-delay mode, it's even worse because this effectively results in two TCP packets. So I fixed this. It may very slightly lower CPU usage on sites making heavy use of small chunks, so I decided to merge it.
• splice() was called too often on small objects and was counter productive. So I added a test to avoid calling it for transfers smaller than a page (4kB) since it's better to run recv()+send() for such objects than splice() which will cause a copy to be performed by the kernel anyway. This may be one of the reason why some people were reporting sensibly lower performance with splice() than send()+recv().

Another issue was reported today. The stats interface running in admin mode did not like backends with colons in their name, because the browser was sending the form url-encoded and names were not decoded by haproxy. I fixed it too.

It was possible for http-expect checks to fail on multi-packet responses in a very specific case, this was fixed too.

Last point is not an issue per se, but was requested by a user. The "monitor" responses (HTTP 200) have the "haproxy" word in them, which is sometimes accessible from the outside, and they preferred to be able to remove it. Since HTTP 200 responses were manipulated exactly like the other ones, I extended the "errorfile" statement to support status code 200 for this usage.

The git repository is already up to date, and the daily snapshot will be updated in a few hours.

Cheers,
Willy Received on 2011/05/31 23:14