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