Hi,
HAProxy 2.7-dev1 was released on 2022/06/24. It added 131 new commits
after version 2.7-dev0.
There's not that much new stuff yet but plenty of small issues were
addressed, and it's already been 3 weeks since the release thus I figured
it was a perfect timing for a -dev1 for those who want to stay on the edge
without taking much risks.
In addition to the fixes that went into 2.6.1 already, some HTTP/3 issues
were addressed and a memory leak affecting QUIC was addressed as well (thanks
to @Tristan971 for his precious help on this one).
Aside fixes, a few improvements started already. First, and to finish on
QUIC, the QUICv2 version negotiation was implemented. This will allow us
to follow the progress on the QUICv2 drafts more closely.
On HTTP/2, the maintainer of the Lighttpd web server reported a nasty case
that he observed between curl and lighttpd which is very similar to the so
called "Silly Window Syndrom" in TCP where a difference of one byte between
a buffer size and a window size may progressively make the transfer
degenerate until almost all frames are 1-byte in size. It's not a bug in
any product, just a consequence of making certain standard-compliant stacks
interoperate. Some workarounds were placed in various components that
allowed the issue to appear. We did careful testing on haproxy and couldn't
produce it there, in part due to our buffer management that makes it
difficult to read exactly the sizes that produce the issue. But there's
nothing either that can strictly prevent it from happening (e.g. with a
sender using smaller frames maybe). So we implemented the workaround as
well, which will also result in sending slightly less frames during
uploads. The goal is to backport this once it has been exposed for a
while without trouble in 2.7.
Another noticeable improvement is the inclusion of a feature that had
been written in the now dead ROADMAP file for 15 years: multi-criteria
bandwidth limiting. It allows to combine multiple filters to enforce
bandwidth limitations on arbitrary criteria by looking at their total
rate in a stick table. Thus it's possible to have per-source, per-
destination, per-network, per-AS, per-interface bandwidth limits in
each direction. In addition there's a stream-specific pair of limits
(one per direction as well) that can even be adjusted on the fly. We
could for example imagine that a client sends a POST request to a
server, that the server responds with a 100-Continue and a header
indicating the max permitted upload bandwidth, and then the transfer
will be automatically capped. Quite frankly, I've been wanting this
for a long time to address the problem of buffer bloat on small links
(e.g. my old ADSL line), and here there's now an opportunity to
maintain a good quality of service without saturating links thanks to
this. I'm pretty sure that some users will be creative and may even
come up with ideas of improvements ;-)
We noticed during the initial QUIC tests that some users faced problems
because they were linking external Lua libs that were built with
incompatible versions of OpenSSL, resulting in some objects being
allocated with one lib and modified with the other, etc. Sometimes the
crash happened during the boot, sometimes at runtime. As this is a
nightmare to diagnose ("show libs" helped a lot there), there's now a
warning at boot when it's detected that some runtime libs bring some
incompatible dependencies by changing a few critical functions such as
malloc(), free() and a few OpenSSL functions. It's not perfect, it's
not rocket science either but it seems to do the job. I'm not totally
sold on the solution, so I'm interested in hearing about any unexpected
report so that we can see if we need to relax some checks (e.g. by
making a special case of openssl and comparing ABI versions maybe).
Such a mess reminded me why I was against adopting a module-oriented
architecture a decade ago :-)
And the rest is essentially cleanups, small refactorings, etc.
At the moment, this version is the most stable 2.7 as all known bugs were
fixed, and nothing risky was merged yet, so it's the right moment to play
with it, particularly if you want to test QUIC or bandwidth limiting.
Some more sensitive updates will come soon in various areas including
threading. The work on pushing the thread limit beyond 64 continues,
we're still far from it but the scheduler was updated so that a series
will be merged soon.
Please find the usual URLs below :
Site index : http://www.haproxy.org/
Documentation: http://docs.haproxy.org/
Wiki : https://github.com/haproxy/wiki/wiki
Discourse: http://discourse.haproxy.org/
Slack channel: https://slack.haproxy.org/
Issue tracker: https://github.com/haproxy/haproxy/issues
Sources : http://www.haproxy.org/download/2.7/src/
Git repository : http://git.haproxy.org/git/haproxy.git/
Git Web browsing : http://git.haproxy.org/?p=haproxy.git
Changelog
