tree 31b15633ff5bbed30b21d84824fb6e29aa4f047a
parent 8b00b36f9908dc2b2d9c2e641d359998c6d1ead9
author Gaetan Rivet <grive@u256.net> 1581086237 +0100
committer Christopher Faulet <cfaulet@haproxy.com> 1587973177 +0200

MINOR: checks: add min-recv tcp-check expect option

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.]