ServerIron ADX Server Load Balancing Guide
Release 12.0.00
June 15, 2009

Table of Contents Previous Next Print


Layer 7 Content Switching > SECTION 1: Advanced Layer 7 Switching Features

SECTION 1: Advanced Layer 7 Switching Features
Advanced L7 content switching allows the ServerIron to make forwarding decisions about HTTP traffic by analyzing information contained within the traffic.
The advanced L7 content switching provides an enhancement over the L7 switching feature available in previous ServerIron ADX releases by allowing you to configure load balancing based on multiple HTTP header fields and XML content. The L7 switching feature available in previous releases is limited to load balancing traffic based on hostname, URL, and cookie fields in the HTTP header.
Specifically, the new L7 content switching feature provides the following functionality:
NOTE: You cannot enable URL switching and L7 content switching simultaneously on the same virtual server.
NOTE: You can define up to 256 CSW policies and up to 512 CSW rules.
To configure L7 content switching, you define content switching rules and policies. A rule specifies the content that the ServerIron ADX looks for in the incoming traffic, and a policy associates rules with one or more actions that specify how the ServerIron ADX handles traffic matching the rule.
The following sections explain how to configure L7 content switching on a ServerIron ADX Chassis device, and how to display information about a L7 content switching configuration.
1.1.1 Enabling CSW
To enable L7 content switching, you bind a content switching policy to a virtual server. For example, to enable L7 content switching on a virtual server called cswVIP, enter commands such as the following
ServerIronADX(config)#server virtual-name-or-ip cswVIP 192.168.20.254
ServerIronADX(config-vs-cswVIP)#port http csw-policy p1
ServerIronADX(config-vs-cswVIP)#port http csw
Syntax: [no] port <portnum> csw-policy <policy-name>
Syntax: [no] port <portnum> csw
NOTE: You cannot enable URL switching and L7 content switching on the same virtual server.
1.1.2 Specifying Scan Depth
To configure actions based on content carried on top of the HTTP protocol (for example, XML content) you must specify how far into the packet the ServerIron ADX scans for the content. The ServerIron ADX scans up to the specified limit. If you do not specify a scan depth, then the ServerIron ADX scans to the end of the packet.
To specify the scan depth for HTTP content, enter commands such as the following:
ServerIronADX(config)#server virtual-name-or-ip cswVIP 192.168.20.254
ServerIronADX(config-vs-cswVIP)#port http csw-scan-depth 128
ServerIronADX(config-vs-cswVIP)#port http csw
Syntax: [no] port <portnum> csw-scan-depth <length>
The <length> specifies the number of bytes the ServerIron ADX scans for content in a packet. You can specify up to 8192 bytes. By default, the ServerIron ADX scans to the end of the packet.
1.2 Defining CSW Rules
This section describes the rules available for L7 content switching. You can define the following types of rules:
HTTP method rules – Cause the ServerIron ADX to make a load balancing decision based on the HTTP method in an incoming packet. See “1.2.1 Configuring an HTTP Method Rule”.
HTTP version rules – Cause the ServerIron ADX to make a load balancing decision based on the HTTP version of an incoming packet. See “1.2.2 Configuring an HTTP Version Rule”.
URL rules – Cause the ServerIron ADX to make a load balancing decision based on the contents of the URL string in an incoming packet. See “1.2.3 URL Rules”.
HTTP header rules – Cause the ServerIron ADX to make a load balancing decision based on the contents of an HTTP header field in an incoming packet. See “1.2.4 HTTP Header Rules”.
XML tag rules – Cause the ServerIron ADX to make a load balancing decision based on the contents of an XML tag in an incoming packet. See “1.2.5 XML Tag Rules”.
In addition, you can combine rules with logical operators AND, OR, and NOT to create nested rules. See “1.2.6 Configuring the Nested Rules”.
1.2.1 Configuring an HTTP Method Rule
To set up an HTTP method rule that causes the ServerIron ADX to make a load balancing decision based on the HTTP method in an incoming packet, enter a command such as the following:
ServerIronADX(config)#csw-rule r1 method eq PUT
This example creates a rule called r1 that matches if an incoming packet contains the PUT method.
Syntax: [no] csw-rule <rule-name> method eq <method-string>
The <rule-name> value can be up to 80 characters in length.
The <method-string> can be OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, or CONNECT.
1.2.2 Configuring an HTTP Version Rule
To set up an HTTP method rule that causes the ServerIron ADX to make a load balancing decision based on the HTTP version of an incoming packet, enter a command such as the following:
ServerIronADX(config)#csw-rule r1 version eq 1.1
This example creates a rule called r1 that matches if an incoming packet uses HTTP version 1.1.
Syntax: [no] csw-rule <rule-name> version eq <http-version>
1.2.3 URL Rules
URL rules cause the ServerIron ADX to make a load balancing decision based on the contents of the URL string in an incoming packet.
Table 5.1 lists the URL rules available for L7 content switching.
 
Matches if a URL string exists in the incoming packet.
Matches if the URL string begins with the specified prefix.
Matches if the URL string ends with the specified suffix.
Matches if the specified pattern exists anywhere within the URL string.
Matches if the URL string is equal to the specified value.
Matches if the URL string contains any one of up to five specified values. This type of rule can be used with the persist action.
csw-rule r1 url search "srvr1"
csw-rule r1 url search "srvr2"
csw-rule r1 url search "srvr3"
csw-rule r1 url search "srvr4"
csw-rule r1 url search "srvr5"
1.2.4 HTTP Header Rules
HTTP header rules cause the ServerIron ADX to make a load balancing decision based on the contents of an HTTP header field in an incoming packet.
In a L7 content switching configuration, you can configure rules for the following HTTP header fields: Connection, Transfer-Encoding, Content-Length, Host, Cookie, Pragma, and Cache-Control, as well as up to 10 other HTTP header fields.
Table 5.2 lists the HTTP header rules available for L7 content switching.
 
HTTP Header Rule Name
Matches if the specified HTTP header field exists in the incoming packet.
[no] csw-rule <rule-name> header <header-name> exists
Matches if the value in the specified HTTP header field begins with the specified prefix.
[no] csw-rule <rule-name> header <header-name> prefix <value>
Matches if the value in the specified HTTP header field ends with the specified suffix.
[no] csw-rule <rule-name> header <header-name> suffix <value>
Matches if the specified pattern exists anywhere within the specified HTTP header field.
[no] csw-rule <rule-name> header <header-name> pattern <value>
Matches if the contents of the specified HTTP header field are equal to the specified value.
[no] csw-rule <rule-name> header <header-name> equals <value>
Matches if the specified HTTP header field contains any one of up to five specified values. This type of rule can be used with the persist action.
[no] csw-rule <rule-name> header <header-name> search <value>
csw-rule r1 header "cookie" search "ServerId1"
csw-rule r1 header "cookie" search "ServerId2"
1.2.5 XML Tag Rules
XML tag rules cause the ServerIron ADX to make a load balancing decision based on the contents of an XML tag in an incoming packet. Rules for up to 200 different XML tags can be specified in a L7 content switching configuration. In a given policy, you can include rules for up to 5 XML tags.
Table 5.3 lists the XML tag rules for L7 content switching.
 
XML Tag Rule Name
XML Tag Exists
Matches if the specified XML tag exists in the incoming packet.
[no] csw-rule <rule-name> xml-tag <tag-name> exists
XML Tag Prefix
Matches if the value in the specified XML tag begins with the specified prefix.
[no] csw-rule <rule-name> xml-tag <tag-name> prefix <value>
XML Tag Suffix
Matches if the value in the specified XML tag ends with the specified suffix.
[no] csw-rule <rule-name> xml-tag <tag-name> suffix <value>
XML Tag Pattern
Matches if the specified pattern exists anywhere within the specified XML tag.
[no] csw-rule <rule-name> xml-tag <tag-name> pattern <value>
XML Tag Equals
Matches if the contents of the specified XML tag are equal to the specified value.
[no] csw-rule <rule-name> xml-tag <tag-name> equals <value>
XML Tag Search
Matches if the specified XML tag contains any one of up to five specified values. This type of rule can be used with the persist action.
[no] csw-rule <rule-name> xml-tag <tag-name> search <value>
1.2.6 Configuring the Nested Rules
You can combine rules with logical operators AND, OR, and NOT to create nested rules. Up to four rules can be combined in a single nested rule.
For example, the following command creates a rule called r1 that combines three other rules: ruleA, ruleB, and ruleC:
ServerIronADX(config)#csw-rule r1 nested "ruleA && (ruleB || (!ruleC))"
The nested rule is matched when an incoming packet matches ruleA, and either matches ruleB or does not match ruleC.
Syntax: [no] csw-rule <rule-name> nested <expression>
Within the <expression>, you can include up to four rules, linked with logical operators. The following logical operators are supported:
&& Logical AND
|| Logical OR
! Logical NOT
A nested rule cannot be specified within the <expression> of another nested rule. The <expression> must refer to more than one rule, unless the ! (logical NOT) operator is used.
1.3 Defining CSW Policies
A policy specifies the action to take when a rule is matched. You can specify the following actions in a policy:
Forward action – Causes the ServerIron ADX to forward packets matching a specified rule to a specified real server or server group. See “1.3.1.1 Configuring the Forward Action”.
Reply-error action – Causes the ServerIron ADX to send a 403 error code page back to the client when the specified rule is matched. See “1.3.1.3 Configuring the Reply-Error Action”.
Log action – Causes the ServerIron ADX to write a message to Syslog when the specified rule is matched. You can optionally customize the format of the Syslog message. See “1.3.1.4 Configuring the Log Action”.
Redirect action – Causes the ServerIron ADX to redirect a request to an alternate domain, URL, or port when the specified rule is matched. See “1.3.1.4 Configuring the Redirect Action”.
Persist action – causes the ServerIron ADX to send requests with similar content to the same server when the specified rule is matched. See “1.3.1.2 Configuring the Persist Action”.
Content-rewrite action – causes the ServerIron ADX to modify an HTTP request or response when a specified rule is matched. See “1.3.1.5 Configuring the Content-Rewrite Action”.
1.3.1 Creating a Policy
To create a policy for L7 content switching, enter a command such as the following:
ServerIronADX(config)#csw-policy policy1
ServerIronADX(config-csw-policy1)#
Syntax: [no] csw-policy <policy-name>
The <policy-name> can be up to 80 characters in length.
1.3.1.1 Configuring the Forward Action
The forward action causes the ServerIron ADX to forward packets matching a specified rule to a specified real server or server group.
For example, the following command specifies that packets matching rule r1 be forwarded to real server 1029:
ServerIronADX(config-csw-policy1)#match r1 forward 1029
Syntax: [no] match <rule-name> forward <id> [cookie-name <name>]
The <rule-name> is the name of a previously configured L7 content switching rule.
The <id> refers to a real server or server group ID. An <id> between 0 and 1023 indicates a server group ID, and an <id> between 1024 and 2047 indicates a real server ID.
If you specify a server group ID, you can optionally specify a cookie name. When you specify a cookie name, the ServerIron ADX performs cookie switching on packets matching the rule, which ensures that packets matching the rule go to the same real server within the server group. See "Configuring Cookie Switching" in the ServerIron ADX for more information.
1.3.1.2 Configuring the Persist Action
The persist action causes the ServerIron ADX to send requests with similar content to the same server when the specified rule is matched. When a rule is matched, the ServerIron ADX uses the content that matched the rule, in combination with a specified persistence method, to select a server or server group to which to send the packet.
When a rule is associated with the persist action, a server or server group is selected as follows:
1.
An incoming packet matches a rule. The persist action can be used in conjunction with the search rules for HTTP headers, URLs, and XML tags. A search rule matches if the specified HTTP header, URL string, or XML tag contains any one of up to five search strings.
For example, you can create a rule that matches if an incoming packet contains a cookie header field with the string "ServerID". The CLI command for this would be:
ServerIronADX(config)#csw-rule r1 header "cookie" search "ServerId"
2.
The ServerIron ADX examines the matched content to determine the persist string. The persist string is the portion of the matched content that the ServerIron ADX uses along with the persist method to calculate a real server or server group to which to send the packet.
For example, for rule r1, defined above, the matched content could be something like the following:
ServerID=1
You can optionally specify that the persist string be a segment of the matched content, starting from a specified offset and lasting for a specified length. In the example above, if you specify an offset of 6 and a length of 4, the persist string would be:
ID=1
3.
The ServerIron ADX uses the persist string along with the configured persist method to select a real server or group. By default, the ServerIron ADX uses a hashing-bucket persist method to select a real server.
The hashing-bucket persist method is illustrated below:
Figure 5.1
You can configure the ServerIron ADX to hash the persist string to a server group ID instead of to a hashing bucket, or as an alternative to the hashing persist methods, you can configure the ServerIron ADX to translate the persist string to a server ID, server group ID, server name, or alias name.
For a given rule, you can configure a primary persist action and a secondary persist action. If the primary persist action does not return a valid persist string, or if the server indicated by the primary persist string is not available, the ServerIron ADX uses the secondary persist action to direct packets to a server.
The following commands configure a rule and policy that use the persist action:
ServerIronADX(config)#csw-rule r1 header host exists
ServerIronADX(config)#csw-policy p1
ServerIronADX(config-csw-p1)#match r1 persist offset 0 length 0
In the example, the csw-rule command creates a rule that matches if an incoming packet contains an HTTP host header field. The csw-policy command creates a policy called p1. The match p1 persist command associates the rule with the persist action. As a result, if an incoming packet has an HTTP host header field, the contents of the host header field are used as the persist string. The ServerIron ADX uses the persist string along with the default hashing-bucket persist method to calculate the real server to which to send the packet.
Syntax: [no] match <rule-name> persist offset <offset> length <length> [[<persist-method>] [secondary]]
or
Syntax: [no] match <rule-name> persist offset <offset> terminator <string> [[<persist-method>] [secondary]]
The <offset> variable specifies the offset in bytes from the beginning of the content matched by the <rule-name> to be used as the persist string. If you specify 0 as the <offset>, the persist string begins at the start of the matched content.
The <length> variable specifies the length in bytes of the persist string. If you specify 0 as the <length>, the persist string ends at the end of the matched content.
The terminator <string> variable specifies the string with which the persist string ends.
The <persist-method> variable specifies which of the following persist methods you want to use:
hash-to-bucket – Hashes the persist string to a hashing bucket, as illustrated in Figure 5.1. This is the default.
hash-to-group-id – Hashes the persist string to a server group ID, instead of to a hashing bucket.
group-or-server-id – Translates the persist string to the ID of a real server or server group.
server-name – Translates the persist string to the name of a real server.
alias-name – Translates the persist string to the name of an alias.
The secondary keyword indicates that this is a secondary persist action for the rule. If the primary persist action does not return a valid persist string, or if the server indicated by the primary persist string is not available, the ServerIron ADX uses the secondary persist action to direct packets to a server.
1.3.1.3 Configuring the Reply-Error Action
The reply-error action causes the ServerIron ADX to send a 403 error code page back to the client when the specified rule is matched.
For example, to cause the ServerIron ADX to send a 403 error code page to a client that sent a packet that matched rule r1, enter the following command:
ServerIronADX(config-csw-policy1)# match r1 reply-error
Syntax: [no] match <rule-name> reply-error
1.3.1.4 Configuring the Log Action
The CSW match log action only logs to a log server, not the local log of the SI (show logging). You must configure a remote server (per the global logging <ip-addr> command) to receive the log.
Syntax: [no] match <rule-name> log [<format>]
By default, the format of the Syslog message is as follows:
<source-ipaddr> <source-port> <protocol> Rule matched, <action-message>
Such as the following:
192.168.9.210 80 HTTP Rule matched, Forward
To cause the ServerIron ADX to write a message to Syslog when rule r1 is matched, enter a command such as the following:
ServerIronADX(config-csw-policy1)# match r1 log
Additionally, you can change the format of the Syslog message using the following tokens:
$SIP – Source IP address
$DIP – Destination IP address
$SPT – Source port
$DPT – Destination port
$HST – Host name
$URL – URL
$RUL – Rule name
$ACT – Action
$CNT – Matched content, such as the matched method, URL, version, or HTTP header
For example, the following command specifies an alternate format for the Syslog message:
ServerIronADX(config-csw-policy1)# match r1 log "$SIP:$SPT->$DIP:$DPT,ru $RUL hit $ACT"
In this example, when a packet matches rule r1, a message such as the following is written to Syslog:
192.168.9.210:80->10.10.10.10:80, ru r1 hit forward
1.3.1.5 Configuring the Content-Rewrite Action
The content-rewrite action causes the ServerIron ADX to modify an HTTP request or response when a specified rule is matched. The content-rewrite action must be used in conjunction with the forward or persist actions. It cannot be configured independently.
The functionality of the content-rewrite action is consistent with that of the cookie insertion and HTTP header insertion features. See "Cookie Insertion" and "HTTP Header Insertion" in the ServerIron ADX for information on configuring these features.
1.3.1.5.1 Inserting a Cookie
You can configure the ServerIron ADX to insert a cookie into an HTTP response when a specified rule is matched. When the rule is matched, a cookie is inserted in the response when any of the following occur:
For example, the following command causes the ServerIron ADX to insert the cookie indicated by the port http cookie-name command into the HTTP response when rule r1 is matched.
ServerIronADX(config-csw-policy1)# match r1 rewrite insert-cookie
Syntax: [no] match <rule-name> rewrite insert-cookie
1.3.1.5.2 Deleting a Cookie
Cookie deletion causes the ServerIron ADX to delete the cookies that it set. The ServerIron removes the cookie from the HTTP request prior to sending the request to the server.
For example, the following command causes the ServerIron ADX to delete the cookie indicated by the port http cookie-name command from the HTTP response when rule r1 is matched:
ServerIronADX(config-csw-policy1)# match r1 rewrite delete-cookie
Syntax: [no] match <rule-name> rewrite delete-cookie
1.3.1.5.3 Damaging a Cookie
Cookie damage consists of altering the cookie header so that it does not contain any cookie that matches the name of the cookie inserted by the ServerIron ADX.
For example, the following command causes the ServerIron ADX to damage the cookie indicated by the port http cookie-name command in the HTTP response when rule r1 is matched.
ServerIronADX(config-csw-policy1)# match r1 rewrite destroy-cookie
Syntax: [no] match <rule-name> rewrite destroy-cookie
1.3.1.5.4 Inserting a HTTP Header
HTTP header insertion causes the ServerIron ADX to insert a header into the HTTP requests it receives on a virtual server or into the HTTP responses it sends out from a virtual server. The header is specified within the CSW match command using the request-insert parameter (for HTTP requests) or the response-insert parameter (for HTTP responses).
To cause the ServerIron ADX to insert a standard HTTP Via: header into HTTP requests matching rule r1, enter the following command:
ServerIronADX(config-csw-p1)# match r1 rewrite request-insert header "Via: ServerIron ADX"
Syntax: [no] match <rule-name> rewrite request-insert header <header>
The <header> variable specifies the string that will inserted.
To cause the ServerIron ADX to insert the header "SI-ADX: proto=HTTP+MMS" into the HTTP responses matching rule r1 it sends from the virtual server, enter the following command:
ServerIronADX(config-csw-policy1)# match r1 rewrite response-insert header "SI-ADX: proto=HTTP+MMS"
Syntax: [no] match <rule-name> rewrite response-insert header <header>
The <header> variable specifies the string that will inserted.
1.3.1.5.5 Inserting an IP Address in a Header
HTTP Header insertion can be used to direct the ServerIron ADX to insert the Client IP address into the HTTP requests it receives on a virtual server that match a CSW rule that you define.
This can be useful in situations where Source Network Address Translation (source NAT) is enabled on a ServerIron ADX. With Source NAT enabled, original source IP addresses are translated into one common IP address. As a result, servers are unable to identify clients by their original source IP addresses. In some cases, the real source IP addresses of the clients may be necessary; for example, for server applications to report statistics, or for web administrators who may need to know the real source IP addresses of the clients in order to secure the system.
You can use the HTTP header insertion feature to insert the original source IP address into the HTTP request. This way, servers are able to identify clients by their original source IP addresses.
To cause the ServerIron ADX to insert the IP address of the connecting client into HTTP requests matching rule r1, enter the following command:
ServerIronADX(config-csw-policy1)# match r1 rewrite request-insert client-ip "MyClientIP"
Syntax: [no] match <rule-name> rewrite request-insert client-ip
1.3.1.5.6 Inserting a Client Certificate into an HTTP Request
HTTP Header insertion can be used to direct the ServerIron ADX to insert a client certificate that you specify into the HTTP requests it receives on a virtual server that match a CSW rule that you define.
The following configuration of CSW policy "p1" directs the ServerIron ADX to insert the entire certificate chain in HTTP requests it receives on a virtual server that match the "r1" CSW rule and to set the prefix header to "SSL":
ServerIronADX(config)# csw-policy p1
ServerIronADX(config-csw-p1)# match r1 rewrite request-insert client-cert entire-chain
ServerIronADX(config-csw-p1)# match r1 rewrite request-insert client-cert cert-header-prefix "SSL"
Syntax: [no] match <rule-name> rewrite request-insert client-cert entire-chain | leaf-cert | wellknown-fields | certheader-prefix <prefix-header>
The entire-chain parameter directs the switch to insert the entire certificate chain. It is in PEM format and BASE64 encoded. The header name is Client-cert. See Table 5.6 for details.
The leaf-cert parameter directs the switch to insert only leaf certificate of the certificate chain. It is in PEM format and BASE64 encoded. The header name is Client-cert. See Table 5.6 for details.
The wellknown-fields parameter directs the switch to insert only the well known fields as described in Table 5.5. They are in ASCII format.
The certheader-prefix parameter directs the switch to set the header prefix of the header listed in Table 5.4 or Table 5.5 to the value specifed by the <prefix-header> variable. For example, if you define the <prefix-header> variable to the well known prefix "SSL", the "Client-Cert" header becomes "SSL-Client-Cert".
Example:
The following example configures the CSW poiicy "p1" to insert the entire certificate chain in HTTP requests it receives on a virtual server and to insert the "SSL" as the certificate header prefix.
ServerIronADX(config)# csw-policy p1
ServerIronADX(config-csw-p1)# match r1 rewrite request-insert header entire-chain
ServerIronADX(config-csw-p1)# match r1 rewrite request-insert header cert-header-prefix "SSL"
 
1.3.1.5.7 Example of Content-Rewrite Action
The following is an example of a rule and a policy that uses the content-rewrite action with a default action:
ServerIronADX(config)# csw-rule r1 header "Cookie" search "ServerID"
ServerIronADX(config)# csw-policy p1
ServerIronADX(config-csw-p1)# match r1 persist offset 0 length 4 group-or-server-id
ServerIronADX(config-csw-p1)# match r1 rewrite destroy-cookie
ServerIronADX(config-csw-p1)# default forward 1
ServerIronADX(config-csw-p1)# default rewrite insert-cookie
ServerIronADX(config)# server virtual-name-or-ip vip1 8.8.8.100
ServerIronADX(config-vs-vip1)# port http
ServerIronADX(config-vs-vip1)# port http cookie-name "ServerID"
ServerIronADX(config-vs-vip1)# port http csw-policy "p1"
ServerIronADX(config-vs-vip1)# port http csw
ServerIronADX(config-vs-vip1)# bind http dns-rs-105 http
 
These commands create a rule that searches for the cookie “Server ID=” within the cookie header of an incoming packet.
NOTE: Under the VIP, you need to configure the same cookie name that is defined in rule r1.
If the ServerID cookie is found in the request and there is only one cookie in the header, then the cookie header is damaged.
if there are multiple cookies in the header, then only the matched cookie is damaged and the request is directed to the server or server group that was indicated by the value of the ServerID cookie.
If no match is found under the p1 policy, the default action is taken. In this configure means forward traffic to one of group 1 server and insert cookie in respond.
A Understanding HTTP URL Rewrite
The HTTP URL Rewrite feature allows the ServerIron to dynamically rewrite URL content in an HTTP request. HTTP URL Rewrite options allow you to insert, delete, and replace URL content at any offset in a HTTP request.
Seamlessly integrated with ServerIron content switching (CSW), HTTP URL Rewrite can be configured as a dependent action for primary CSW actions. However, only Forward and Persists are typically used for HTTP URL Rewrite actions on HTTP requests, because the other actions do not pass requests to servers.
This section explains the HTTP URL Rewrite feature, under the following headings:
B HTTP URL Rewrite Features
Before you configure HTTP URL Rewrite, you should be aware of the following benefits and restrictions for this feature:
C. CSW Topology
Figure 5.2 shows a simple CSW network topology.
Figure 5.2
For the CSW configuration shown in Figure 5.2 the following rules apply:
D. Configuring HTTP URL Rewrite
The following sections describe a full configuration process for HTTP URL Rewite, and a configuration process for HTTP URL Rewrite actions, under the following headings:
Da Configuring HTTP URL Rewrite Example
This section describes how to perform a complete configuration HTTP URL Rewrite, using the content delete option. This scenario uses all of the required steps to configure HTTP URL Rewrite, and identifies the steps that are optional.
The configuration process contains the following segments:
Da.a.1 Create a Policy with HTTP URL Rewrite
To define a CSW rule and create a CSW policy with HTTP URL Rewrite options, follow these steps:
1.
ServerIron(config)# csw-rule r11 url pattern /xyz
Syntax: csw-rule <rule-name> url pattern <url-content>
2.
NOTE: Only one rule is required for configuring HTTP URL Rewrite.
ServerIron(config)#csw-rule r12a header Accept-Charset prefix ISO-
Syntax: csw-rule <rule-name> header <header-content> prefix <prefix-content>
3.
ServerIron(config)#csw-policy mypolicy
Syntax: csw-policy <policy-name>
4.
ServerIron(config-csw-mypolicy)#match r11 forward 1025
Syntax: match <rule-name> forward <server id>
5.
ServerIron(config-csw-mypolicy)#match r11 rewrite request-delete matched-string
Syntax: match <rule-name> rewrite request-delete matched-string
NOTE: The rewrite request-delete matched-string option is an HTTP URL Rewrite action. For more detailed command information, see “rewrite request-delete”.
6.
ServerIron(config-csw-mypolicy)# match r11 log
Syntax: match <rule-name> log
7.
ServerIron(config-csw-mypolicy)# match r12a forward 1025
Syntax: match <rule-name> forward <server id>
8.
ServerIron(config-csw-mypolicy)# match r12a rewrite request-delete offset 4 2
Syntax: match <rule-name> rewrite request-delete offset <offset> <length>
NOTE: rewrite request-delete offset is a HTTP URL Rewrite action.
NOTE: For more information about offsets, see “F. Explanation of Offsets”.
9.
ServerIron(config-csw-mypolicy)# default forward 1026
Syntax: default forward <server id>
D.a.a.2 Configure Real and Virtual Servers
To configure the real and virtual servers, follow these steps:
1.
ServerIron(config)# server real web1 1.1.1.1
Syntax: server real <real-server> <ip-address>
2.
ServerIron(config-rs-web1)# port http
Syntax: port http
3.
ServerIron(config-rs-web1)# server real web2 1.1.1.2
Syntax: server real <vip-name> <ip-address>
4.
ServerIron(config-rs-web2)# port http
ServerIron(config-rs-web2)# exit
Syntax: port http
Syntax: exit
5.
ServerIron(config)#server virtual-name-or-ip csw-vip 1.1.1.100
Syntax: server virtual-name-or-ip <vip-name> <ip-address>
6.
Define a virtual HTTP port on the virtual server.
ServerIron(config-vs-csw-vip)#port http
Syntax: port http
7.
ServerIron(config-vs-csw-vip)# bind http web1 http web2 http
Syntax: bind http <real-server> http <vip-name>
D.a.a.3 Enable Content Switching
To enable content switching, follow these steps:
1.
ServerIron(config-vs-csw-vip)#port http csw-policy mypolicy
Syntax: port http csw-policy <policy-name>
2.
ServerIron(config-vs-csw-vip)#port http csw
Syntax: port http csw
D.a.a.4 HTTP URL Rewrite Configuration Summary
The following example shows a summary of the configuration steps:
#csw-rule r11 url pattern /xyz
#csw-rule r12a header Accept-Charset prefix ISO-
 
#csw-policy mypolicy
#match r11 forward 1025
#match r11 rewrite request-delete matched-string
#match r11 log
#match r12a forward 1025
#match r12a rewrite request-delete offset 4 2
#default forward 1026
 
#server real web1 1.1.1.1
#port http
#server real web2 1.1.1.2
#port http
 
#server virtual-name-or-ip csw-vip 1.1.1.100
#port http
#port http csw-policy mypolicy
#port http csw
#bind http web1 http web2 http
D.b Configuring HTTP URL Rewrite Actions
This section describes the following configuration procedures:
D.b.1 Configuring Rewrite Request-Delete
HTTP URL Rewrite allows the ServerIron to delete a string or portion of a string from inside the incoming client request. The following options are described:
Delete Matched-String
To configure a request to delete a matched string in a CSW rule, follow these steps:
1.
ServerIron(config)#csw-rule r11 url pattern "-sample"
Syntax: csw-rule <rule-name> url pattern <url-content>
2.
ServerIron(config)#csw-policy mypolicy
Syntax: csw-policy <policy-name>
3.
ServerIron(config-csw-mypolicy)#match r11 forward 1025
Syntax: match <rule-name> forward <server-id>
4.
ServerIron(config-csw-mypolicy)#match r11 rewrite request-delete matched-string
Syntax: match <rule-name> rewrite request-delete matched-string
5.
ServerIron(config-csw-mypolicy)#match r11 log
Syntax: match <rule-name> log
6.
ServerIron(config-csw-mypolicy)#default forward 1026
Syntax: default forward <server-id>
NOTE: The following section assumes you have already completed the previous configuration.
If the ServerIron were to receive a request for URL /abc/xyz-sample/index.html, it would take the following actions:
In this case, "-sample" is the deleted string that CSW rule r11 matches. The request is forwarded to the server with server ID 1025, which is defined by primary CSW action match r11 forward 1025. The highlighted URLs in the following two HTTP request messages show the difference between the original request and the rewritten request.
If there is no sub-string "-sample" in the URL of the HTTP request, rule r11 is not hit, the request is sent to the server with server ID of 1026, which is defined by the default rule default forward 1026.
EXAMPLE: Original HTTP Request
GET /abc/xyz-sample/index.html HTTP/1.1\r\n
Host: www.foo.com\r\n
User-Agent: Mozilla/5.0 Netscape/7.02\r\n
Accept-Charset: ISO-8859-1\r\n
Cookie: name=foundrynet; userid=12345\r\n
\r\n
EXAMPLE: Rewritten HTTP Request
GET /abc/xyz/index.html HTTP/1.1\r\n
Host: www.foo.com\r\n
User-Agent: Mozilla/5.0 Netscape/7.02\r\n
Accept-Charset: ISO-8859-1\r\n
Cookie: name=foundrynet; userid=12345\r\n
\r\n
Delete Content at Positive Offset
NOTE: For more information about offsets, see “F. Explanation of Offsets”.
To configure a request to delete content at a positive offset, follow these steps:
1.
ServerIron(config)#csw-rule r12a url prefix "/abc"
Syntax: csw-rule <rule-name> url prefix <prefix-content>
2.
ServerIron(config)#csw-policy mypolicy
Syntax: csw-policy <policy-name>
3.
ServerIron(config-csw-mypolicy)#match r12a forward 1025
Syntax: match <rule-name> forward <server-id>
4.
ServerIron(config-csw-mypolicy)#match r12a rewrite request-delete offset 4 2
Syntax: match <rule-name> rewrite request-delete offset <offset> <length>
NOTE: The following section assumes you have already completed the previous configuration.
The URL prefix "/abc" is matched, offset 0 is at the second "/", which is right after the matched prefix "/abc" in the URL, which is defined in CSW "r12a"; so offset 4 is number "1" which is 4 byte away after the letter "c". The result is that 2 byte "12" is deleted in URL.
EXAMPLE: Original HTTP Request
GET /abc/xyz12/index.html HTTP/1.1\r\n
Host: www.foo.com\r\n
User-Agent: Mozilla/5.0 Netscape/7.02\r\n
Accept-Charset: ISO-8859-1\r\n
Cookie: name=foundrynet; userid=12345\r\n
\r\n
EXAMPLE: Rewritten HTTP Request
GET /abc/xyz/index.html HTTP/1.1\r\n
Host: www.foo.com\r\n
User-Agent: Mozilla/5.0 Netscape/7.02\r\n
Accept-Charset: ISO-8859-1\r\n
Cookie: name=foundrynet; userid=12345\r\n
\r\n
Delete Content at Negative Offset
NOTE: For more information about offsets, see “F. Explanation of Offsets”.
To configure a request to delete content at a negative offset, follow these steps:
1.
ServerIron(config)#csw-rule r12b url suffix ".html"
Syntax: csw-rule <rule-name> url suffix <content>
2.
ServerIron(config)#csw-policy mypolicy
Syntax: csw-policy <policy-name>
3.
ServerIron(config-csw-mypolicy)#match r12b forward 1025
Syntax: match <rule-name> forward <server-id>
4.
ServerIron(config-csw-mypolicy)#match r12b rewrite request-delete neg-offset 11 6
Syntax: match <rule-name> rewrite request-delete neg-offset <offset> <length>
NOTE: The following section assumes you have configured the scenario above.
When ".html" is matched, offset 0 is white space after letter "l", letter "l" is neg-offset 1, letter "m" is neg-offset 2, letter "t" is neg-offset 3 and so on; neg-offset 11 is "_". Count 6 byte from left to right starting with "_", you can see "_index" is to be deleted.
EXAMPLE: Original HTTP Request
GET /abc/xyz/defult_index.html HTTP/1.1\r\n
Host: www.foo.com\r\n
User-Agent: Mozilla/5.0 Netscape/7.02\r\n
Accept-Charset: ISO-8859-1\r\n
Cookie: name=foundrynet; userid=12345\r\n
\r\n
EXAMPLE: Rewritten HTTP Request
GET /abc/xyz/default.html HTTP/1.1\r\n
Host: www.foo.com\r\n
User-Agent: Mozilla/5.0 Netscape/7.02\r\n
Accept-Charset: ISO-8859-1\r\n
Cookie: name=foundrynet; userid=12345\r\n
\r\n
Delete String
NOTE: For more information about offsets, see “F. Explanation of Offsets”.
To configure a request to delete a sub-string in a CSW rule, follow these steps:
1.
ServerIron(config)#csw-rule r13 url exists
Syntax: csw-rule <rule-name> url exists
2.
ServerIron(config)#csw-policy mypolicy
Syntax: csw-policy <policy-name>
3.
ServerIron(config-csw-mypolicy)#match r13 forward 1025
Syntax: match <rule-name> forward <server-id>
4.
ServerIron(config-csw-mypolicy)#match r13 rewrite request-delete string "123"
Syntax: match <rule-name> rewrite request-delete string <string-content>
NOTE: The following section assumes you have already completed the previous configuration.
The url exist matches any url. If it exists in the request, search for "123" in url. if found, only delete "123"; if no "123" is found in the url, the original url is sent to the server.
EXAMPLE: Original HTTP request:
GET /abc/xyz123/index.html HTTP/1.1\r\n
Host: www.foo.com\r\n
User-Agent: Netscape/7.02\r\n
Accept-Charset: ISO-8859-1\r\n
Cookie: name=foundrynet; userid=12345\r\n
\r\n
EXAMPLE: Rewritten HTTP request:
GET /abc/xyz/index.html HTTP/1.1\r\n
Host: www.foo.com\r\n
User-Agent: Netscape/7.02\r\n
Accept-Charset: ISO-8859-1\r\n
Cookie: name=foundrynet; userid=12345\r\n
\r\n
D.b.2 Configuring Rewrite Request-Insert
Content insertion allows ServerIron to insert any string either right after the matched string found by the CSW rule, or at any specified offset in the content located by the matched CSW rule. Use the following procedures to configure a string insert at a positive offset or a negative offset.
NOTE: For more information about offsets, see “F. Explanation of Offsets”.
Insert String at Positive Offset
To configure a request to insert a string after a CSW rule match, follow these steps:
1.
ServerIron(config)#csw-rule r21 url prefix "/abc"
Syntax: csw-rule <rule-name> url prefix <prefix-content>
2.
ServerIron(config)#csw-policy mypolicy
Syntax: csw-policy <policy-name>
3.
ServerIron(config-csw-mypolicy)#match r21 forward 1025
Syntax: match <rule-name> forward <server-id>
4.
ServerIron(config-csw-mypolicy)#match r21 rewrite request-insert /hello-world
Syntax: match <rule-name> rewrite request-insert <content> <offset>
NOTE: The following section assumes you have already completed the previous configuration.
NOTE: If no offset is defined, the ServerIron will always insert at offset 0.
Offset 0 is at the second "/", which is right after matched prefix "/abc", which is defined in CSW "r21". The result is that string "/hello-world" is inserted at the default offset 0, which is after letter "c". The original URL becomes "/abc/hello-world/xyz/index.html".
The highlighted URLs in the following two HTTP request messages show the difference between the original request and the one after being rewritten.
EXAMPLE: Original HTTP request:
GET /abc/xyz/index.html HTTP/1.1\r\n
Host: www.foo.com\r\n
User-Agent: Mozilla/5.0 Netscape/7.02\r\n
Accept-Charset: ISO-8859-1\r\n
Cookie: name=foundrynet; userid=12345\r\n
\r\n
EXAMPLE: Rewritten HTTP request:
GET /abc/hello-world/xyz/index.html HTTP/1.1\r\n
Host: www.foo.com\r\n
User-Agent: Mozilla/5.0 Netscape/7.02\r\n
Accept-Charset: ISO-8859-1\r\n
Cookie: name=foundrynet; userid=12345\r\n
\r\n
Insert String at Negative Offset
To configure a request to insert a string after a CSW rule match, follow these steps:
1.
ServerIron(config)#csw-rule r22 url prefix /abc/
Syntax: csw-rule <rule-name> url prefix <prefix-content>
2.
ServerIron(config)#csw-policy mypolicy
Syntax: csw-policy <policy-name>
3.
ServerIron(config-csw-mypolicy)#match r22 forward 1025
Syntax: match <rule-name> forward <server-id>
4.
ServerIron(config-csw-mypolicy)#match r22 rewrite request-insert /hello-world neg-offset 5
Syntax: match <rule-name> rewrite request-insert <content> neg-offset <offset>
NOTE: The following section assumes you have already completed the previous configuration.
NOTE: If you want to insert a string at the beginning of a URL, make sure that the string always starts with a "/", or the server that recieves the request returns a response of "bad request." This response indicates the format is invalid. The assumption is that the URL always starts with a "/".
The highlighted URLs in the following two HTTP request messages show the difference between the original request and the rewritten request. Offset 0 is at the first "x", which is right after the matched prefix "/ abc/", which is defined in CSW "r22". So negative offset 5 is at the first "/", which is 5 bytes away before the "x". The result is that string "/hello-world" is inserted at the first "/", which is the beginning of URL "/abc/xyz/index.html". The original URL becomes "/hello-world/abc/xyz/index.html".
EXAMPLE: Original HTTP request:
GET /abc/xyz/index.html HTTP/1.1\r\n
Host: www.fool.com\r\n
User-Agent: Mozilla/5.0 Netscape/7.02\r\n
Accept-Charset: ISO-8859-1\r\n
Cookie: name=foundrynet; userid=12345\r\n
\r\n
EXAMPLE: Rewritten HTTP request:
GET /hello-world/abc/xyz/index.html HTTP/1.1\r\n
Host: www.foo.com\r\n
User-Agent: Mozilla/5.0 Netscape/7.02\r\n
Accept-Charset: ISO-8859-1\r\n
Cookie: name=foundrynet; userid=12345\r\n
\r\n
NOTE: When inserting a string in an HTTP request, make sure the negative offset is correctly specified. Incorrectly specifying the negative offset (out of range) may result in an improper HTTP request..
D.b.3 Configuring Rewrite Request-Replace
Content replacement allows you to replace a defined string, or a string that matches a CSW rule. The following procedures explain both methods.
Replace a String Defined by Content Rule
To configure a request to replace a string that matches a CSW rule, follow these steps:
1.
ServerIron(config)#csw-rule r31 url exist
Syntax: csw-rule <rule-name> url exist
2.
ServerIron(config)#csw-policy mypolicy
Syntax: csw-policy <policy-name>
3.
ServerIron(config-csw-mypolicy)#match r31 forward 1025
Syntax: match <rule-name> forward <server-id>
4.
ServerIron(config-csw-mypolicy)#match r31 rewrite request-replace matched-string "/newabc/newxyz/newindex.html"
Syntax: match <rule-name> rewrite request-replace matched-string <new-string>
<rule-name> —defines the name of CSW rule.
matched-string—the matched string (defined by CSW rule), which is to be replaced.
<new-string>— defines the new string that replaces the previous string.
NOTE: The following section assumes you have already completed the previous configuration.
The url exist matches the entire url. So the matched string is whole url "/abc/xyz/index.html". It is replaced by new string "/newabc/newxyz/newindex.html".
EXAMPLE: Original HTTP request:
GET /abc/xyz/index.html HTTP/1.1\r\n
Host: www.fool.com\r\n
User-Agent: Mozilla/5.0 Netscape/7.02\r\n
Accept-Charset: ISO-8859-1\r\n
Cookie: name=foundrynet; userid=12345\r\n
\r\n
EXAMPLE: Rewritten HTTP request:
GET /newabc/newxyz/newindex.html HTTP/1.1\r\n
Host: www.fool.com\r\n
User-Agent: Mozilla/5.0 Netscape/7.02\r\n
Accept-Charset: ISO-8859-1\r\n
Cookie: name=foundrynet; userid=12345\r\n
\r\n
Replace a Defined String
To configure a request to replace a specific string in a CSW rule match, follow these steps:
1.
ServerIron(config)#csw-rule r32 url pattern "abc"
Syntax: csw-rule <rule-name> url pattern <pattern-content>
2.
ServerIron(config)#csw-policy mypolicy
Syntax: csw-policy <policy-name>
3.
ServerIron(config-csw-mypolicy)#match r32 forward 1025
Syntax: match <rule-name> forward <server-id>
4.
ServerIron(config-csw-mypolicy)#match r32 rewrite request-replace string "xyz" "1234"
Syntax: match <rule-name> rewrite request-replace string <old-string> <new-string>
The <rule-name> variable defines the name of CSW rule.
The <old-string> variable defines the string to be replaced, if it can be found in the URLdefined by the CSW rule. If the <old-string> variable is not found, the replacement will not be happen.
The <new-string> variable defines the string with which to be replaced.
NOTE: The following section assumes you have already completed the previous configuration.
Because url contains pattern "abc", rule r32 will be hit, then search for string "xyz" also found, so "xyz" will be replaced with string "1234". The following two HTTP request messages show the difference between the original request and the one after being rewritten.
EXAMPLE: Original HTTP Request
GET /abc/xyz/index.html HTTP/1.1\r\n
Host: www.fool.com\r\n
User-Agent: Netscape/7.02\r\n
Accept-Charset: ISO-8859-1\r\n
Cookie: name=foundrynet; userid=12345\r\n
\r\n
EXAMPLE: Rewritten HTTP Request
GET /abc/1234/index.html HTTP/1.1\r\n
Host: www.fool.com\r\n
User-Agent: Netscape/7.02\r\n
Accept-Charset: ISO-8859-1\r\n
Cookie: name=foundrynet; userid=12345\r\n
\r\n
E HTTP URL Rewrite Command Reference
This section describes the following HTTP URL Rewrite options:
rewrite request-delete
Use the rewrite request-delete option in the CSW policy configuration mode to delete content, as shown in the following:
ServerIronADX(config-csw-mypolicy)#match r11 rewrite request-delete offset 4 2
Syntax: match <rule-name> rewrite request-delete {matched-string | neg-offset <offset> <length> | offset <offset> <length> | string <ASCII string>}
The matched-string parameter specifies the matched-string option for the request to delete a string defined by a rule.
The neg-offset parameter specifies the negative-offset option for the delete request as defined by the followng variables:
The <offset> variable is the value of the deletion offset.
The <length> variable is the value of the length of content to be deleted.
The offset parameter specifies the positive-offset option for the delete request as defined by the following variables:
The <offset> variable is the value of the deletion offset.
The <length> variable is the value of the length of content to be deleted.
The string parameter specifies the string option for the delete request as specified by the following variable:
The <ASCII string> variable is the value of the string to be deleted.
rewrite request-insert
Use the rewrite request-insert option in the CSW policy configuration mode to insert content, as shown in the following:
ServerIronADX(config-csw-mypolicy)# match r11 rewrite request-insert abc offset 4
Syntax: match <rule-name> rewrite request-insert {[<ASCii-string> [neg-offset <DECIMAL> | offset <DECIMAL>]] | client-ip | header}
The <ASCII-string> variable specifies the value of the string for the offset options in the insert request (described in the following).
The neg-offset parameter specifies the negative offset option for the insert request as the value specified in the <DECIMAL> variable.
The offset paraqmeter specifies the positive offset option for the insert request as the value specified in the <DECIMAL> variable.
The client-ip parameter specifies client-ip option for the insert request.
NOTE: The value of the client-ip must be defined under the VIP command.
The header parameter specifies header option for the insert request.
NOTE: The value of the header must be defined under the VIP command.
rewrite request-replace
Use this option in the CSW policy configuration mode to replace content, as shown in the following:
ServerIronADX(config-csw-mypolicy)#match r11 rewrite request-replace matched-string
Syntax: match <rule-name> rewrite request-replace {matched-string <ASCII string> | string <ASCIIstring-old> <ASCIIstring-new>}
The matched-string parameter specifies the matched-string option for the request to replace a string defined by a rule the is specifed by the <ASCII string> variable.
The string parameter specifies that a string defined by the <ASCIIstring-old> variable must be replaced by a string of the <ASCIIstring-old> variable.
F. Explanation of Offsets
NOTE: The offset or neg-offset keyword indicates that insertion or deletion starts after or before the offset of the interested content defined in the matched CSW rule.
In this example, the ServerIron receives the following message:
GET /abc/xyz/index.html HTTP/1.1\r\n
Host: www.foo.com\r\n
User-Agent: Mozilla/5.0 Netscape/7.02\r\n
Accept-Charset: ISO-8859-1\r\n
Cookie: name=foundrynet; userid=12345\r\n
\r\n
The following examples show how the offsets work for various rules:
Prefix Matching
Offset 0 points to "y", which is the next byte after "/abc/x" in the URL.
Suffix Matching
Offset 0 points to "\r", which is the next byte after "com" in the value of "Host" header "www.foo.com".
Pattern Matching
Offset 0 points to "c", which is the next byte after "foo." in the value of "Host" header "www.foo.com".
Exist Matching
Offset 0 points to white space at end of letter "l", which is right after the last byte of URL "/abc/xyz/index.html".
Equal Matching
Offset 0 points to "\r", which is the next byte after "www.foo.com" in the value of "Host" header, "www.foo.com".
G. Displaying the Statistics for All HTTP Content Rewrites
You can use the show l7-rewrite-info command to display the statistics for all HTTP content rewrites. Using this command on the Management Processor (MP) shows the results of all HTTP content rewrites for both the MP and the BPs. Using this command on a BP (the web switching CPU) shows the results for the BP only.
To display the statistics for all HTTP content rewrites, enter the command such as the following:
Syntax: show l7-rewrite-info
Table 5.6 defines the fields shown in the screen display.
Table 5.6: L7 Rewrite Information  
Usage Guidelines
When you define an offset or negative offset value to insert or delete a string, the value is not allowed to go beyond the URL value defined by the associated CSW rule. If it does exceed the boundry of the URL value, the ServerIron adjusts it to align with the beginning or the end of the URL.
Similarly, the deletion action is not allowed to delete content beyond the URL value defined by its associated CSW rule. If the string to be deleted does exceed the start or end of the boundary of the URL or header value content, ServerIron limits the string to be deleted to the part within the boundary.
Syntax: match <rule-name> rewrite request-insert <string> [offset | neg-offset <offset>]
The <rule-name> variable defines the name of CSW rule.
The <string> variable defines the string to be inserted.
The <offset> variable defines the distance of bytes from the offset 0. By default, offset 0 is right after the interested string defined by matched CSW rule.
Key word offset or neg-offset—indicates that the insertion offset starting after or before the offset 0.
1.3.2 Case-Insensitive Match for Content Switching
With Case-Insensitive Match for content switch (csw) you can optionally specify a csw-rule or csw-policy to be case insensitive and the consequent match ignores case for the input.
The following example shows how to configure a case-insensitive rule:
ServerIronADX(config)#csw-rule r1 url pattern /test/index.html case-insensitive
Syntax: csw-rule <rule-name> url | header | method | xml-tag pattern <pattern-to-match> case-insensitive
The optional case-insensitive keyword specifies the pattern match to be case insensitive.
The following example shows how to configure a case-insensitive policy:
ServerIronADX(config)#csw-policy p1 case-insensitive
Syntax: csw-policy <policy-name> case-insensitive
The optional case-insensitive keyword specify this policy is case-insensitive.
NOTE: You cannot mix case insensitive policy and case sensitive rules and vice verse.
1.3.3 Wildcards in CSW Rules for URL Prefixes
Wildcards in CSW rules for URL prefixes behave as described for the following CSW rule:
csw-rule "pages0" url prefix "/pages/0*"
In this case, "/pages/0*" does not match on " /pages/0". It would only match on URLs such as "/pages/01" and "/pages/011119011", where the URL is at least one byte longer that the part of the rule before the asterisk.
1.3.1.4 Configuring the Redirect Action
The redirect action causes the ServerIron ADX to redirect a request to an alternate domain, URL, port, or Uniform Resource Identifier (URI) when the specified rule is matched.
For example, the following command causes the ServerIron ADX to redirect a request to the domain fdry.com, URL
/home/index.html, and port 8080 when rule r1 is matched.
ServerIronADX(config-csw-policy1)#match r1 redirect "fdry.com" "/home/index.html" 8080
Syntax: [no] match <rule-name> redirect <domain> [<url> | [<port> <status-code>] | [<url> <new-port>]]
The <rule-name> variable can be up to 80 characters in length.
The <domain> variable can be up to 255 characters.
The <url> variable can be up to 255 characaters.
You can optionally specify * (asterisk) for either the <domain> or <url>. When you do this, the redirected request uses the same domain or URL as in the original request.
For the <port> parameter, you can enter any well-known port name or port number. For <status-code>, enter any three-digit status code.
For <url> <new-port>, enter the new URL and port number to which the request will be redirected.
HTTP Redirect Status Code
Prior to release 11.0.00, ServerIron ADX uses status code 302 with redirect messages. The code 302 indicates a temporary move. Beginning with release 11.0.00, ServerIron ADX can be configured to use status code 301, which indicates permenant move, to suit different application requirements.
To redirect an HTTP request with redirect code 301, entre the following command:
ServerIronADX(config)#csw-policy p1
ServerIronADX(config-csw-p1)#match r1 redirect "fdry.com" HTTP 301
1.3.1.5 Support for Large Get Requests
ServerIron ADX will be able perform Layer 7 Content Switching on large-sized GET requests (up to 20,000 bytes). Earlier release supported up to 8,000 byte GET requests.
1.4 Displaying CSW Information
This section contains the following sections:
1.4.1 Displaying Header Information
To display information about the HTTP headers encountered in a L7 content switching configuration, enter the following command:
Syntax: show csw-hdr-info
The following table describes the information displayed by the show csw-hdr-info command.
 
1.4.2 Displaying CSW Rule Information
To display information about the L7 content switching rules configured on the device, enter the following command:
Syntax: show csw-rule [<rule-name>]
The following table describes the information displayed by the show csw-rule command.
 
To display detailed information for a specified rule, enter a command such as the following:
Syntax: show csw-rule <rule-name> detail
The following table describes the information displayed by the show csw-rule detail command.
 
1.4.3 Displaying CSW Policy Information
To display information about a L7 content switching policy, enter the following command on the BP:
Syntax: show csw-policy server-sw
 
To display detailed information about a policy, enter a command such as the following:
Syntax: show csw-policy <policy-name> detail
In addition to the information shown in Table 5.10, the show csw-policy detail command displays the following information:
 
2.2 Enabling HTTP Redirect
You can enable the HTTP redirect feature in a virtual server and instructs ServerIron ADX to use the message "HTTP/1.0 301 Moved Permanently" as a response to the client. Otherwise, if the HTTP redirect is enabled, ServerIron ADX sends the message "HTTP/1/1 301 Moved Permanently" as a response to the client.
To enable the HTTP redirec, enter the following command:
ServerIronADX(config)# server http-redirect-1.0
Syntax: [no] server http-redirect-1.0
3.8 HTTP Status Codes
The ServerIron ADX can perform HTTP health checks for TCS and SLB implementations. The ServerIron ADX makes a determination about the health of the HTTP service on a real server based on its response to an HTTP GET or HEAD request.
If the real server responds before the HTTP keepalive interval expires, the ServerIron ADX assumes that the HTTP service on that real server is alright and marks the service ACTIVE.
However, if the real server responds with an HTTP reply status code less than 200 or greater than 299 (for SLB) or less than 200 or greater than 499 (for TCS), the ServerIron ADX marks the HTTP service on the real server FAILED.
If the real server does not respond, the ServerIron ADX retries the request up to the number of times specified by the HTTP retries parameter. If the real server’s HTTP service still does not respond, the ServerIron ADX marks the service FAILED for that server.
NOTE: You can change the status code ranges. See “Changing HTTP Keepalive Method, Value, and Status Codes”.
 
Table 5.12 lists the standard HTTP status codes.
 
Table 5.12: HTTP Status Codes
100 199
200 299
300 399
400 499
500 599

Layer 7 Content Switching > SECTION 1: Advanced Layer 7 Switching Features

Table of Contents Previous Next Print
Copyright © 2009 Brocade Communications Systems, Inc.