Protocol Settings

Use the Virtual Servers > Edit > Protocol Settings page to access advanced settings for managing connections between remote clients and your virtual server. These include the following:

Type	Description
HTTP Settings	Keepalive settings, and whether the Virtual Traffic Manager should include headers in the request, such as “X-Forwarded-For”, “X-Forwarded-Proto”, and “X-Cluster-Client-Ip”.
Cookie Settings	Specifies how the cookies are handled by the Virtual Traffic Manager.
RTSP Specific Settings	Allows user to define a specific range of ports to be used with RTSP (RTSP virtual servers only). For more details, see Real-Time Streaming Protocol.
SIP Settings	Specify how the Virtual Traffic Manager handles SIP traffic (SIP virtual servers only). For more details, see Session Initiation Protocol .
Location Header Settings	Allows URL redirection in case a node replies with a 301 (moved permanently) or 302 (temporary redirect) status code, using an incorrect protocol, hostname or port (HTTP virtual servers only).
FTP Settings	Security settings and port ranges for FTP data connections (FTP virtual servers only).
UDP Settings	Timeouts, and the maximum number of response datagrams expected for one connection (UDP virtual servers only).
Timeout Settings	Timeouts for new and established connections.
Error Handling	Allows the user to define how the virtual server handles errors on connections it processes.
Memory Limits	Maximum buffer sizes for data sent by the client and returned by the server.
TCP Connection Settings	Use max_concurrent_connections to configure the maximum number of concurrent TCP connections allowed by this virtual server. When the configured limit is reached, the Virtual Traffic Manager does not accept new connections to this virtual server until the number of concurrent TCP connections drops below the specified limit. Enable proxy_protocol if the Virtual Traffic Manager should expect connections to be prefixed with a PROXY protocol header. Use TrafficScript to inspect the information contained in the PROXY header. Connections that are not prefixed with a valid PROXY protocol header are discarded. The Virtual Traffic Manager supports PROXY protocol versions 1 and 2. Enable close_with_rst to instruct the Virtual Traffic Manager to close connections from clients with a RST (reset) packet rather than a FIN (finish) packet. This avoids the TIME_WAIT state, which on rare occasions allows wandering duplicated packets to be safely ignored. It also ensures data has been fully received by the peer. Enable this option only if you fully understand the implications of TCP state transition, since TCP connections typically finish with a FIN packet to the peer and an acknowledgment FIN packet in reply. This mechanism allows the sender to be sure the peer has read all the queued data, which cannot happen if the connection is closed with a RST packet. On an unreliable network, data that has been transmitted can in some cases be lost in transit. The purpose of the TIME_WAIT state is to prevent wandering delayed packets from one TCP connection using address <A>:<port P> to address <B>:<port Q> from being accepted by a later TCP connection using the same addresses. In other words, if a duplicate packet from the first connection is delayed in the network and arrives at the second address when its sequence number is in the second connection's window, there is no way for the network stack in the kernel to determine that the delayed packet contains data from the first connection, potentially causing corruption. The kernel increments port numbers in use, so the possibility of this occurring is minimal but not zero. Enable proxy_close to send the client FIN to the back-end server and wait for a server response instead of closing the connection immediately. Enable so_nagle to improve the efficiency of the TCP connection by reducing the number of packets that have to be sent over the network.
Transparent Proxying	To enable transparent proxying for bound sockets on this virtual server, set "transparent" to Yes. In this configuration, a firewall rule can be used to send selected traffic to the virtual server without changing the destination address. In a TrafficScript request rule, you can determine what course of action to take by checking the request's destination IP address or port by using "request.getDestIp" or "request.getDestPort". You can then perform forward proxying to the original destination using "pool.select".

Settings specific to a certain protocol are only shown if the virtual server is managing that protocol.

You do not normally need to change any of these settings. The default values have been chosen to give good performance on a wide range of systems.

MIME Type Auto-Detection

The MIME Type is a component of an HTTP response that describes the type of data in the response – image, HTML page, and so on – so that the client can know how to render or process it.

Some Web servers and Web applications do not correctly set the MIME type response header, and most client software is capable of detecting when this has occurred and auto-detecting the MIME type itself.

In certain circumstances, the Virtual Traffic Manager also needs to know the MIME type of a response. For example, the Virtual Traffic Manager will only attempt to compress certain types of HTTP response data; if the MIME type is missing or incorrectly identified, the Virtual Traffic Manager’s content compression will not operate correctly.

In this situation, click Virtual Servers > Edit > Protocol Settings > HTTP Specific Settings and enable mime!detect to engage MIME Type auto-detection. The Virtual Traffic Manager applies a range of heuristics to deduce the MIME type of the response data; auto-detection takes place when all of the following are true:

There is a response body.

The Content-Type header is missing, or it matches the value of mime!default.

The response is not compressed.

The Virtual Traffic Manager will de-chunk data if necessary, if chunk-transfer encoding was used.

You should only configure MIME Type auto-detection when absolutely necessary, as it will reduce the performance of the Virtual Traffic Manager system.

Location Header Settings

This setting provides rewriting for the most usual URL redirection responses coming from a webserver, that is, 301 (object moved permanently) and 302 (object moved temporarily).

location!regex: enter a regular expression to match the expected response from the node (a 301/302 redirection). You can use generic characters like (.*) to match parts of the expression.

location!replace: enter a regular expression using $1 to $9 to redirect the response to a different object.

location!rewrite: select the desired response in case the response from the node does not match the expression provided in location!regex.

Before using regular expressions, read and understand the security considerations in Using Regular Expressions.

For example, using the following values:

location!regex= (.*)www.example.com/products/(.*)

location!replace= $1products.example.com/$2

If the webserver returns a response such as the following:

HTTP/1.1 302 Moved Temporarily
Location: http://www.example.com/products/hacksaw.htm

The Virtual Traffic Manager rewrites it to:

HTTP/1.1 302 Moved Temporarily
Location: http://products.example.com/hacksaw.htm

Handling Errors

Click Virtual Servers > Edit > Error Logging to enable logging of connection errors encountered by your virtual server.

Connection errors may occur for a variety of reasons:

All of the nodes in the selected pool are unavailable.

The connection with the back-end server timed out and could not be retried (see Retrying Failed Requests).

An SSL protocol error occurred in the server-side or client-side connection.

The back-end server did not return a valid response (for example, a mal-formed HTTP response).

Client connection errors are likely to be due to the actions or behavior of clients, and are mostly not under the control of the Virtual Traffic Manager. Server connection errors relate to the Virtual Traffic Manager to back-end server connection and so are likely to be affected by, and ultimately can be corrected by, the Virtual Traffic Manager and your back-end server configurations.

Generally, connection errors are not logged, unless they relate to errors with the back-end servers that are detected by passive monitoring.

For debugging purposes, it can be very useful to log these errors:

log!client_connection_failures: this setting enables verbose logging of client-connection errors to the error log, or another location if specified by the Event Handling settings in your Virtual Traffic Manager.

log!server_connection_errors: this setting enables verbose logging of server connection errors, and any internal faults in the Virtual Traffic Manager (such as a TrafficScript rule abort because the max_instr limit is exceeded).

log!ssl_failures: this setting enables logging of failures that occur during SSL negotiation with clients and servers.

For more information, see Troubleshooting.

Returning a Custom Error Message

If the Virtual Traffic Manager is unable to obtain a valid response for a request, and the client connection is still alive, it will close the client connection or (for HTTP only) return the following error to the client:

Service Unavailable
The service is temporarily unavailable. Please try again later.

This error message can be replaced, using the contents of a file uploaded to the “conf/extra” resource folder. To select an error file, use the error_file setting on the Virtual Servers > Edit > Protocol Settings > Error Handling page.

Files can be uploaded to the “conf/extra” resource folder using the Catalog > Extra Files > Miscellaneous Files configuration page.

The Virtual Traffic Manager is capable of processing HTTP headers within your error file, regardless of the actual file type, when you wish to set explicit directions on how the file should be handled. For example, you could set the “Content-Type” header if you wish to display a file of a particular type, such as a GIF or JPG image file. In this case, you would append the following lines to the top of your binary file:

Content-Type: image/gif

This capability can be extended to override the HTTP response code, as per the following example:

HTTP/1.1 200 OK

This would force the Virtual Traffic Manager to return the desired code in its response to the client.

It is important to remember to include a blank line after any headers, before the actual content of the file.

Memory Limits for Connections

The Virtual Traffic Manager allows configurable limits on the amount of memory your virtual server can use for each connection:

max_client_buffer: The limit on the amount of data the Virtual Traffic Manager receives from the client (to send to the server) that is buffered. The Virtual Traffic Manager responds differently when the limit is reached, depending on the state of the connection:

If the Virtual Traffic Manager is still reading in HTTP headers, it sends a 413 HTTP error code to the client and logs a warning.

If the Virtual Traffic Manager is still running request rules, it continues buffering and logs a warning.

If the Virtual Traffic Manager has reached the stage of streaming data to the server (request rule processing has finished), it applies flow control. In this scenario the client-side of the connection is paused, so the Virtual Traffic Manager does not read in any more data from the client until it has managed to push some of the buffered data to the server.

max_server_buffer: The limit on the amount of data the Virtual Traffic Manager receives from the server (to send to the client) that is buffered. The Virtual Traffic Manager responds differently when the limit is reached, depending on the state of the connection:

If the Virtual Traffic Manager is still reading in response headers, it sends a 500 HTTP error code to the client and logs a warning.

If the Virtual Traffic Manager is still running response rules, it continues buffering and logs a warning.

If the Virtual Traffic Manager has commenced streaming the response to the client (response rule processing has completed), it applies flow control. In this scenario the server-side of the connection is paused, so the Virtual Traffic Manager does not read in any more data from the server until it has managed to push some of the buffered data to the client.

It is possible for both limits to become active at the same time. If the Virtual Traffic Manager has reached the stage of streaming the request body to the server and the server starts to stream its response body before it has read the complete request body, and if both client and server are quick to send but slow to read, the Virtual Traffic Manager might activate both flow control mechanisms simultaneously.