Applies To:

Show Versions Show Versions

Manual Chapter: BIG-IP version 9.2 Configuration Guide for Local Traffic Management: Managing HTTP and FTP Traffic
Manual Chapter
Table of Contents   |   << Previous Chapter   |   Next Chapter >>


6

Managing HTTP and FTP Traffic


Introducing HTTP and FTP traffic management

The BIG-IP® local traffic management (LTM) system offers several features that you can use to intelligently control your HTTP, HTTPS, and FTP traffic. Examples of these features are the insertion of headers into HTTP requests and the compression of HTTP server responses.

These features are available through configuration of an HTTP or an FTP profile. A profile is a group of settings, with values, that corresponds to a specific type of traffic, such as HTTP traffic. A profile defines the way that you want the LTM system to manage that traffic type.

In addition to HTTP and FTP profiles, the LTM system includes other features to help you manage your application traffic, such as health monitors for checking the health of HTTP and FTP services, and iRulesTM for querying or manipulating HTTP header or content data.

Note

In addition to the HTTP profile, there is another type of HTTP profile called a FastHTTP profile. The use of a FastHTTP profile is incompatible with the use of an HTTP profile. For more information on the FastHTTP profile, see Chapter 5, Understanding Profiles .

Table 6.1 summarizes the capabilities within the LTM system for managing HTTP and FTP traffic and shows the LTM object that you configure to implement each feature.

 


Table 6.1 Summary of the LTM system features related to HTTP and FTP traffic control
Feature
Description
Configuration Object
HTTP compression
You can create an HTTP profile that causes the LTM system to compress server responses using well-defined algorithms such as gzip and deflate.
HTTP profile
Monitoring of HTTP, HTTPS, and FTP ports on pool members
You can associate an HTTP, HTTPS, or FTP monitor with the members of a pool to ensure that pool members are ready and able to receive traffic on specific ports.
Load balancing pool

HTTP, HTTPS, and FTP health monitors
Header insertion and deletion
You can insert headers into HTTP requests, or delete content from HTTP headers.
HTTP profile and iRule
Session persistence
You can ensure that HTTP sessions persist to the same pool member across connections.
Persistence profile and iRule
Header and content inspection and modification
By writing an iRule, users can inspect or modify the content of an HTTP request or response.
iRule
Redirection of HTTP requests
By configuring an HTTP profile or writing an iRule, you can instruct the LTM system to redirect HTTP traffic based on URI, status code, or content.
HTTP Profile and iRule
Pooling connections
You can configure the LTM system so that multiple client connections can reuse the same idle server-side connection. You can also configure the LTM system to rewrite the HTTP connection headers to ensure that a connection stays open.
OneConnect profile
Chunking of requests and responses
You can configure the LTM system to unchunk or rechunk HTTP responses.
HTTP profile
Pipelining
The LM system supports HTTP pipelining.
HTTP profile
IPV4-to-IPV6 compatibility
Ensures compatibility between IP version 4 and IP version 6 clients and servers when using the FTP protocol.
FTP profile

 

Configuring HTTP profile settings

You can configure HTTP profile settings to ensure that HTTP traffic management suits your specific needs. These configuration settings are organized into several categories on the New HTTP Profile screen in the Configuration utility: General Properties, Settings, Compression, and RAM Cache. You can configure these settings when you create a profile, or after profile creation by modifying the profile's settings. For specific procedures on configuring a profile, see Chapter 5, Understanding Profiles .

For the profile settings that appear in the Properties and Settings areas of the HTTP Profile screen, you can specify values where none exist, or modify any default values to suit your needs. For information about other HTTP profile settings, see Configuring HTTP compression , and Configuring the RAM Cache .

Table 6.2 shows these profile settings. For those settings that have default values, you can retain those default settings or modify them. Following this table are descriptions of the settings and the procedure for changing them.

Table 6.2 Configuration settings in an HTTP profile
Setting
Description
Default Value
Name
Specifies the user-supplied name of the profile. You must specify a name for your profile.
No default value
Parent Profile
Specifies the profile from which your custom profile is derived.
http
Basic Auth Realm
Specifies an authentication realm for client authentication.
No default value
Fallback Host
Specifies the fallback host to send as an HTTP 302 response when all nodes are down.
No default value
Header Insert
Specifies the header string that you want to insert into an HTTP request.
No default value
Header Erase
Specifies the header string that you want to erase from an HTTP request.
No default value
Response Chunking
Specifies how to handle chunking for HTTP responses. Possible values are Unchunk, Rechunk, Selective, and Preserve.
Preserve
OneConnect Transformations
Performs HTTP header transformations for the purpose of keeping connections open. This feature requires configuration of a One ConnectTM profile.
Disabled
Redirect Rewrite
Allows you to modify HTTP redirections. Possible values are Matching, All, Nodes, or None.
None
Maximum Header Size
Specifies the maximum size that the LTM system allows for HTTP headers. The default value is represented in bytes.
32
Pipelining
Enables or disables HTTP pipelining.
Disabled
Insert XForwarded-For
Specifies an XForwarded-For header that the LTM system can insert into an HTTP request, to use with connection pooling. This feature adds the IP address of the client as the value of the XForwarded-For header.
No default value
LWS Maximum Columns
Specifies the maximum width allowed for an HTTP header that is inserted into an HTTP request.
80
LWS Separator
Specifies the separator that the LTM system should use between HTTP headers when a header exceeds the maximum width allowed.
\r\n
Maximum Requests
Specifies the maximum number of HTTP requests that the system allows for a single Keep-Alive connection.
0

 

Before configuring an HTTP profile, it is helpful to have a description of certain settings that you might want to change.

Specifying a profile name

To create an HTTP profile, you must specify a unique name for the profile. The Name setting is one of only two settings for which you must actively specify a value when creating an HTTP profile; all other settings have default values.

To specify a profile name, simply locate the Name setting and type a unique name for the profile.

Specifying a parent profile

Every profile that you create is derived from a parent profile. You can use the default http profile as the parent profile, or you can use another HTTP profile that you have already created.

To specify a parent profile, locate the Parent Profile setting and select a profile name.

Specifying a realm for basic authentication

The value of the Basic Auth Realm setting is a string that you provide. The LTM system sends this string to a client as part of client authentication.

To configure this setting, locate the Basic Auth Realm setting and type a value.

Specifying a fallback host

Another feature that you can configure within an HTTP profile is HTTP redirection. HTTP redirection allows you to redirect HTTP traffic to another protocol identifier, host name, port number, or URI path. For example, if all members of the targeted pool are unavailable (that is, the members are disabled, marked as down, or have exceeded their connection limit), the LTM system can redirect the HTTP request to the fallback host, with the HTTP reply Status Code 302 Found.

When configuring the LTM system to redirect HTTP traffic to a fallback host, you can specify an IP address or a fully-qualified domain name (FQDN). The value that you specify becomes the value of the Location header that the servers sends in the response. For example, you can specify a redirection as http://redirector.siterequest.com.

Inserting headers into HTTP requests

An optional setting in an HTTP profile is HTTP header insertion. The HTTP header being inserted can include a client IP address. Including a client IP address in an HTTP header is useful when a connection goes through a secure network address translation (SNAT) and you need to preserve the original client IP address.

The format of the header insertion that you specify is generally a quoted string. Alternatively, however, you can insert a Tools Command Language (TCL) expression into a header that dynamically resolves to the desired value. When you assign the configured HTTP profile to a virtual server, the LTM system then inserts the header specified in the profile into any HTTP request that the LTM system sends to a pool or pool member.

Note

In addition to inserting a string such as a client IP address into an HTTP request, you can configure the LTM system to insert SSL-related headers into HTTP requests. Examples are: client certificates, cipher specifications, and client session IDs. To insert these types of headers, you must create an iRule. For more information on using iRule commands to perform header insertion, Chapter 13, Writing iRules.

To insert a header into an HTTP request, locate the Header Insert setting and type a value.

Erasing content from HTTP headers

Another optional setting is the Header Erase setting. Using this setting, you can configure a profile to erase the contents of a header from an HTTP request that is being sent from a client to a server. With this feature, you can erase header content from HTTP requests before forwarding the requests over the network. Such headers might contain sensitive information, such as user IDs or telephone numbers, that must be erased before the information is forwarded.

When you use this setting, the LTM system erases the contents of the specified header and replaces that content with blank spaces. The header itself is retained.

Note

This feature does not apply to HTTP responses being sent from a server to a client.

The client header with the contents to be erased must be specified as a quoted string. To erase a header from an HTTP request, locate the Header Erase setting and type a value.

Configuring chunking

Sometimes, you might want to inspect and/or modify HTTP application data, such as when you are using an iRule that inspects the content of an HTTP response. Such inspections or modifications require that the response be unchunked, that is, not in chunked encoding. Using the Response Chunking settings, the LTM system can unchunk a chunked response before performing an action on that response.

Possible values for this setting are Unchunk, Rechunk, Selective, and Preserve. The default value is Preserve.

Table 6.3 describes each of these values and the action that the LTM system takes, depending on whether an original response is chunked or unchunked.

Table 6.3 Chunking behavior of the LTM system
Setting
Original response is chunked
Original response is unchunked
Unchunk
The LTM system unchunks the response and processes the HTTP content, and passes the response on as unchunked. The connection closes when all data is sent to the client as indicated by the Connection: Close header.
The LTM system processes the HTTP content and passes the response on untouched.
Rechunk
The LTM system unchunks the response, processes the HTTP content, re-adds the chunk trailer headers, and then passes the response on as chunked. Any chunk extensions are lost.
The LTM system adds transfer encoding and chunking headers on egress.
Selective
Same as Rechunk.
The LTM system processes the HTTP content and then passes the response on untouched.
Preserve
The LTM system leaves the response chunked, processes the HTTP content, and passes the response on untouched. Note that if HTTP compression is enabled, the LTM system does not compress the response.
The LTM system processes the HTTP content and then passes the response on untouched.

 

Enabling or disabling OneConnect transformations

This setting enables or disables part of the OneConnectTM feature. When enabled, this setting performs HTTP Connection header transformations on HTTP/1.0 requests, for the purpose of implementing Keep-Alive support for connection persistence. Thus, when a client sends an HTTP/1.0 request with a Connection: Close header, this feature forces the connection to remain open by transforming the header to Connection: Keep-Alive.

The default value for this setting is Disabled.

Important

To enable this setting, you must also enable the connection pooling component of the OneConnectTM feature. You enable connection pooling by configuring a OneConnect profile. For more information on connection pooling and configuring a OneConnect profile, see Chapter 5, Understanding Profiles.

For general information on the OneConnectTM feature, see Chapter 1, Introduction to Local Traffic Management.

To enable OneConnect transformations, locate the OneConnect Transformations setting and check the box.

Rewriting an HTTP redirection

Sometimes, a client request is redirected from the HTTPS protocol to the HTTP protocol, which is a non-secure channel. If you want to ensure that the request remains on a secure channel, you can cause that redirection to be rewritten so that it is redirected back to the HTTPS protocol.

Note that the rewriting of any redirection takes place only in the HTTP Location header of the redirection response, and not in any content of the redirection.

To enable the LTM system to rewrite HTTP redirections, you simply specify, through the Configuration utility, the way that you want the system to handle URIs during the rewrite. Once enabled, this feature rewrites the protocol name port number

Possible values for this setting are Matching, All, Nodes, or None.

Selecting URIs to rewrite

When configuring the LTM system to rewrite HTTP redirections, you specify whether the system should rewrite only those URIs matching the URI originally requested by the client (minus an optional trailing slash), or whether the system should rewrite all URIs. In the latter case, the system always rewrites redirected-to URIs, and rewrites those URIs as if they matched the originally-requested URIs.

If the URI contains a node IP address instead of a host name, you can configure the LTM system to change that IP address to the virtual server address.

Table 6.4 shows examples of how redirections of client requests are transformed when the LTM system is listening on port 443, and the Rewrite Redirections setting is enabled.

Table 6.4 Examples of rewriting HTTP redirections with the system listening on port 443
Original Redirection
Rewrite of Redirection
http://www.myweb.com/myapp/
https://www.myweb.com/myapp/
http://www.myweb.com:8080/myapp/
https://www.myweb.com/myapp/

 

Table 6.5 shows examples of how redirections of client requests are transformed when the SSL proxy is listening on port 4443, and the rewrite feature is enabled.

Table 6.5 Examples of rewriting HTTP redirections with the system listening on port 4443
Original Redirection
Rewrite of Redirection
http://www.myweb.com/myapp/
https://www.myweb.com:4443/myapp/
http://www.myweb.com:8080/myapp/
https://www.myweb.com:4443/myapp/

 

Rewriting the protocol name

When configured to rewrite HTTP redirections, the LTM system rewrites the HTTP protocol name to HTTPS. For example, a client might send a request to https://www.sample.com/bar and be initially redirected to http://www.sample.com/bar/, which is a non-secure channel. If you want the client request to remain on a secure channel, you can configure the LTM system to rewrite the redirected URI to go to https://www.sample.com/bar/ instead. (Note the addition of the trailing slash.)

Specifying the maximum header size

With this setting, you can specify the maximum size that the LTM system allows for HTTP headers. The default value is 32 and is represented in bytes.

Enabling support for pipelining

Normally, a client cannot make a request until the previous request has received a response. HTTP/1.1 pipelining allows clients to make requests even when prior requests have not received a response. For this to succeed, however, destination servers must include support for pipelining. This feature enables that support on the LTM system.

To enable pipelining, locate the Pipelining setting and check the box. By default, this feature is set to Disabled.

Inserting an XForwarded For header

When using connection pooling, which allows clients to make use of existing server-side connections, you can insert the XForwarded For header and specify a client IP address. When you configure the LTM system to insert this header, the target server can identify the request as coming from a client other than the client that initiated the connection.

Configuring the maximum columns for linear white space

This setting specifies the maximum number of columns allowed for a header that is inserted into an HTTP request.

To configure the LWS Maximum Columns setting, specify a maximum value.

Configuring a linear white space separator

This setting specifies the separator that the LTM system should use between HTTP headers when a header exceeds the maximum width specified by the LWS Maximum Columns setting.

To configure the LWS Separator setting, specify a value for the separator.

Specifying a maximum number of requests

The Maximum Requests setting specifies the maximum number of requests that the system allows for a single Keep-Alive connection. When the specified limit is reached, the final response contains a Connection: close header is followed by the closing of the connection. The default setting is 0, which in this case means that the system allows an infinite number of requests per Keep-Alive connection.

Configuring HTTP compression

In a typical client-server scenario, browsers and servers can be configured to compress and uncompress HTTP content. HTTP compression reduces the amount of data to be transmitted, thereby significantly reducing bandwidth usage. The following two sections describe the benefits of configuring the LTM system to perform HTTP compression tasks.

Compression in a typical client-server scenario

When HTTP compression is enabled in a client-server environment, a browser inserts an Accept-Encoding header into a client request, specifying the compression methods that the browser understands. Consequently, the server reads the header and compresses the response body with one of those compression methods. The server then inserts a Content-Encoding header in the response, to communicate to the browser the compression method that the server used. Upon receiving the compressed response, the browser reads the Content-Encoding header and uncompresses the data accordingly.

Enabling HTTP compression without an LTM system typically requires installation and configuration of compression software on the destination server.

Compression using the LTM system

An optional feature is the LTM system's ability to off-load HTTP compression tasks from the target server. All of the tasks needed to configure HTTP compression on the LTM system, as well as the compression software itself, are centralized on the LTM system.

The primary way to enable the HTTP compression option is by setting the Compression setting of an HTTP profile to Enabled. This causes the LTM system to compress HTTP content for any responses matching the values that you specify in the Request-URI or Content-Type settings of the HTTP profile.

If you want to enable HTTP compression for specific connections, you can write an iRule that specifies the HTTP:compress enable command. For more information, see Chapter 13, Writing iRules .

When HTTP compression is enabled on the LTM system, the LTM system executes a series of steps:

  1. First, the LTM system reads the Accept-Encoding header of a client request, looks for specification of either the deflate or gzip compression method, and notes whether either method is marked as being preferred.
  2. If the Keep Accept Encoding setting in the HTTP profile is set to Disabled, the LTM system then removes the Accept-Encoding header from the request and passes the request on to the server. Removing the Accept-Encoding header prevents the server from performing the HTTP compression and from inserting the Content-Encoding header into its response.
  3. Upon receiving the server response, the LTM system inserts the Content-Encoding header, specifying the compression method that it has chosen to use. The LTM system chooses a compression method by looking for the specification of either the gzip or deflate compression method in the Accept-Encoding header of the client request. If the client request does not specify a compression method, the LTM system uses the deflate method to compress the response data.
  4. Finally, the LTM system then compresses the response and sends it to the client. The client then reads the Content-Encoding header in the response, determines the compression method used, and uncompresses the data accordingly.

Using the LTM system HTTP compression feature, you can include or exclude certain types of URIs or files that you specify. This is useful because some URI or file types might already be compressed. Using CPU resources to compress already-compressed data is not recommended because the cost of compressing the data usually outweighs the benefits. Examples of regular expressions that you might want to specify for exclusion are.*\.pdf, .*\.gif, or .*\.html.

Table 6.6 shows the compression settings that you can specify within an HTTP profile. Configuring these settings means either specifying a value where no default value exists, or changing a default value.

Table 6.6 Configurable settings for HTTP compression
Setting
Description
Default Value
Compression
Enables or disables the HTTP compression feature.
Disable
URI Compression
Displays the settings for including or excluding certain Request-URI responses. Possible values are URI List or Not Configured.
Not Configured
URI List
If the URI Compression setting is set to Enabled, specifies the URI targeted for compression, as well as the types of responses to include for and exclude from URI compression.
No default value
Content Compression
Displays the settings for including or excluding certain Content-Type responses. Possible values are Content List or Not Configured.
Not Configured
Content List
If the Content Compression setting is set to Enabled, specifies the type of content targeted for compression, as well as the type of responses to include for or exclude from content compression.
In the Include List box, default values are:
text/
application/(xml|x-javascript)
Preferred Method
Specifies the compression method that you want to use to compress the response. Possible values are gzip and deflate.
gzip
Minimum Content Length
Specifies the minimum length in bytes of a server response that is acceptable for compressing that response. The length applies to content length only, not headers.
1024
Compression Buffer Size
Specifies the maximum number of compressed bytes that the LTM system buffers before deciding whether or not to insert a Content-Length header into the response that specifies the compressed size.
4096
gzip Compression Level
Specifies the amount and rate of compression.
1 - Least Compression (Fastest)
gzip Memory Level
Specifies the number of kilobytes of memory that the LTM system uses for internal compression buffers when compressing a server response.
8
gzip Window Size
Specifies the number of kilobytes in the window size that the LTM system uses when compressing a server response.
16
Vary Header
Enables or disables the insertion of a Vary header into cacheable server responses.
Enabled
HTTP/1.0 Requests
Enables or disables compression of responses to HTTP/1.0 client requests.
Disabled
Keep Accept Encoding
When enabled, allows the target server to perform the HTTP compression instead of the LTM system.
Disabled
Browser Workarounds
Implements browser workarounds.
Disabled (unchecked)
CPU Saver
Specifies, when checked (enabled), that the system monitors the percent CPU usage and adjusts compression rates automatically when the CPU usage reaches either the CPU Saver High Threshold or the CPU Saver Low Threshold.
Enabled (checked)
CPU Saver High Threshold
Specifies the amount of CPU usage that causes the system to change the amount of content being compressed, and the amount of compression being applied.
90
CPU Saver Low Threshold
Specifies the amount of CPU usage that causes the system to revert back to user-defined compression values.
75

 

Before configuring an HTTP profile, it is helpful to have a description of the compression settings that you might want to change.

Enabling or disabling the compression feature

The Compression setting causes the LTM system to perform compression on server responses. Possible values are:

  • Enabled
    This value causes the LTM system to compress, or refrain from compressing, HTTP server content for any responses matching the values that you specify in the URI List or Content List settings of the HTTP profile.
  • Disabled
    When the Compression setting is set to Disabled, the LTM system does not perform HTTP compression.
  • Selective
    This setting causes the LTM system to perform HTTP compression only when specified by an iRule containing the HTTP::compress command.

To enable HTTP compression, locate the Compression setting and select Enabled. If you are enabling compression through the use of the iRule command HTTP::compress <enable>, select Selective.

Using URI compression

If you enable compression, you probably do not want the LTM system to compress every kind of server response. Using the URI Compression setting, you can set its value to URI List, which instructs the LTM system to include in compression, or exclude from compression, certain responses that are specified in the URIs of client requests.

More specifically, you can type regular expressions to specify the types of server responses that you want the LTM system to include in, or exclude from, compression. For example, you can specify that you want the LTM system to compress all.htm responses by typing the regular expression.*.htm. The LTM system then compares that response type to the URI specified within each client request, and if the system finds a match, takes some action.

Any regular expression that you specify must be in Advanced Regular Expression (ARE) syntax.

To use the URI Compression feature, locate the URI Compression setting and select URI List. You can then use the Include List box or the Exclude List box to type your regular expressions. If you do not specify any list (either URI or content), the LTM system compresses all responses. For more information on content lists, see Using content compression .

Including URI-specified responses in HTTP compression

When the URI compression setting is enabled, and you type one or more values in the Include List, the LTM system compresses only those responses that match the URI part of the client request line.

The values you specify in the Include List box are in the form of regular expressions. For example, if the Include List box contains the values.*.txt,.*.htm, and.*.html, and those expressions match URIs in client requests, then the LTM system compresses only the responses for those URIs that match the specified regular expressions.

To apply this setting successfully, the LTM system must find a match in at least one of the values specified in the Include List box. If the LTM system finds no match, then no response is compressed.

Excluding URI-specified responses in HTTP compression

When the URI compression setting is enabled, and you type one or more values in the Exclude List, the LTM system excludes from compression those responses that match the URI part of the client request line.

The values you specify in the Exclude List box are in the form of regular expressions. For example, if the Exclude List box contains the value.*.pdf, and that expression matches URIs in client requests, then the LTM system excludes from compression any.pdf responses for those URIs.

To apply this setting successfully, the LTM system must find a match in at least one of the values specified in the Exclude List box. If the LTM system finds no match, then no responses are excluded from compression.

Using content compression

If you enable compression, you probably do not want the LTM system to compress every kind of server response. Using the Content Compression setting, you can set its value to Content List, which instructs the LTM system to include in compression, or exclude from compression, certain responses that are specified in the Content-Type header of server responses.

More specifically, you can type regular expressions to specify the types of server responses that you want the LTM system to include in, or exclude from, compression. For example, you can specify that you want the LTM system to compress all.htm responses by typing the regular expression.*.htm. The LTM system then compares that response type to the value of the Content-Type header specified within each server response, and if the system finds a match, takes some action.

Any regular expression that you specify must be in Advanced Regular Expression (ARE) syntax.

To use the Content Compression feature, locate the Content Compression setting and select Content List. You can then use the Include List box or the Exclude List box to type your regular expressions. If you do not specify any list (either URI or content), the LTM system compresses all responses. For more information on content lists, see Using URI compression .

Including Content-Type responses in HTTP compression

When compression is enabled and you specify one or more values in the Include List box, the LTM system includes only those responses that match the value of the server's Content-Type header. The value of this setting is a list of those header values. For example, if the Include List box contains the values application/pdf and image/**, then only responses of those content types are compressed.

To include all text types, you assign the value text/.* to this setting.

Excluding Content-Type responses in HTTP compression

When compression is enabled and you specify one or more values in the Exclude List box, the LTM system excludes those responses that match the value of the server's Content-Type header. The value of this setting is a list of those header values. For example, if the Exclude List box contains the values application/pdf and image/**, then responses of those content types are excluded from compression.

To exclude all text types, you assign the value text/.* to this setting.

Specifying a preferred compression method

Using the Preferred Method setting, you can specify the compression method that you want the BIG-IP system to use when compressing responses. The two possible values are gzip and deflate. The default value is gzip.

Specifying minimum content length for compression

When compression is enabled, the Minimum Content Length setting specifies the minimum length of a server response in uncompressed bytes that the LTM system requires for compressing that response. The LTM system finds the content length of a server response in the Content-Length header of the server response. Thus, if the content length specified in the response header is below the value assigned to the Minimum Content Length setting, the LTM system does not compress the response. The length in bytes applies to content length only, not headers.

For example, using the default value of 1024, the LTM system compresses only those responses with HTTP content containing at least 1024 bytes.

Sometimes the Content-Length header does not indicate the content length of the response. In such cases, the LTM system compresses the response, regardless of size.

To specify a minimum content length, locate the Minimum Content Length setting, and type a numeric value.

Specifying the compression buffer size

When compression is enabled, the Compression Buffer Size setting specifies the maximum number of compressed bytes that the LTM system buffers before deciding whether or not to preserve a Keep-Alive connection and rewrite the Content-Length header.

For example, using the default value of 4096, the LTM system buffers up to 4096 bytes of compressed data before deciding whether or not to preserve the connection and rewrite the Content-Length header.

The LTM system's decision to rewrite the Content-Length header depends on whether response chunking is enabled (using the Response Chunking profile setting). Table 6.7 shows the behavior of the LTM system with respect to compression buffer size and response chunking.

Table 6.7 LTM system behavior based on maximum buffer size
If the size of the compressed response is
And the compressed response is
Then the LTM system
Equal to or greater than the maximum buffer size
Chunked
Keeps the connection open (if the Connection header is not set to Close).
Not chunked
Closes the connection by changing the value of the Connection header to Close.
Less than the maximum buffer size
Chunked
Does not insert a Content-Length header with a compressed response size.
Not chunked
Inserts a Content-Length header with a compressed response size.

 

For more information, see Specifying minimum content length for compression , preceding.

To specify a compression buffer size, locate the Compression Buffer Size setting and type a numeric value.

Specifying a compression level

Using the gzip Compression Level setting, you can specify the extent to which data is compressed, as well as the compression rate. Possible values are 1 - Least Compression (Fastest), 9 - Most Compression (Slowest), and Other. The default compression level is 1 - Least Compression (Fastest).

You can specify any whole number ranging from 1 through 9, with these results:

  • Specifying a lower number causes data to be less compressed but at a higher performance rate. Thus, a value of 1 causes the least compression but the fastest performance.
  • Specifying a higher number causes data to be more compressed but at a slower performance rate. Thus, a value of 9 (the highest possible value) causes the most compression, but the slowest performance.
Warning

Selecting any value other than 1 - Least Compression (Fastest) can degrade system performance.

Specifying a memory level for gzip compression

The gzip Memory Level setting specifies a value representing the amount of kilobytes of memory that the LTM system uses to compress data when using the gzip or deflate compression method. The value of the gzip Memory Level setting must be a power-of-2 integer, in bytes, ranging from 1 to 256.

Generally, a higher value causes the LTM system to use more memory, but results in a faster and higher compression ratio. Conversely, a lower value causes the LTM system to use less memory, but results in a slower and lower compression ratio. The default value is 8.

To specify a memory level, locate the gzip Memory Level setting and select a numeric value.

Specifying window size for gzip compression

The gzip Window Size setting specifies a value representing the number of kilobytes in window size that the LTM system uses when compressing a server response using the gzip or deflate compression method. The value of the gzip Window Size setting must be a power-of-2 integer, in bytes, ranging from 1 to 128.

Generally, a higher value causes the LTM system to use more memory, but results in a higher compression ratio. Conversely, a lower value causes the LTM system to use less memory, but results in a lower compression ratio. The default value is 16.

To specify a window size, locate the gzip Window Size setting and select a numeric value.

Enabling or disabling the Vary header

When compression is enabled, the Vary Header setting inserts the Vary: Accept-Encoding header into a compressed server response. If the Vary header already exists in the response, the LTM system appends the value Accept-Encoding to that header.

The reason for inserting the Vary: Accept-Encoding header into a server response is to follow a recommendation by RFC2616, which states that the Vary header should be inserted into any cacheable response that is subject to server-driven negotiation. Server responses that are subject to HTTP compression fall into this category.

If the Vary Header setting is disabled, the LTM system does not insert the Vary header into a server response.

To disable the Vary header, locate the Vary Header setting and clear the Enabled box.

Allowing compression for HTTP/1.0 requests

The HTTP/1.0 Requests setting is included for backward compatibility, allowing HTTP compression for responses to HTTP/1.0 client requests. The default value for this setting is Disabled.

If this setting is set to Enabled, the LTM system only compresses responses in either of the following cases:

  • When the server responds with a Connection: close header
  • When the response content is no greater than the value of the Compression Buffer Size setting

To enable compression for HTTP/1.0 requests, locate the HTTP/1.0 Requests setting and check the box.

Keeping the Accept-Encoding header

Normally, when you enable HTTP compression, the LTM system strips out the Accept-Encoding header from the HTTP request. This causes the LTM system to perform the HTTP compression instead of the target server.

By default, the Keep Accept Encoding setting is disabled. If you want to allow the target server instead of the LTM system to perform the HTTP compression, simply enable this setting.

Implementing browser workarounds

When you enable the Browser Workarounds setting, the system uses built-in workarounds for several common browser issues that occur when compressing content. More specifically, enabling this setting prevents the system from compressing server responses when any of these conditions exist:

  • The client browser is Netscape version 4.0x.
  • The client browser is Netscape version 4.x (that is, versions 4.10 and higher), and the Content-Type header of the server response is not set to text/html or text/plain.
  • The client browser is Microsoft® Internet Explorer (any version), the Content-Type header of the server response is set to either text/css or application/x-javascript, and the client connection uses SSL.
  • The client browser is Microsoft® Internet Explorer (any version), the Content-Type header of the server response is set to either text/css or application/x-javascript, and the Cache-Control header of the server response is set to no-cache.

The default setting is disabled (unchecked).

CPU Saver

When you enable the CPU Saver setting, the system monitors the percent CPU usage and adjusts compression rates automatically when the CPU usage reaches the percentage defined in either the CPU Saver High Threshold or the CPU Saver Low Threshold. The default setting is enabled (checked).

CPU Saver High Threshold

The CPU Saver High Threshold setting specifies the percent of CPU usage at which the system starts automatically decreasing the amount of content being compressed, as well as the amount of compression which the system is applying. The default setting is 90 percent.

CPU Saver Low Threshold

The CPU Saver Low Threshold specifies the percent CPU usage at which the system resumes content compression at the user-defined rates. The default setting is 75 percent.

Configuring the RAM Cache

This section describes how to configure the properties of the RAM Cache feature on the BIG-IP system. A RAM cache is a cache of HTTP objects stored in the BIG-IP system's RAM that are reused by subsequent connections to reduce the amount of load on the back-end servers.

Getting started with RAM caching

There are several concepts to consider before you configure the RAM cache on the BIG-IP system.

  • When to use the RAM cache
  • What items you can cache
  • The cache mechanism

When to use the RAM Cache

The RAM cache feature provides the ability to reduce the traffic load to back-end servers. This ability is useful if an object on a site is under high demand, if the site has a large quantity of static content, or if the objects on the site are compressed.

  • High demand objects
    This feature is useful if a site has periods of high demand for specific content. With RAM cache configured, the content server only has to serve the content to the BIG-IP system once per expiration period.
  • Static content
    This feature is also useful if a site consists of a large quantity of static content such as CSS, javascript, or images and logos.
  • Content compression
    For compressible data, the RAM cache can store data for clients that can accept compressed data. When used in conjunction with the compression feature on the BIG-IP system, the RAM cache takes stress off of the BIG-IP system and the content servers.

The items you can cache

The RAM Cache feature is fully compliant with the cache specifications described in RFC 2616, Hypertext Transfer Protocol -- HTTP/1.1. This means you can configure the RAM Cache feature to cache the following content types:

  • 200, 203, 206, 300, 301, and 410 responses
  • Responses to GET methods by default.
  • Other HTTP methods for URIs specified in the URI Include list or specified in an iRule.
  • Content based on the User-Agent and Accept-Encoding values. The RAM cache holds different content for Vary headers.

The items that the RAM cache does not cache are:

  • Private data specified by cache control headers
  • HEAD, PUT, DELETE, TRACE, and CONNECT methods, by default.

Understanding the RAM Cache mechanism

The default RAM cache configuration caches only the HTTP GET methods. You can use the RAM cache to cache both the GET and other methods, including non-HTTP methods, by specifying a URI in the URI Include list or writing an iRule. The cache uses the storage mechanism for cached content described in Table 6.8 .

Table 6.8 RAM cache storage mechanism
Action
Cached Content
Removed
All cookie headers are removed.
Modified
Hop-by-hop headers are modified when served. These headers include: Connection, Keep-Alive, and Transfer Encoding.
Added
A Date header is added that includes the current time on the BIG-IP system. An Age header is added that reflects the amount of time the item has been in the cache. Note that this setting is on by default in the profile. You can disable this setting by turning the Insert Age Header attribute off in the profile.
Unchanged
All other headers are stored as they are received.

 

Clearing items from the RAM cache

The RAM cache removes the least frequently used items in the cache. This prevents stale items from taking up room in the cache when newer items are selected for caching. The cache also uses a scoring system to remove stale items after a period of time. When a cached item reaches its age limit, it is expired from the cache. You can use the HTTP profile attributes to control the size of each cache instance and how quickly items are expired from the cache. For more information about these attributes, see the following section, Understanding RAM Cache settings .

Understanding RAM Cache settings

To configure the RAM cache, you need to configure the RAM cache settings of the HTTP profile. These settings provide the ability to turn on the cache and fine tune it for a specific implementation. In addition to configuring the RAM cache objects in the HTTP profile, you may want to use bigpipe utility commands, configure bigdb variables, or create iRules. For information on bigdb keys related to the RAM Cache feature, see Appendix B of the Network and System Management Guide. For information on creating iRules for RAM cache, see Chapter 13, Writing iRules , in this guide.

The default items stored by the cache are HTTP GET responses. However, you can specify URIs in the URI list if you want to cache POST and GET methods for a particular URI.

The RAM cache settings are available in the HTTP profile. Table 6.9 lists and describes the RAM cache settings for the HTTP profile type.

Table 6.9 RAM cache settings in the HTTP profile
Setting
Description
Default Value
RAM cache
Specifies whether the RAM Cache feature is enabled or disabled.
Disabled
Maximum Cache Size
Specifies the maximum size in megabytes for the RAM cache. When the cache reaches the maximum size, the system starts removing the oldest entries.
100
Maximum Entries
Specifies the maximum number of entries that can be in the RAM cache. The default is 0, which means that the system does not limit the maximum entries.
0
Maximum Age
Specifies how long in seconds that the system considers the cached content to be valid.
3600
Minimum Object Size
Specifies the smallest object in bytes that the system considers eligible for caching.
500
Maximum Object Size
Specifies the largest object in bytes that the system considers eligible for caching.
50000
URI Caching
Specifies whether the system retains or excludes certain URIs in the RAM cache. The process forces the system either to cache URIs that typically are ineligible for caching, or to not cache URIs that typically are eligible for caching.
Not Configured
URI List
Specifies the Uniform Resource Identifiers (URIs) that the system either includes in or excludes from caching.
Include List
Lists the URIs that are typically ineligible for caching, but the system caches them. When you add URIs to the include list, the GET methods are cached for the URI and other methods, including non-HTTP methods.
Exclude List
Lists the URIs that are typically eligible for caching, but the system does not cache them.
No default value
Ignore Headers
Specifies how the system processes client-side Cache-Control headers when RAM caching is enabled.
All
Specifies that the system disregards all Cache-Control headers.
Cache-Control:max-age
Specifies that the system ignores only the Cache-Control:max-age header.
None
Specifies that the system honors all Cache-Control headers.
All
Insert Age Header
Specifies, when enabled, that the system inserts Date and Age headers in the cached entry. The Date header contains the current date and time on the BIG-IP system. The Age header contains the length of time the content has been in the cache.
Enabled
Aging Rate
Specifies how quickly the system ages a cache entry. The aging rate ranges from 0 (slowest aging) to 10 (fastest aging).
9

 

Configuring FTP profile properties and settings

You can tailor FTP profile properties and settings to your specific needs. For those settings that have default values, you can retain those default settings or modify them. You can modify any settings either when you create the profile, or at any time after you have created it. For specific procedures on configuring a profile, see Chapter 5, Understanding Profiles .

Table 6.10 lists these configurable settings, along with a short description of each and the default values. Following this table are descriptions of specific settings.

Table 6.10 Properties and settings of an FTP profile
General property
Description
Default Value
Name
Specifies the user-supplied name of the profile. Specifying a name for your profile is required.
No default value
Parent Profile
Specifies the profile from which your custom profile is derived.
FTP
Translate Extended
Ensures compatibility between IP version 4 and IP version 6 clients and servers when using the FTP protocol.
Enabled
Data Port
Allows the FTP service to run on an alternate port.
20

 

Before configuring an FTP profile, it is helpful to have a description of certain node settings that you might want to change.

Specifying a profile name

To create an FTP profile, you must specify a unique name for the profile. The Name setting is one of only two settings for which you must actively specify a value when creating an FTP profile; all other settings have default values.

Specifying a parent profile

Every profile that you create is derived from a parent profile. In the Parent Profile setting, you can select the default FTP profile as the parent profile, or you can select another FTP profile that you have already created.

Specifying a Translate Extended value

Because IP version 6 addresses are not limited to 32 bits (unlike IP version 4 addresses), compatibility issues can arise when using FTP in mixed IP-version configurations.

Enabled by default, the Translate Extended setting causes the LTM system to automatically translate FTP commands when a client-server configuration contains both IP version 4 and IP version 6 systems. For example, if a client system running IP version 4 sends the FTP PASV command to a server running IP version 6, the LTM system automatically translates the PASV command to the equivalent FTP command for IP version 6 systems, EPSV.

The LTM system translates the FTP commands EPRV and PORT in the way.

It is highly unlikely that you will need to change the default value (Enabled) for this setting. The only case where you might want to disable this setting is when sending an EPSV command to an IP version 4 system, such as when testing an FTP server.

Specifying a data port

The Data Port setting allows the FTP service to run on an alternate port. You can use the default port number 20, or specify another port number.

Managing HTTP and FTP profiles

Using the Configuration utility, you can view HTTP and FTP profiles and delete any custom profiles that you have created. Note, however, that you cannot delete the default profiles http and ftp.

For the procedures on creating and modifying SSL profiles, see Chapter 5, Understanding Profiles .

To view an HTTP or FTP profile

  1. On the Main tab, expand Local Traffic.
  2. Click Profiles.
    The Profiles screen opens.
  3. From the Services menu, choose HTTP or FTP.
    This displays a list of any existing HTTP or FTP profiles.
  4. In the Name column, click the name of the profile that you want to view.

Tip


When listing existing profiles, you can use the Search box that appears directly above the profile list. With the Search box, you can specify a string to filter the list, thereby showing only those objects that match the string. The default setting is an asterisk (*), which means show all objects.

To delete an HTTP or FTP profile

  1. On the Main tab, expand Local Traffic.
  2. Click Profiles.
    The Profiles screen opens.
  3. From the Services menu, choose HTTP or FTP.
    This displays a list of any existing client-side or server-side profiles.
  4. Click the Select box to the left of the custom profile that you want to delete.
  5. Click Delete.
    A confirmation screen appears.
  6. Click Delete.



Table of Contents   |   << Previous Chapter   |   Next Chapter >>

Was this resource helpful in solving your issue?




NOTE: Please do not provide personal information.



Incorrect answer. Please try again: Please enter the words to the right: Please enter the numbers you hear:

Additional Comments (optional)