mirror of
https://github.com/haproxy/haproxy.git
synced 2026-02-03 20:39:41 -05:00
644b3dc7d8
As discussed on https://github.com/orgs/haproxy/discussions/3146 and on the mailing list, there's a marked preference for having abortonclose enabled by default when relevant. The point being that with todays' internet, the large majority of requests sent with a closed input channel are aborted requests, and that it's pointless to waste resources processing them. This patch now considers both "option abortonclose" and its opposite "no option abortonclose" to figure whether abortonclose is enabled or disabled in a backend. When neither are set (thus not even inherited from a defaults section), then it considers the proxy's mode, and HTTP mode implies abortonclose by default. This may make some legacy services fail starting with 3.3. In this case it will be sufficient to add "no option abortonclose" in either the affected backend or the defaults section it derives from. But for internet-facing proxies it's better to stay with the option enabled. |
||
|---|---|---|
| .. | ||
| common.pem | ||
| h1_host_normalization.vtc | ||
| h1_request_target_validation.vtc | ||
| h1_to_h1.vtc | ||
| h2_desync_attacks.vtc | ||
| h2_to_h1.vtc | ||
| http_abortonclose.vtc | ||
| http_bodyless_response.vtc | ||
| http_bodyless_spliced_response.vtc | ||
| http_request_buffer.vtc | ||
| http_splicing.vtc | ||
| http_splicing_chunk.vtc | ||
| http_transfer_encoding.vtc | ||
| http_wait_for_body.vtc | ||
| protocol_upgrade.vtc | ||
| scheme_based_normalize.vtc | ||
| srv_ws.vtc | ||
| truncated.vtc | ||
| websocket.vtc | ||