mirror of
http://git.haproxy.org/git/haproxy.git/
synced 2024-12-13 15:04:42 +00:00
1afd826ae4
Some expect rules cannot be satisfied due to inherent ambiguity towards the received data: in the absence of match, the current behavior is to be forced to wait either the end of the connection or a buffer full, whichever comes first. Only then does the matching diagnostic is considered conclusive. For instance : tcp-check connect tcp-check expect !rstring "^error" tcp-check expect string "valid" This check will only succeed if the connection is closed by the server before the check timeout. Otherwise the first expect rule will wait for more data until "^error" regex matches or the check expires. Allow the user to explicitly define an amount of data that will be considered enough to determine the value of the check. This allows succeeding on negative rstring rules, as previously in valid condition no match happened, and the matching was repeated until the end of the connection. This could timeout the check while no error was happening. [Cf: I slighly updated the patch. The parameter was renamed and the value is a signed integer to support -1 as default value to ignore the parameter.] |
||
---|---|---|
.. | ||
1be_40srv_odd_health_checks.vtc | ||
4be_1srv_health_checks.vtc | ||
4be_1srv_smtpchk_httpchk_layer47errors.vtc | ||
40be_2srv_odd_health_checks.vtc | ||
common.pem | ||
http-check-send.vtc | ||
http-monitor-uri.vtc | ||
tcp-check_min-recv.vtc | ||
tcp-check_multiple_ports.vtc | ||
tls_health_checks.vtc |