Hello, I'm sending here what I posted there: > https://github.com/orgs/haproxy/discussions/3146 > Please use whatever suits you best to respond. >
I believe that the choice of default values in any software should follow three main principles: - Alignment with best practices Defaults should reflect the current state of the art. This avoids carrying outdated or even unsafe behaviors simply for historical reasons. A clear example comes from security: options once considered acceptable a decade ago are now deprecated, and defaults must evolve accordingly. - Adaptation to hardware evolution Defaults should not remain frozen in time. A well-known case is MySQL, where buffer sizes set 20–25 years ago were left unchanged for too long. As a result, for many years the "default" installation performed poorly on modern machines, even though plenty of RAM was available. This contributed to MySQL's poor reputation in terms of performance compared to PostgreSQL, even though it was largely a configuration issue rather than a flaw in the engine itself. The same applies to HTTPD vs Nginx: the perception that Nginx was faster often came not from a superior engine, but from better-tuned defaults out of the box (yup, I just opened two troll boxes in one paragraph :p :p). - Adaptation to real-world usage This is where abortonclose clearly fits. In today's usage, the expected behavior is to stop processing a request once the client has gone away. There is no value in completing a task if nobody will receive the result. In fact, one could argue this is a security and robustness measure, as it reduces wasted CPU cycles, prevents buildup of "zombie" requests, and helps mitigate denial-of-service patterns (e.g., aborted TLS handshakes). Having this behaviour as a default will not surprise a new-comer. This said, my humble opinion is that yes, we should change the default to enable 'abortonclose'. Of course, this must be clearly documented in the release notes, with a strong mention in the "changes in default behavior" section. Given the importance of the parameter, it might even be worth considering a notice/warning when the option is not explicitly set (either enabled or disabled), to make sure administrators are consciously aware of the behavior in their configuration. Hope this helps, Olivier
