From: Gaetan Rivet Date: Thu, 13 Feb 2020 09:30:01 +0000 (+0100) Subject: BUG/MINOR: checks: chained expect will not properly wait for enough data X-Git-Tag: v2.2-dev7~180 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=738ee76aa7a9968cb9c9610725c26622c50f0b33;p=thirdparty%2Fhaproxy.git BUG/MINOR: checks: chained expect will not properly wait for enough data TCP check expect matching strings or binary patterns are able to know prior to applying their match function whether the available data is already sufficient to attempt the match or not. As such, on insufficient data the expect is postponed. This behavior avoids unnecessary matches when the data could not possibly match. When chaining expect, upon passing the previous and going onto the next however, this length check is not done again. Then the match is done and will necessarily fail, triggering a new wait for more data. The end result is the same for a slightly higher cost. Check received data length for all expects in a chain. This bug exists since the introduction of the feature: Fixes: 5ecb77f4c76f ("MEDIUM: checks: add send/expect tcp based check") Version 1.5+ impacted. --- diff --git a/src/checks.c b/src/checks.c index f67e9229b6..a685d07c9d 100644 --- a/src/checks.c +++ b/src/checks.c @@ -3150,10 +3150,10 @@ static int tcpcheck_main(struct check *check) goto out_end_tcpcheck; } + tcpcheck_expect: if (!done && (check->current_step->string != NULL) && (b_data(&check->bi) < check->current_step->string_len) ) continue; /* try to read more */ - tcpcheck_expect: if (check->current_step->string != NULL) ret = my_memmem(contentptr, b_data(&check->bi), check->current_step->string, check->current_step->string_len) != NULL; else if (check->current_step->expect_regex != NULL)