TrafficScript Rules
This chapter describes TrafficScript rules, including how to create new rules and apply them to your services.
Overview
Some variants of the Virtual Traffic Manager do not support TrafficScript rules or XML capabilities, or have limited support (RuleBuilder only). Full support can be obtained through a software or license key upgrade.
The Virtual Traffic Manager section of the Ivanti Community Web site contains a large amount of examples and documentation describing how to use TrafficScript rules to solve a range of network and application problems. See https://forums.ivanti.com/s/?language=en_US for more information.
You can customize the Virtual Traffic Manager using your own traffic management rules. These rules are created using a scripting language called TrafficScript.
The Virtual Traffic Manager executes TrafficScript rules whenever it receives a new connection or network request, whenever it receives a response from a node, and at the logical completion of a transaction. The rules can inspect the incoming and outgoing data in the connection, and other aspects such as the remote client address.
TrafficScript rules can use regular expressions to search, match, and substitute data. Before using regular expressions in your rules, read and understand the security considerations in Using Regular Expressions.
A TrafficScript rule can modify the request or response (for example, rewriting the URL or headers in an HTTP request), set session persistence parameters, selectively log transactions, or inform the Virtual Traffic Manager how to route the request to the most appropriate pool.
This makes it possible to control precisely how the Virtual Traffic Manager manages your traffic by using rules designed to meet your own hosting requirements.
TrafficScript Example
The following TrafficScript rule can be used with HTTP requests. It handles the request as follows:
- Requests for “www.example.co.uk” are rewritten to “www.example.com”.
- Requests for .jsp pages are routed to a set of application servers (the pool named “JSPServers”).
- Requests for URLs beginning “/secure” are only allowed during office hours.
# Rewrite host header if necessary
if( http.getHostHeader() == "www.example.co.uk" ) {
http.setHeader( "Host", "www.example.com" );
}
$path = http.getPath();
# Give .jsp requests to the "JSPServers" pool
if( string.endsWith( $path, ".jsp" ) ) {
pool.use( "JSPServers" );
}
# Deny access to /secure outside office hours
if( string.startsWith( $path, "/secure" ) ) {
if( sys.time.hour() < 9 || sys.time.hour() >= 18 ) {
connection.discard();
}
}The next rule can be used with HTTP responses. It processes the response as follows:
- If the status code is 404 or 5xx, retry the request a maximum of three times.
- If the response contains references to www.example.co.uk, rewrite it by changing these references to www.example.com.
$code = http.getResponseCode();
if( $code == 404 || $code >= 500 ) {
if( request.getRetries() < 3 ) {
# Avoid the current node when we retry,
# if possible
request.avoidNode( connection.getNode() );
request.retry();
}
}
# We're only going to process text/html responses, so
# break out of the rule if the response is of a
# different type...
if( http.getResponseHeader( "Content-Type" ) != "text/html" ) break;
# getResponseBody automatically de-chunks and uncompresses
# the response if required
$response = http.getResponseBody();
if( string.contains( $response, "www.example.co.uk" ) ) {
$response = string.regexsub( $response, "www.example.co.uk", "www.example.com", "g" );
http.setResponseBody( $response );
}TrafficScript Documentation
The syntax and functions of the TrafficScript language are documented fully in Virtual Traffic Manager: TrafficScript Guide. You can access this guide from the Virtual Traffic Manager product page on the Ivanti Web site at www.ivanti.com.
The TrafficScript edit page also includes a quick reference link to the functions available. To view the reference, click the TrafficScript Reference link when editing a rule.
For a description of how to create rules, see Creating a Rule in the Catalog.
Applications of Rules on the Virtual Traffic Manager
Virtual servers typically use rules to select appropriate pools to handle requests. The rule can inspect any part of the request, possibly modify it, and decide which pool should handle the request.
You can use a rule to dictate session persistence information to a pool. After inspecting the request, the rule can use the connection.setPersistenceKey() function to provide a string to persist on. This string is used by the Universal session persistence method to identify the session the request belongs to.
Rules can be used to check the response from the server and modify it, or even retry the request (if possible) if a transient error was detected.
Rules can override the classes assigned to a connection by the virtual server or the pool. This way, they can specify custom behavior for each connection; connections to a slow resource can be given a longer response time tolerance for example. Classes you can assign in this way include Service Level Monitoring, Session Persistence and Bandwidth Management.
Service Protection classes can use rules. If you have associated a service protection class with your virtual server, it inspects the incoming packets. The class may use a rule to check the packet for a match with known worms or viruses. This rule is executed before the main processing of the virtual server is carried out.
Session persistence and service protection applications of rules are covered in Session Persistence and Service Protection respectively.