On Wed, Oct 28, 2026 at 05:42:20PM +0100, Willy Tarreau wrote: > Hi, > > HAProxy 3.5-dev10 was released on 2026/10/28. It added 194 new commits > after version 3.5-dev9. > > Well, among those, 129 were bug fixes for diverse severity levels. We're > still in the process of reviewing a batch of analysis reports in which > around 350 issues are still to be evaluated (mostly of low severity but > these are the ones taking most time to analyze since reports can be very > subjective). A big thank to those doing the triage and analysis work as I > know how painful and boring it is, but what pays off is that at some > point we should see the number of issue reports go down. > > Now for the interesting stuff: > > - filters: permit legacy filters to register at the right place as well. > This means that those with old out-of-tree filters will still see their > code continue to work for a while and the filter registered at the right > place. That's not a reason for not updating them. And as a reminder, a > warning will now be emitted if unused/ignored legacy filters are found > in a proxy. Other small improvements were made. > > - the list of HTTP violations that can be accepted by the > "accept-unsafe-violations-in-http-request/response" proxy options was > becoming too wide, because if you really needed to make an exception > for a bogus application, you had to enable all of them at once, and > this was scaring us away from adding new exceptions. Now these ones > have been split into individual options that can be enabled or disabled > in the global section using the new "acceptable-http-request-violations" > and "acceptable-http-response-violations", which enumerate exactly which > exceptions are accepted when required. This allows to only enable the > missing one, or possibly even to set a few for a whole config without > taking risks. A dozen of exceptions were enumerated, individually > acceptable or not. A new one was added, disabled by default, which is > "short-status-code", which allows to process status codes shorter than > 3 digits, which are now forbidden by default. I think we'll backport > it at least to 3.4 after 3.5 is released. > > - QUIC: the AEAD confidentiality limit was implemented. It's a spec > requirement that mandates changing keys from time to time after a > number of packets used it, in order to keep data and keys protected. > Another improvement consisting in using native HKDF APIs brought nice > performance improvement during handshakes (+11% OpenSSL 3.5.4, +4% > AWS-LC 5.9.0). > > - compression/decompression: libslz was updated to 1.4-dev3, bringing > nice performance improvements (1.4 to 20x compression, 2 to 3x on > decompression) and compression ratios at the same time. Thus basically > we can now afford to decompress/recompress for the previous cost of > only a decompression. Another update might happen before the release > (consider content-type in order to tune the compression algos). > > - SSL: servers now have a new "pha" directive to enable post-handshake > authentication with a server when a certificate is present. It does > not work with AWS-LC which doesn't support PHA. WolfSSL only supports > it when explicitly built with the proper define. > > - threads: the per-thread-group FD table allocation is now NUMA aware. > This should improve performance on multi-socket systems (even though > these ones usually sufferr from other problems, starting with NIC > locality). > > Then as usual more reg tests, CI and doc. > > We're reaching the end of the month, and as usual we're heading towards > the feature-freeze. As you know by now, that doesn't mean we not longer > merge anything, just that the sensitivity of what is merged has to be > seriously questioned, so as not to waste too much developer time that is > needed for continuing to fix reported bugs. We'll also switch to a > weekly release schedule again until the release hopefully between the > last week of November and the first of December. > > I'm aware of a few things that are still coming before the release: > - the revamped cache: some of you dealing with high loads know that > the current design doesn't scale well with threads and that it's > not uncommon to face watchdog warnings when running on 64 cores and > playing with Vary. A new version had been worked on here and ought > to have been merged earlier, but during latest stress tests, we > spotted a few bugs that are better fixed. It's a matter of days so > we'll have it in dev11. > > - HTTP hardening: in addition to the acceptable-violations stuff comes > the need to reject certain things that are not strictly forbidden but > which everyone knows are not acceptable, particularly from the public > internet. That's what I regroup under the term "hardening". The goal > is to have a set of options working like the http-violations, and to > group them by profile so that public binds can use a stricter profile > than private ones. I'm having a working PoC that now proves the model > scales, it only applies it to H1 now and I just need to port it to H2 > and H3 so I prefer finish it before releasing it so as not to confuse > users with a doc that speaks about stuff that's only for H1. My goal > is not to add everything early, just to have the building blocks so we > can later refine this. > > - a few commands on the CLI (wait, show events) should support an > uninterruptible mode to ease writing of scripts: right now they > immediately terminate if stdin is closed as happens when echoing a > command via socat. We know how to proceed, it was just low on the > priority list. > > - some converters to replace/count characters/words a-la "tr"/"grep" > are also in a branch in a horrible but working state, they need a > bit of polishing. > > - we'd like to implement a form of keep-alive protocol on top of socket > pairs so that it's possible for a master to detect an unresponsive > worker (rare but bugs happen). > > - I remember about one report of a confusing message for the automatic > chroot, that requires to better handle the situation. Need to recheck, > as I don't remember the details. > > There are probably a few more that I don't have immediately in mind. > > Anyway, if you want a great, nice and beautiful 3.5, now's really time > to deploy 3.5-dev10 and test it!
By the way (some might have noticed), we've got a second crash on haproxy.org with the latest -dev version. The first one was on dev9, the second on dev10, both in the compression code. So please be careful about that. We'll try to figure the root cause and fix it early next week. Those who don't use compression can deploy, those with compression might better wait for a fix (or disable compression). And those who already deployed might want to keep an eye on it ;-) Willy
