Request and Response Rules
TrafficScript rules are assigned to a Virtual Server. The Traffic Manager allows a rule to be used as a “request rule”, a “response rule”, or a “transaction completion rule”:
- Request rules are executed when the first request data is received from a client. A request rule can read further data if the client's request is not complete. When the request rules assigned to a virtual Server have finished executing, a connection to a back-end server is made and the request data is streamed to the server.
- Response rules are executed when the first data in the response is read from the back-end server. A response rule can then read further data from the server, and can flush the current data to the client. When the response rules assigned to a Virtual Server have finished executing, the remaining data is streamed to the client.
- Transaction completion rules are applied at the end of the transaction when, for example, the client or server closes the connection, or when the connection times out. In the case of HTTP, RTSP and SIP Virtual Servers, transactions are also considered complete when a full response has been sent to the client, even if the connection is kept alive to handle another request.
Processing Multiple Requests and Responses
If the client sends another request down the same network connection, the Traffic Manager can be configured to run the request and response rules again against this new request. To configure this behavior, use the “run once/run every time” setting for each rule in the Virtual Server configuration. Use request.endsAt() and request.endsWith() to parse persistent connections that contain multiple requests and responses.
The run once/run every time option is not relevant for HTTP connections. Even though a client might send several HTTP requests down the same persistent connection, they are automatically separated into single connections internally.
If you are parsing persistent connections on which the client and server can send data at any point in time in any order, use the “Generic Streaming” Virtual Server type along with request.get() and response.get().
Specialized Protocol Handling Functions
Processing HTTP
The Traffic Manager is fully conversant in the HTTP protocol. On a new HTTP connection, request rules are not started until all the HTTP headers have been received. Specialized TrafficScript functions (such as http.getPath() and http.setHeader()) are available to parse and manipulate the request.
When an HTTP response is received from a back-end server, it does not execute the response rules until it has received all the HTTP headers in the response. Again, specialized TrafficScript functions (such as http.setResponseHeader() and http.setResponseCookie()) are available to manipulate the response.
You cannot use the lower-level connection, request, and response functions such as request.getLine() or response.set() to modify an HTTP request. Use the equivalent specialized HTTP functions instead.
Although multiple HTTP requests can be submitted down a single TCP connection (using keepalives and pipelining), the Traffic Manager transparently separates these requests and handles each individually. For this reason, the option to run rules once or every time is not relevant to HTTP requests.
HTTPS traffic decrypted by the Traffic Manager is handled in exactly the same way. The HTTP payload requests can be inspected and manipulated just as if they were sent in plain text.
Other Specialized Protocols
TrafficScript offers high-level functions for several other protocols, including SIP and RTSP. Always use the high-level functions to read and write request data where possible, rather than lower level functions such as request.get() or response.set().
Processing Other Protocols
The Traffic Manager can handle other protocols (TCP and UDP based) using request.get(), request.set(), response.get(), response.set(), and related functions to read requests.
UDP is a connectionless protocol. To set a UDP response, use the TrafficScript function connection.close( $data, 0 );.