HTTP or HTTPS Protocol Health Checking

When either the HTTP Protocol or HTTPS Protocol options are selected a number of extra options are available as described below.

URL

By default, the health checker tries to access the URL to determine if the machine is available. A different path can be specified here, for example /owa/healthcheck.htm.

Status Codes

Health check status codes can be set to override default functionality. Without any Status Codes set, the following HTTP status codes are considered to be Up:

• 200-299: Success (for example 200 OK, 202 Accepted)
• 301: Moved Permanently
• 302: Found
• 401: Unauthorized

Additionally, 2xx status codes are subject to pattern matching the response data, if this is configured. Other codes are considered up without pattern matching, even if it is set.

If custom health check codes are set:

• Check codes may be set to a list of numbers, each from 300-599
• Check codes may be up to 127 characters long, which means 32 valid codes
• Any code in the list is considered to have a health check status of Up
• Configured codes override the default set

• 2xx codes are always considered up in all cases and are subject to pattern matching, if configured

• Check codes may be official HTTP status codes, unofficial codes or custom-defined user codes – as long as they fall in the range of 300-599

  • For a summary of official HTTP status codes, refer to: http://www.ietf.org/assignments/http-status-codes/http-status-codes.xml

    Further information can be found in the more detailed article: https://tools.ietf.org/rfc/rfc7231.txt

• If the application being checked uses decimal sub-codes (for example 400.1), the decimal part is ignored for the purposes of matching the configured codes. So, 400.1, 400.2 and so on, will all match 400.

  • For a list of Microsoft sub-codes using decimals, refer to: https://support.microsoft.com/en-us/kb/943891

  • Sub-codes may not be configured in the Status Codes field – please use the three digit code

  • Sub-codes are grouped by the top-level code

Use HTTP/1.1

By default, the LoadMaster uses HTTP/1.0. However, you may opt to use HTTP/1.1, which will operate more efficiently. When using HTTP/1.1, the health checks are multiplexed to a single connection. This means that more health checks are sent to the server in a single connection, which is more efficient from a connection point of view, that is, there is only one connection rather than multiple connections every time the Real Servers are checked.

When a Real Server does not send any response to a health check request when using the HTTP/1.1 head method, the LoadMaster takes the Real Server out of rotation in all Virtual Services where the Real Server is participating. If this is not the desired behavior, use HTTP/1.0 instead (you could always send a host an extra header if needed).

HTTP/1.1 Host

When using HTTP/1.1 checking, the Real Servers require a hostname to be supplied in each request. If no value is set, then this value is the IP address of the Virtual Service.

To send Server Name Indication (SNI) host information in HTTPS health checks, please enable Use HTTP/1.1 in the Real Servers section of the relevant Virtual Service(s) and specify a host header. If this is not set, the IP address of the Real Server is used.

HTTP Method

When accessing the health check URL, the system can use either the HEAD, GET or POST method.

In LoadMaster firmware version 7.2.52, support was added for the OPTIONS method for HTTP and HTTPS health check types. This specifies that the server will be marked up when the LoadMaster receives a 200 OK in response to an HTTP (or HTTPS) OPTIONS request sent by the LoadMaster.

The OPTIONS HTTP method requests a description of the permitted communication options from the server. A 200 OK response from the server contains a response body which can be optionally searched for specific text in order to provide an additional check. To search the response body, specify the search text in the Reply 200 Pattern text box that appears when you select the OPTIONS HTTP method. The server will be marked up if the provided text is found in the response body; otherwise, the server is marked down.

Post Data

This field will only be available if the HTTP Method is set to POST. When using the POST method, up to 2047 characters of POST data can be passed to the server.

Reply 200 Pattern

When using the GET or the POST method, the contents of the returned response message can be checked. If the response contains the string specified by this Regular Expression, then the machine is determined to be up. The response will have all HTML formatting information removed before the match is performed. Only the first 4K of response data can be matched.

If the response message contains multiple lines, each line is split and is considered as a separate entity. The lines are tested one-by-one (in sequence) against the pattern until one succeeds. For example, if the response is

Example

Pattern

If the Reply 200 Pattern is “/Example/”, it will attempt to match it first against “Example” and succeed.

If the Reply 200 Pattern is “/Pattern/”, it will attempt to match it first against “Example” and fail, then move on and try to match it against “Pattern” and succeed, resulting in an UP health check.

The LoadMaster will only check for this phrase if the reply from the server is a 200 code. If the reply is something else, the page is marked as down without checking for the phrase. However, if the reply is a redirect (code 302), the page is not marked as down. This is because the LoadMaster assumes that the phrase will not be present and also it cannot take the service down, as the redirect would then become useless.

Both Regular Expressions and Perl Compatible Regular Expressions (PCRE) can be used to specify strings.

The checker only checks the response one line at a time (and it ignores HTML/XML tags). It is not possible to concatenate multiple lines on the same reply 200 pattern.

For further information on Regular Expressions and PCRE, please refer to the Content Rules, Feature Description document.

Custom Headers

Here you can specify up to 4 additional headers/fields which is sent with each health check request. Clicking the Show Headers button will show the entry fields. The first field is where you define the key for the custom header that is to be part of the health check request. The second field is the value of the custom header that is to be sent as part of the health check request. Once the information is input, click the Set Header button. Each of the headers can be up to a maximum of 20 characters long and the fields can be up to a maximum of 100 characters long. However, the maximum allowed number of characters in total for the 4 header/fields is 256.

The following special characters are allowed in the Custom Headers fields:

; . ( ) / + = - _

If a user has specified HTTP/1.1, the Host field is sent as before to the Real Server. This can be overridden by specifying a Host entry in the additional headers section. The User-Agent can also be overridden in the same manner. If a Real Server is using adaptive scheduling, the additional headers which are specified in the health check are also sent when getting the adaptive information.

Health Check Authorization

It is possible to perform a health check using an authenticated user: enable Use HTTP/1.1, select HEAD as the HTTP Method and enter the Authorization header with the correctly constructed value. The Authorization field is constructed as follows:

The username and password are combined into a string “username:password”.

The resulting string is then encoded using the RFC2045-MIME variant of Base64, except not limited to 76 char/line.

The authorization method and a space, i.e. “Basic“ is then put before the encoded string.

For example, if the user agent uses 'Aladdin' as the username and 'open sesame' as the password then the field is formed as follows:

Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

Using SNI with Health Checks

To send SNI host information in HTTPS health checks, please enable Use HTTP/1.1 in the Real Servers section of the relevant Virtual Service(s) and specify a host header. If this is not set, the IP address of the Real Server is used.