From bd741540d2a31da74b10dfffcbc9a9024cc11ef2 Mon Sep 17 00:00:00 2001 From: Willy Tarreau Date: Tue, 16 Mar 2010 18:46:54 +0100 Subject: [PATCH] [MEDIUM] checks: add support for HTTP contents lookup MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit This patch adds the "http-check expect [r]{string,status}" statements which enable health checks based on whether the response status or body to an HTTP request contains a string or matches a regex. This probably is one of the oldest patches that remained unmerged. Over the time, several people have contributed to it, among which FinalBSD (first and second implementations), Nick Chalk (port to 1.4), Anze Skerlavaj (tests and fixes), Cyril Bonté (general fixes), and of course myself for the final fixes and doc during integration. Some people already use an old version of this patch which has several issues, among which the inability to search for a plain string that is not at the beginning of the data, and the inability to look for response contents that are provided in a second and subsequent recv() calls. But since some configs are already deployed, it was quite important to ensure a 100% compatible behaviour on the working cases. Thus, that patch fixes the issues while maintaining config compatibility with already deployed versions. (cherry picked from commit b507c43a3ce9a8e8e4b770e52e4edc20cba4c37f) --- doc/configuration.txt | 89 +++++++++++++++++++++++++++++- include/types/proxy.h | 10 ++++ src/cfgparse.c | 85 ++++++++++++++++++++++++++++- src/checks.c | 124 +++++++++++++++++++++++++++++++++++++++--- 4 files changed, 296 insertions(+), 12 deletions(-) diff --git a/doc/configuration.txt b/doc/configuration.txt index 12ce86ec2..9a7c0e37a 100644 --- a/doc/configuration.txt +++ b/doc/configuration.txt @@ -868,6 +868,7 @@ fullconn X - X X grace X X X X hash-type X - X X http-check disable-on-404 X - X X +http-check expect - - X X http-check send-state X - X X http-request - X X X id - X X X @@ -2083,9 +2084,93 @@ http-check disable-on-404 generate an alert, just a notice. If the server responds 2xx or 3xx again, it will immediately be reinserted into the farm. The status on the stats page reports "NOLB" for a server in this mode. It is important to note that this - option only works in conjunction with the "httpchk" option. + option only works in conjunction with the "httpchk" option. If this option + is used with "http-check expect", then it has precedence over it so that 404 + responses will still be considered as soft-stop. - See also : "option httpchk" + See also : "option httpchk", "http-check expect" + + +http-check expect [!] + Make HTTP health checks consider reponse contents or specific status codes + May be used in sections : defaults | frontend | listen | backend + no | no | yes | yes + Arguments : + is a keyword indicating how to look for a specific pattern in the + response. The keyword may be one of "status", "rstatus", + "string", or "rstring". The keyword may be preceeded by an + exclamation mark ("!") to negate the match. Spaces are allowed + between the exclamation mark and the keyword. See below for more + details on the supported keywords. + + is the pattern to look for. It may be a string or a regular + expression. If the pattern contains spaces, they must be escaped + with the usual backslash ('\'). + + By default, "option httpchk" considers that response statuses 2xx and 3xx + are valid, and that others are invalid. When "http-check expect" is used, + it defines what is considered valid or invalid. Only one "http-check" + statement is supported in a backend. If a server fails to respond or times + out, the check obviously fails. The available matches are : + + status : test the exact string match for the HTTP status code. + A health check respose will be considered valid if the + response's status code is exactly this string. If the + "status" keyword is prefixed with "!", then the response + will be considered invalid if the status code matches. + + rstatus : test a regular expression for the HTTP status code. + A health check respose will be considered valid if the + response's status code matches the expression. If the + "rstatus" keyword is prefixed with "!", then the response + will be considered invalid if the status code matches. + This is mostly used to check for multiple codes. + + string : test the exact string match in the HTTP response body. + A health check respose will be considered valid if the + response's body contains this exact string. If the + "string" keyword is prefixed with "!", then the response + will be considered invalid if the body contains this + string. This can be used to look for a mandatory word at + the end of a dynamic page, or to detect a failure when a + specific error appears on the check page (eg: a stack + trace). + + rstring : test a regular expression on the HTTP response body. + A health check respose will be considered valid if the + response's body matches this expression. If the "rstring" + keyword is prefixed with "!", then the response will be + considered invalid if the body matches the expression. + This can be used to look for a mandatory word at the end + of a dynamic page, or to detect a failure when a specific + error appears on the check page (eg: a stack trace). + + It is important to note that the responses will be limited to a certain size + defined by the global "tune.chksize" option, which defaults to 16384 bytes. + Thus, too large responses may not contain the mandatory pattern when using + "string" or "rstring". If a large response is absolutely required, it is + possible to change the default max size by setting the global variable. + However, it is worth keeping in mind that parsing very large responses can + waste some CPU cycles, especially when regular expressions are used, and that + it is always better to focus the checks on smaller resources. + + Last, if "http-check expect" is combined with "http-check disable-on-404", + then this last one has precedence when the server responds with 404. + + Examples : + # only accept status 200 as valid + http-request expect status 200 + + # consider SQL errors as errors + http-request expect ! string SQL\ Error + + # consider status 5xx only as errors + http-request expect ! rstatus ^5 + + # check that we have a correct hexadecimal tag before /html + http-request expect rstring