Hi,
HAProxy 2.6.0 was released on 2022/05/31. It added 57 new commits
after version 2.6-dev12, essentially small bug fixes, QUIC counters
and doc updates.
This is a long term supported version that will be maintained till 2027.
I'll sum up the changes from 2.5 here without entering into details as I
was told that my coworkers Nick and Baptiste are working on a blog article
that will show up on https://haproxy.com/blog/ to cover all these updates
in details, and that's a tough work I'm definitely not going to replicate!
First, this version aims at helping users stay up to date with modern
protocols through the support of QUIC & HTTP/3. After having served
haproxy.org without any major issues for two months, we now consider that
it is stable enough to be deployed in production, but we'll maintain its
experimental status for now, because you must be aware that being a young
protocol and an even younger implementation, it's perfectly possible that
some future issues might take time to get fixed, during which it will be
required to disable it.
In addition, QUIC currently relies on the QuicTLS library for the TLS
layer, which is a community effort to maintain a patch set on top of
OpenSSL. And given that the OpenSSL team has deliberately rejected the
opportunity to reintegrate this work, nobody knows how long the QuicTLS
team will have the patience and energy to maintain QuicTLS up to date.
And unless distributions adopt the patch set in their OpenSSL package,
HAProxy as provided by distros will not be built with QUIC support.
In summary, use QUIC, deploy it and have fun with it, but never forget
that maybe one day in 1 year or in 4 years there could be changes around
it in (new config settings, adoption of a new library etc) and that
certain steps in the maintenance cycle could be less smooth than for the
rest of the code only because of OpenSSL not being capable to follow
evolving standards anymore.
Speaking of OpenSSL, HAProxy 2.6 fully supports OpenSSL 3.0 which, among
other API changes, has deprecated support for the old "engines" API,
causing build warnings that would be a nightmare to deal with for package
maintainers. It has come to our attention that engines were almost never
used in the past, that when used, they were most often misused (we still
commonly see the irrelevant "rdrand" engine being configured), and that
those using real engines generally have to rebuild both haproxy and
openssl to adapt to various specificities and/or patches. As such it was
decided to simply disable engines support by default (the "ssl-engine"
keyword will not work anymore), but it may be re-enabled by building with
"USE_ENGINE=1" and ignoring the warnings. Finally, OpenSSL 0.9.8 support
was dropped after we discovered that nobody noticed that it broke in 2.5
with the introduction of JWT. That's usually a sign that it can safely
be abandonned.
HAProxy 2.6 also focuses on usability improvements (remember, simplicity
is key to reliability). Among these, the native HTTP client now supports
DNS resolution and server certificate checking. Both can default to the
default system files, thanks to the "default" resolvers section that is
now inherited from the system files by default, and the "@system-ca"
pseudo ca-file that uses the up-to-date list of CA present on the local
system. This means that safe communication with external agents or service
providers should now be incredibly easier.
On the content processing front, we've seen ugly and complicated configs
that were trying to work around certain misses. The two common examples
are setting dummy a HTTP header to perform a hash on certain key, or
having many conditional rules to append values to lists or assign
variables based on presence or absence of the source or the destination.
This resulted in a new "balance hash" algorithm that directly takes an
expression, the "add_item()" converter that deals with concatenation of
list elements with their respective delimiters, and a list of conditions
to the "set-var" family of actions that will allow to filter in which
case to update a variable (when set/not set, greater/lower etc). When
tested on real world configurations, this could divide the number of
rules by 4.
Some users refrained from upgrading to 2.5 after HTTP/1.0 request body
was rejected by default from body-less requests, and some of their old
agents used to rely on this. A new option was added to preserve the
feature when it's known that the servers are compliant and will not open
a vulnerability ("h1-accept-payload-with-any-method").
It is no longer necessary to specify "expose-fd listeners" nor to pass
"-x" on the command line to inherit the previous process' listening
sockets in master-worker deployments; the new master process will
automatically retrieve them from the old one over one of the dedicated
management sockets.
Version 2.6 also improves management: the dynamic servers feature is
no longer experimental, so those who were waiting for a
