Replies: 3 comments
-
|
In places I don’t have this enabled I just forgot. So, yes, enable by default would be my recommendation. |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
After reading through the docs, this seems like a reasonable default to have. I didn't know this option existed either until your post. I've added it to our config and rolled it out. |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
FWIW now implemented in 3.3-dev with commits 644b3dc and 00b27a9. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
Problem statement
I've often found myself recommending HTTP users to enable
option abortoncloseto 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.Proposal
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 80should 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 abortoncloseindefaultssections 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.Beta Was this translation helpful? Give feedback.
All reactions