Content rule (pattern) syntax

Learn how to use the content rule (pattern) syntax for the CBR component, along with scenarios and examples of its usage.

Content rule (pattern) syntax

Attention: Applicable only if you selected content for the rule type.
Enter the pattern syntax that you want to use, with the following restrictions:
  • No spaces can be used within the pattern
  • Special characters, unless you precede the character with a backward slash (\):
    *
    Wildcard (matches 0 to x of any character)
    (
    left parenthesis that is used for logic grouping
    )
    right parenthesis that is used for logic grouping
    &
    Logical AND
    |
    Logical OR
    !
    Logical NOT

Reserved keywords

Reserved keywords are always followed by an equal sign "=".

Method
HTTP method in the request, for example GET, POST
URI
Path of the URL request (case sensitive)
Version
Specific version of request, either HTTP/1.0 or HTTP/1.1
Host
Value from the host: header (not case-sensitive)
Important: Optional in HTTP/1.0 protocols
<key>
Any valid HTTP header name that Dispatcher can search for. Examples of HTTP headers are User-Agent and Connection, Referrer
A browser that targets http://www.company.com/path/webpage.htm might result in values, as follows:
Method=GET
URI=/path/webpage.htm
Version=HTTP/1.1
Host=www.company.com
Connection=Keep-Alive
Referer=http://www.company.com/path/parentwebpage.htm
The operating system shell might interpret special characters, such as "&", and convert them to alternative text before cbrcontrol evaluates them. If you are entering the command from the dscontrol, cbrcontrol, or a configuration file, use double quotation marks (" ") around the special characters. For example, the following command is valid only when you use the cbrcontrol>> prompt or from a configuration file:
rule add 10.1.203.4@80@cbr_prod_rule_ek type content
  pattern "uri=/nipoek/*"
For this command to work at the operating system prompt when you use special characters, place double quotation marks around the entire command:
cbrcontrol "rule add 10.1.203.4@80@cbr_prod_rule_ek type content
  pattern uri=/nipoek/*"

If the quotation marks are not used, some of the pattern might be truncated when the rule is saved in CBR.

Scenarios and examples for using pattern syntaxes

Scenario 1
The setup for one cluster name involves one set of web servers for standard HTML content, another set of web servers with WebSphere® Application Server for servlet requests, and another set of Lotus® Notes® servers for NSF files. Access to the client data is required to distinguish between those requested pages. It is also required to send them to the appropriate servers. The content pattern matching rules provide the separation that is needed to accomplish these tasks. A series of rules are configured so that the necessary separation of requests occurs automatically. For example, the following commands accomplish the three splits mentioned:
>>rule add cluster1@80@servlets type content pattern "uri=*/servlet/*" priority 1
>>rule uses cluster1@80@servlets server1+server2
>>rule add cluster1@80@notes type content pattern "uri=*.nsf*" priority 2
>>rule uses cluster1@80@notes server3+server4

If a request for an NSF file arrives at Load Balancer, the servlets rule is checked first, but does not match. The request is then checked by the notes rule and returns a match. The client is load-balanced between server3 and server4.

Scenario 2
Another common scenario is when the main website controls several distinct internal groups. For example, www.company.com/software involves a different set of servers and content from www.company.com/hardware division. Because the requests are all based off the root www.company.com cluster, content rules are required to find the URI differences and complete load balancing. The scenario's rule looks similar to the following examples:
>>rule add cluster1@80@div1 type content pattern "uri=/software/*" priority 1
>>rule uses cluster1@80@div1 server1+server2
>>rule add cluster1@80@div2 type content pattern "uri=/hardware/*" priority 2
>>rule uses cluster1@80@div2 server3+server4
Scenario 3
Certain combinations are sensitive to the order in which rules are searched. For example, in Scenario 2, clients were split based on a directory in their request path; however, the target directory might display at multiple levels of the path and mean different things on placement. For example, www.company.com/pcs/fixes/software is a different target from www.company.com/mainframe/fixes/software. Define the rules to account for this possibility and not catch too many scenarios at the same time. For example, the uri=*/software/* test is too broad of a wildcard search in this case. Alternative rules might be structured as follows:
  • A combination search can narrow this search down:
    >>rule add cluster1@80@pcs type content pattern "(uri=/pcs/*)&(uri=*/software/*)"
    >>rule uses cluster 1@80@pcs server1
  • In cases where there are no combinations to use, the order becomes important:
    >>rule add cluster1@80@pc1 type content pattern "uri=/pcs/*"
    >>rule uses cluster1@80@pc1 server2
  • The second rule catches when "pcs" displays in later directory spots instead of the first.
    >>rule add cluster1@80@pc2 type content pattern "uri=/*/pcs/*"
    >>rule uses cluster1@80@pc2 server3
  • In almost every case, you want to complete the rules with a default always true rule to catch anything that falls through the other rules. This rule can also be a "Sorry, the site is currently down, please try again later" server for scenarios where all other servers fail for this client.
    >>rule add cluster1@80@sorry type true priority 100
    >>rule uses cluster1@80@sorry server5
Reference topic    

Terms and conditions for information centers | Feedback

Last updated: April 16, 2014 11:59 AM EDT
File name: rprf_contentsyntax.html