On Sat, Oct 31, 2026 at 03:30:34AM +0100, Willy Tarreau wrote: > 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 ;-)
So I was wrong on that, both were on dev10, and it looks like I haven't updated the buffer full detection code to plan for slz's worst-case overhead in case of incompressible data. Working on it now. Willy
