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
