Content Matching

When the Rule Type selected is Content Matching, the following options are available.

Rule Name

This is the name of the rule.

Match Type:

• Regular Expression: A powerful way of creating complex matching and replacement rules. Regular expressions can also be used to reference parts of the original string.

• Prefix: Matches from the beginning of the string only.
• Postfix: Matches from the end of the string only.

Header Field

The header field name must be matched. If no header field name is set, the default is to match the string within the URL.

Rules can be matched based on the Source IP of the client by entering src-ip within the Header Field input field. The header field is populated by the source IP of the client.

The Header Field can be set to method to match on the HTTP method field.

The body of a request can also be matched by typing body in the Header Field text box. When matching on the body, up to the first 50K of the input stream is read.

Match String

Enter the pattern to match. Both Shell Regular Expressions and Perl Compatible Regular Expressions (PCRE) are supported.

Both are the same in terms of performance. Performance is affected if a highly complex expression is used. The maximum number of characters allowed is 250.

To create a rule that sends all URL requests that have /images* as the root path to a group of servers, the Match String value should be /^\/images.*/

It is possible to perform content switching on URL, HTTP Header, Source IP, or the body of a request. The default behavior is to test the URL, however, a Header Field may be specified instead. To use Source IP content switching, use the pseudo-header src-ip — the source IP of the client is then available as a text field. The HTTP method can be matched upon by filling out the Header Field text box and the method. The body can be matched upon by entering body in the Header Field text box.

Negation

Negation inverts the sense of the match. Without negation, all requests that include /images/ for example, would match an applicable rule. With negation, all requests except /images/ would match the rule.

Ignore Case

If enabled, case is ignored when comparing strings.

Include Host in URL

If selected, this option prepends the hostname, for example, support.progress.com, to the request URL before performing the match.

Include Query in URL

Selecting this option enables the match string to include the text generated after the ? in a URL. This part of the URL is the URL query. For example, in the URL http://example.com/images/imagid.jsp?item=1, the query is item=1.

Fail on Match

If this rule is matched, then always fail to connect. If an error code or error URL is set, the code/URL is sent back to the client.

Use of Flags to Create Dependent Rules

By using the Perform If Flag Set and Set Flag If Matched options it is possible to make rules dependent on each other, therefore, only execute a particular rule(s) if another rule(s) has been successfully matched.

For example, if a rule called Test2 should execute only if a rule called Test1 was matched successfully, complete the following steps:

1. Log in to the LoadMaster WUI.
2. In the main menu, select Rules & Checking and Content Rules.

   

3. Click Modify on the Test1 rule.

   

4. Select Flag 1 from the Set Flag If Matched drop-down list.
5. Click Modify Rule.
6. Click Modify on the Test2 rule.

   

7. Select Flag 1 from the Perform If Flag Set drop-down list.
8. Click Modify Rule.

When the Test1 rule is successfully matched, a flag (Flag 1) is set. The Test2 rule will not execute unless Flag 1 is set. So, Test2 cannot run unless Test1 has been successfully matched.

If a flag is set during the matching of a request, it can be queried when processing response header modifications. Therefore, if the request sets a given flag, when the server responds, any response rules that are dependent on the flag will only execute if it is set.