Hi all,
I'm sending here what I posted there:
https://github.com/orgs/haproxy/discussions/3146
Please use whatever suits you best to respond.
I've often found myself recommending HTTP users to enable option abortonclose
to automatically drop HTTP requests that clients abort, and now even avoid to
compute HTTPS handshakes on closed connections, and often users were not aware
of this option (sometimes asked why it was not the default), or were afraid of
enabling it due to the wording in the documentation.
I'm just wondering if we shouldn't simply turn it on by default in HTTP
frontends/backends as long as it remains possible to disable it (using no
option abortonclose) for those who know that they're using hacked scripts to
communicate with their services. A number of public servers nowadays just close
the connection or return an error if the client closes immediately after
sending a request, so that's not new territory. And those dealing with failover
of SSL frontends under high load know that it can take time to stabilize the
CPU usage because aborted handshakes cost a lot and slow the recovery down.
Also with the numerous tools available to send request, the cases where people
still need to issue printf "GET /foo HTTP/1.1\r\nHost:
bar.example.com\r\n\Connection: close\r\nr\n" | nc address 80 should be so rare
that it would make sense that these are the ones who should enable the option.
I've run a quick non-scientific search in closed issues, and I'm seeing it 1/3
of the times I'm seeing "roundrobin", so for me it's a confirmation that lots
of users need it and that most miss it.
I have the intuition that distinguishing the absence of an option from no
option abortonclose in defaults sections in the config parser might be a little
bit tricky, so before evaluating the code impacts I'm interested in getting
feedback on this, particularly compelling reasons for not to do it. We're in a
non-LTS version with 3.3, it's still not too late to adopt this and document it
as a change of defaults in the wiki.
Thanks!
Willy
