Hi, HAProxy 3.1.10 was released on 2025/11/07. It added 45 new commits after version 3.1.9.
This update covers exactly the same range as the last two 3.2 updates, so I've picked the relevant parts of the descriptions below: - a missed initialization in QUIC could trigger a BUG_ON() hence provoke a crash in qc_rcv_buf(). - the way certain QUIC stacks recently started to send their crypto frames leaving a single byte hole between them was fundamentally incompatible with our storage model which requires at least 8 bytes holes. As such, some of them would experience random connection failures due to dropped frames. This required to rework that storage part (the "ncbuf" stuff) to support an alternate byte-addressed area that is compatible with this behavior that we initially considered as irrelevant and only likely used by attackers. This new work has been extensively tested in produciton where the issue was first reported, and given that there were some reports of recent Firefox versions triggering the issue, we considered that we should not wait to backport it. Thanks Annika for your wonderful help BTW! - as mentioned previously here, we've got a report of accidental breakage in 3.0 of the hash algorithms involved in consistent hashing, that prevents some users from migrating from pre-3.0 to 3.0+ by causing too heavy a cache redistribution. The problem is that fixing it will also cause some redistribution for those running on affected versions. The overall consensus was that those not noticing the issue will not be impacted by the fix and those impacted by it have not upgraded because of it, so better fix it in any case. In order to know if you're subject to this problem, look for "hash-type consistent" in your config, and if present, then check if there is a "hash-key" setting. If the first one is present without the second one or with "hash-key id", you may notice a drop in cache hit ratio during the upgrade. If the cache hit ratio is already small (e.g. small storage), it may be better to upgrade all LB nodes at once. If the cache hit ratio is very high (large storage), it might be better to first upgrade one LB node to pre-heat the caches with the redistributed objects, then upgrade the other ones. But based on what was observed since then, it should pass smoothly at most if not all places. - declaring thread groups with non-existing threads would cause some listeners to fail to accept pending connections, or even to crash when trying to dispatch incoming connections to the same group's threads. This was fixed by refining the groups to only work with existing threads. However, if a group ends up with no thread, now an error will be reported and the process will refuse to start (which is always better than starting and rejecting traffic like today). This only concerns those with manually configured "thread-groups" directives in their configs. - CLI: sending many requests (e.g. "add map") would send one LF character at a time and would make socat's CPU usage quickly reach 100% and increase the update time. - we've got some reports of segfaults at boot with GCC 15 and tree vectorization being applied to unaligned data at -O3, only for certain very specific targets (westmere and nehalem only). An extra build option to calm down that optimization was added that got rid of the issue, and greeted us with the pleasant surprise of improving the -O3 request rate by about 5%. All optimizations are not always as effective as planned. - 1xx responses in HTTP/3 were not always properly encoded if they would appear in the same response packet as the final response, and they would generally cause a parsing error on the client, which will abort the connection; 1xx sent along the final response are really not common right now and mostly happen in testing, but some applications could trigger them more than others. - a slow memory leak of SSL captures has been noticed over the last two years on haproxy.org, making us believe that it was in the SSL lib, because the counters we placed around it showed more calls to the init() callback than the release() one. We were actually wrong and discovered that in TLS 1.3 there can be two consecutive Client Hello messages on a connection and that this caused the capture area to be allocated twice and only the last one was freed. At least it explained everything, and this was fixed (and confirms to no longer leak). - a ring that would fail to connect to one of its servers could remain stuck forever if unlucky and it happens at a precise ms within the 20 first seconds of boot (then every 49.7 days). - a bug in mt_list_delete() applied to an already deleted entry in the process of being re-added was detected in 3.3-dev where it would make a development branch constantly fail. The fact that it was never noticed before comforts us in the idea that the pattern doesn't exist in 3.2 or older. But we preferred to backport the fix in case it would become necessary in the future and we'd forget about it. - a case of rare crashes was addressed when idle connections are purged, woken up and reused at the same time. Most users will never notice it, we triggered it around 500k req/s on 128 threads... - internal fixes for MT lists that could permit the compiler to do some updates in a bad order, causing deadlocks. It was only met in stress- testing. - the condition that decides whether to produce HTTP status 414 or 431 was incorrect and would only produce 414 (URI too long). - updating a CA from the CLI could occasionally cause a crash due to objects being still referenced. - on some rare occasions, stick-table keys of type strings could sometimes be incorrectly indexed with some extra bytes past the final zero and appear as duplicates, causing entries to get mixed. This is one of the longest living bugs we've had, it's been there since the feature was implemented in 1.4-dev7 almost 16 years ago! - default HTTP 405, 431 and 501 error files had an incorrect content length that would probably cause the front connections to be closed after the response. With 3.3 getting closer, it's about time to switch away from 3.1 an either upgrade to 3.2 or even better, test 3.3-dev which is quickly getting better. Think about it if you're upgrading your 3.1 ;-) Please find the usual URLs below : Site index : https://www.haproxy.org/ Documentation : https://docs.haproxy.org/ Wiki : https://github.com/haproxy/wiki/wiki Discourse : https://discourse.haproxy.org/ Slack channel : https://slack.haproxy.org/ Issue tracker : https://github.com/haproxy/haproxy/issues Q&A from devs : https://github.com/orgs/haproxy/discussions Sources : https://www.haproxy.org/download/3.1/src/ Git repository : https://git.haproxy.org/git/haproxy-3.1.git/ Git Web browsing : https://git.haproxy.org/?p=haproxy-3.1.git Changelog : https://www.haproxy.org/download/3.1/src/CHANGELOG Dataplane API : https://github.com/haproxytech/dataplaneapi/releases/latest Pending bugs : https://www.haproxy.org/l/pending-bugs Reviewed bugs : https://www.haproxy.org/l/reviewed-bugs Code reports : https://www.haproxy.org/l/code-reports Latest builds : https://www.haproxy.org/l/dev-packages Willy --- Complete changelog : Amaury Denoyelle (11): MINOR: quic: restore QUIC_HP_SAMPLE_LEN constant BUG/MINOR: quic: check applet_putchk() for 'show quic' first line BUG/MEDIUM: h3: properly encode response after interim one in same buf MINOR: ncbuf: extract common types MINOR: ncbmbuf: define new ncbmbuf type MINOR: ncbmbuf: implement add MINOR: ncbmbuf: implement iterator bitmap utilities functions MINOR: ncbmbuf: implement ncbmb_data() MINOR: ncbmbuf: implement advance operation MINOR: ncbmbuf: add tests as standalone mode BUG/MAJOR: quic: use ncbmbuf for CRYPTO handling Aurelien DARRAGON (1): BUG/MINOR: sink: retry attempt for sft server may never occur Christopher Faulet (3): BUG/MINOr: hlua: Fix receive from HTTP applet by properly accounting data BUG/MEDIUM: apppet: Improve spinning loop detection with the new API BUG/MEDIUM: applet: Improve again spinning loops detection with the new API Frederic Lecaille (2): BUG/MINOR: quic: too short PADDING frame for too short packets BUG/MAJOR: quic: uninitialized quic_conn_closed struct members Huangbin Zhan (1): MINOR: http: fix 405,431,501 default errorfile Maximilian Moehl (1): BUG/MEDIUM: mux-h1: fix 414 / 431 status code reporting Olivier Houchard (4): BUG/MEDIUM: stick-tables: Don't forget to dec count on failure. BUG/MEDIUM: mt_list: Make sure not to unlock the element twice BUG/MEDIUM: mt_lists: Avoid el->prev = el->next = el BUG/MEDIUM: mt_list: Use atomic operations to prevent compiler optims Remi Tricot-Le Breton (4): BUG/MINOR: ssl: Free global_ssl structure contents during deinit BUG/MINOR: ssl: Free key_base from global_ssl structure during deinit BUG/MEDIUM: ssl: Crash because of dangling ckch_store reference in a ckch instance BUG/MINOR: init: Do not close previously created fd in stdio_quiet Valentine Krasnobaeva (1): MINOR: debug: add distro name and version in postmortem William Lallemand (3): MINOR: ssl: diagnostic warning when both 'default-crt' and 'strict-sni' are used BUILD: ssl: can't build when using -DLISTEN_DEFAULT_CIPHERS BUG/MINOR: ssl: returns when SSL_CTX_new failed during init Willy Tarreau (14): BUG/MEDIUM: ssl: take care of second client hello BUG/MINOR: ssl: always clear the remains of the first hello for the second one BUILD: makefile: disable tail calls optimizations with memory profiling BUG/MAJOR: lb-chash: fix key calculation when using default hash-key id DOC: clarify the experimental status for certain features BUG/MEDIUM: threads/config: drop absent threads from thread groups BUG/MEDIUM: build: limit excessive and counter-productive gcc-15 vectorization BUG/MINOR: stick-tables: properly index string-type keys MINOR: applet: do not put SE_FL_WANT_ROOM on rcv_buf() if the channel is empty MINOR: cli: create cli_raw_rcv_buf() from the generic applet_raw_rcv_buf() BUG/MEDIUM: cli: do not return ACKs one char at a time DOC: config: slightly clarify the ssl_fc_has_early() behavior BUG/MEDIUM: mux-h2: make sure not to move a dead connection to idle BUG/MEDIUM: connections: permit to permanently remove an idle conn ---
