Network Side Scripting - Modifying HTTP requests with Netscaler VPX, F5 BigIP and Zeus Traffic Manager

In a previous post, we discussed how network-side scripting was another way to manage a web-based application, monitoring, debugging and modifying its behavior. Network-side scripting is one of the domains of traffic management devices (what Gartner calls "ADCs"), and in this post, I will compare how a simple problem can be solved using the three leading traffic managers – Citrix's Netscaler VPX, F5’s BigIP Local Traffic Manager and Zeus Traffic Manager.

The challenge – mismatched host headers

When testing load balancing devices, one common problem is that of the mismatched host header. You type in a URL as follows:

• http://IP-address-of-load-balancer/

The load balancer receives the request and forwards it on to the origin web server, and the web server returns a 400 error message because it knows nothing about the website named 'IP-address-of-load-balancer'.

In a production system, you would configure your DNS so that the web site's FQDN resolved to the load balancer's IP address. In testing, you can resolve this by rewriting the request in the load balancer / traffic manager, changing the host header field to match the name of a website the server is hosting (such as www.zeus.com).

Rewriting incoming requests is a good example of one use of network-side scripting. In this example, we will load-balance traffic to the public www.zeus.com site (running on addresses 92.52.65.213 and 92.52.65.222), and we will rewrite the host header to 'www.zeus.com' on all requests we manage.

Citrix Netscaler

This example uses Netscaler VPX Express version 9.1; an identical procedure would be used with the MPX hardware appliances

Netscaler provides a limited network-side scripting capability called "AppExpert". Unlike F5's iRules and Zeus' TrafficScript freeform languages, AppExpert policies have a restricted format; a policy contains one expression, and one action that is performed if the expression evaluates to 'true'. Rules are created in a 'bottom-up' fashion; first create the action, then add the expression to create the policy, then bind it to a virtual server to apply the rule.

Constructing the Rule

The Netscaler actions include INSERT_HTTP_HEADER and DELETE_HTTP_HEADER actions, but no action to change the value of an existing header. Calling INSERT_HTTP_HEADER on the host header (which already exists) has the undesired effect of appending the new value to the existing header value. Consequently, it is necessary to create two policies, one to delete the existing header and one to add the new value, both with an expression of 'TRUE'.

Note: As Chad Tripod, Netscaler Senior SE pointed out in a comment below, the following can also be achieved using Netscaler's CLI. Netscaler's CLI is also illustrated in the following article in this series.

Each of the two policies should be created and bound to the Virtual Server as below:

Create the action (hoping to avoid the inscrutable error messages)

Create the policy: always execute the ‘Set Host Header’ action

Bind the policy to a virtual server

Note that policies that are added later have a lower priority (they run first), so if the policies are added in the order you wish them to run ('Remove', then 'Set') they must be explicitly reordered. Furthermore, by default, if a policy executed successfully, subsequent policies are not evaluated; the 'Goto Expression' must be changed:

This procedure configures the Netscaler to correctly modify the host header to contain the value ‘www.zeus.com’.

F5 BigIP Local Traffic Manager

This example uses F5 BigIP version 9.

F5’s iRules is a TCL-based language that has fine-grained access to the BigIP system and the request it is processing. An iRule is generally composed of one or more snippets of TCL, each associated with one of the 11 different HTTP events (72 events in total) that are triggered by BigIP state machine:

F5 BigIP HTTP state machine

Constructing the Rule

When the BigIP system receives the client request headers (event: HTTP_REQUEST), we wish to invoke the HTTP::header command to replace the value of the Host header:

when HTTP_REQUEST {
	HTTP::header replace Host www.zeus.com
}

iRule rule to modify a Host header

Associate the iRule with the Virtual Server:

Configure your virtual server to run the RewriteHostHeader rule

Note: the virtual server must be configured with the Standard type (not 'FastHTTP' or 'FastL4'), with an 'http'-based profile so that the iRule can perform the HTTP commands.

Zeus Traffic Manager

This example uses Zeus Traffic Manager (previously 'ZXTM') version 5.1.

Zeus' TrafficScript language is a procedural programming language in the style of Perl, PHP or JavaScript. TrafficScript rules are associated with one of two different events – received request, received response – and are automatically suspended and resumed when they perform a blocking operation, such as reading more response data.

Zeus state machine

Zeus Traffic Manager also includes a GUI tool named RuleBuilder for building simple Netscaler-style 'if condition then action' rules.

Constructing the Rule

When the Zeus Traffic Manager system receives the client request headers, we wish to invoke the http.setHeader() function to replace the value of the Host header.

RuleBuilder may be used to create the rule:

RuleBuilder rule to set the Host Header to the value 'www.zeus.com'

Alternatively, the rule may be written in TrafficScript:

http.setHeader( "Host", "www.zeus.com" );

TrafficScript rule to modify a Host header

Configure the Virtual Server to run the rule whenever it receives a request:

TrafficScript rule running on each request

Rules are associated with either the 'Request' or 'Response' event of a Virtual Server.

Observation

All three systems under consideration were able to implement a Network Side Scripting rule to rewrite the host header of an HTTP request. However, there is a marked difference in the efficiency of the approaches.

Netscaler’s strictly guided approach is complicated by the need to create two policies and by the bottom-up approach that requires multiple configuration items to be created, associated and then correctly bound to create the desired rule.

F5's iRules and Zeus' TrafficScript approaches are very similar, and both equally effective at implementing the policy. Zeus' ability to suspend and resume rules when processing network traffic means a large number of F5's 'events' can be simplified to just two in Zeus Traffic Manager.

In the following post, I'll consider a more sophisticated use case for network-side scripting, rewriting HTTP responses to mask sensitive information.

Owen Garrett [Zeus Dev Team] 29 September 2009 3 comments