mirror of
http://git.haproxy.org/git/haproxy.git/
synced 2024-12-20 02:30:13 +00:00
96816b0755
Depending on the timing, the second client that should be reported as a
client abort during connection attempt ("CC--" termination state) is
sometime logged as a server close ("SC--" termination state) instead. It
happens because sometime the connection failure to the server s1 is detected
by haproxy before the client c2 aborts. There is no retries and the
connection timeout is set to 100ms. So, to work, the client abort must be
performed and detected by haproxy in less than 100ms.
To fix the issue, the c2 client is now routed to a backend with a connection
timeout set to 1 second and 10 retries. It should be large enough to detect
the client aborts (~10s)
In addition, there is another race condition when the script is
started. sometime, server s1 is not stopped when the first client sends its
request. So a barrier was added to be sure it is stopped before starting to
send requests. And we wait to be sure the server is detected as DOWN to
unblock the barrier. It is performed by a dedicated backend with an
healthcheck on the server s1.
This patch should solve issue #1664.
|
||
|---|---|---|
| .. | ||
| common.pem | ||
| h1_to_h1.vtc | ||
| h2_desync_attacks.vtc | ||
| h2_to_h1.vtc | ||
| http_abortonclose.vtc | ||
| http_bodyless_response.vtc | ||
| http_msg_full_on_eom.vtc | ||
| http_request_buffer.vtc | ||
| http_splicing.vtc | ||
| http_transfer_encoding.vtc | ||
| http_wait_for_body.vtc | ||
| protocol_upgrade.vtc | ||
| scheme_based_normalize.vtc | ||
| srv_ws.vtc | ||
| websocket.vtc | ||