Applies To:

Show Versions Show Versions

Manual Chapter: Profiles for Managing HTTP Traffic
Manual Chapter
Table of Contents   |   << Previous Chapter   |   Next Chapter >>

BIG-IP® Local Traffic ManagerTM offers several features that you can use to intelligently control your application layer 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 various configuration profiles. A profile is a group of settings, with values, that correspond to HTTP traffic. A profile defines the way that you want the BIG-IP system to manage HTTP traffic.
In addition to these profiles, Local Traffic Manager includes other features to help you manage your application traffic, such as health monitors for checking the health of HTTP and HTTPS services, and iRules® for querying or manipulating header or content data. For more information, see the remainder of this guide.
To configure and manage HTTP profiles, log in to the BIG-IP Configuration utility, and on the Main tab, expand Local Traffic, and click HTTP.
You can configure an HTTP profile to ensure that HTTP traffic management suits your specific needs. You can configure the profile settings when you create a profile, or after profile creation by modifying the profiles settings.
You can also use the default HTTP profile, named http, as is, if you do not want to create a custom HTTP profile.
You can use the default http profile as is, or create a custom HTTP profile. The http profile is considered a default profile because it does not inherit setting values from a parent profile.
The following table shows the profile settings for an HTTP type of profile. For those settings that have default values, you can retain those default settings or modify them. Following this table are more detailed descriptions of the settings.
Specifies the fallback host to send as an HTTP 302 response when either all nodes are down, or the selected node is down but not yet detected as such by the associated monitors.
Specifies the HTTP error codes that cause the BIG-IP system to redirect an HTTP response to the host specified with the Fallback Host setting.
When you type the error codes in the Fallback Error Codes box, you separate the codes with a space, such as 500 501 502. You can also specify a range of error codes, as in this example: 505-515.
Specifies how to handle chunking for HTTP responses. Possible values are Unchunk, Rechunk, Selective, and Preserve.
Performs HTTP header transformations for the purpose of keeping connections open. This feature requires configuration of a One ConnectTM profile.
Specifies the maximum size in bytes the system allows for all HTTP request headers combined, including the request line. If the combined headers length in bytes in a client request exceeds this value, the system stops parsing the headers and resets the TCP connection.
Insert XForwarded-For
Inserts an XForwarded-For header 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.
Specifies the maximum width allowed for an HTTP header that is inserted into an HTTP request.
Specifies the separator that the BIG-IP system should use between HTTP headers when a header exceeds the maximum width allowed.
Specifies the maximum number of HTTP requests that the system allows for a single Keep-Alive connection.
Specifies, when checked (enabled), that the system inspects HTTP traffic for security vulnerabilities, by using a security profile in Protocol Security ModuleTM. This option is available only when you are licensed for the module.
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.
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.
Redirection to a fallback host occurs if all members of the targeted pool are unavailable, or if a selected pool member is unavailable. (The term unavailable refers to a member being disabled, marked as down, or having exceeded its connection limit.) When one or more pool members are unavailable, Local Traffic Manager can redirect the HTTP request to the fallback host, with the HTTP reply Status Code 302 Found.
Although HTTP redirection often occurs when the system generates an LB_FAILED iRule event, redirection can also occur without the occurrence of this event, such as when:
The selected node sends an RST after a TCP 3WHS has completed, but before the node has sent at least a full response header.
Local Traffic Manager finds the selected node to be unreachable while receiving the body portion of a request or a pipelined request.
When configuring Local Traffic Manager 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.
In addition to redirecting traffic when a target server becomes unavailable, you can also specify the HTTP error codes from server responses that should trigger a redirection to the fallback host. Typical error codes to specify are 500, 501, and 502.
You can insert headers into HTTP requests. 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, Local Traffic Manager then inserts the header specified in the profile into any HTTP request that the BIG-IP 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 Local Traffic Manager 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.
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, Local Traffic Manager erases the contents of the specified header and replaces that content with blank spaces. The header itself is retained.
You can specify any headers within an HTTP response that you want the BIG-IP system to allow. If you are specifying more than one header, separate the headers with a blank space. For example, if you type the string Content-Type Set-Cookie Location, the BIG-IP system then allows the headers Content-Type, Set-Cookie, and Location.
Sometimes, you might want to inspect and/or modify HTTP application data, such as compressing 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 feature, Local Traffic Manager can unchunk a chunked response before performing an action on that response.
Table 6.2 describes each of the actions that you can configure the BIG-IP system to take, depending on whether an original response is chunked or unchunked.
Local Traffic Manager 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.
Local Traffic Manager processes the HTTP content and passes the response on untouched.
Local Traffic Manager 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.
Local Traffic Manager adds transfer encoding and chunking headers on egress.
Same as Rechunk.
Local Traffic Manager processes the HTTP content and then passes the response on untouched.
Local Traffic Manager leaves the response chunked, processes the HTTP content, and passes the response on untouched. Note that if HTTP compression is enabled, Local Traffic Manager does not compress the response.
Local Traffic Manager processes the HTTP content and then passes the response on untouched.
You can enable or disable part of the OneConnectTM feature, for HTTP/1.0 connections only. When this setting is enabled and a OneConnect profile is assigned to the virtual server, the setting performs Connection header transformations, for the purpose of keeping a client connection open. More specifically:
3.
Local Traffic Manager transforms the Connection: Close header to Connection: Keep-Alive.
4.
Through use of the OneConnect profile, the server-side connection detaches, goes into the pool of available server-side connections used for servicing other requests, and eventually closes. This process is hidden from the client.
5.
The client-side connection remains open, operating under the assumption that the server-side connection is still open and therefore able to accept additional requests from that client.
Note: For this feature to take effect, you must also configure a OneConnectTM profile, which enables connection pooling.
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 the redirection to be rewritten so that it is redirected back to the HTTPS protocol.
To enable Local Traffic Manager to rewrite HTTP redirections, you use the Rewrite Redirections setting to specify the way that you want the system to handle URIs during the rewrite.
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.
None
The system does not rewrite any redirections. This is the default value.
All
The system rewrites the URI in all HTTP redirect responses. In this case, the system rewrites those URIs as if they matched the originally-requested URIs.
Matching
The system rewrites the URI in any HTTP redirect responses that match the request URI (minus an optional trailing slash).
Nodes
The system rewrites the hidden node IP address to a virtual server address, and rewrites the port number. You choose this value when the virtual server is not configured with a Client SSL profile (that is, when the virtual server is configured to process plain HTTP traffic only).
Note: For values All, Matching, and Nodes, the system always hides the node IP address. Also, the system hides the node IP address independently of the protocol rewrite, with no regard to the protocol in the original redirection.
Table 6.3 shows examples of how redirections of client requests are transformed when the BIG-IP system is listening on port 443, and the Rewrite Redirections setting is enabled.
Table 6.4 shows examples of how redirections of client requests are transformed when the system is listening on port 4443, and the rewrite feature is enabled.
You can use the Configuration utility to encrypt one or more cookies that the BIG-IP system sends to a client system. When the client sends the encrypted cookie back to the BIG-IP system, the system decrypts the cookie.
This setting specifies the maximum size in bytes that the BIG-IP system allows for all HTTP request headers combined, including the request line. If the combined headers length in bytes in a client request exceeds this value, the system stops parsing the headers and resets the TCP connection. The default value is 32,768 bytes.
Normally, a client cannot initiate a request until the previous request has received a response. HTTP/1.1 pipelining allows clients to initiate multiple requests even when prior requests have not received a response. Note, however, that each initiated request is still processed sequentially; that is, a request in the queue is not processed until the previous request has received a response.
By enabling support for pipelining on the BIG-IP system, you remove the need to enable pipelining on the destination server itself. By default, this feature is enabled.
When using connection pooling, which allows clients to make use of existing server-side connections, you can insert the XForwarded For header into a request. When you configure Local Traffic Manager to insert this header, the target server can identify the request as coming from a client other than the client that initiated the connection. The default setting is Disabled.
You can specify the separator that Local Traffic Manager should use between HTTP headers when a header exceeds the maximum width specified by the LWS Maximum Columns feature.
You can specify 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.
You can configure the BIG-IP system to remove, preserve, or append Via headers in HTTP client requests, HTTP server responses, or both.
You can sepcify that the system inspect HTTP traffic for security vulnerabilities when you configure a security profile in Protocol Security ModuleTM. This option is available only when you are licensed for that module.
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.
An optional feature is the BIG-IP systems ability to off-load HTTP compression tasks from the target server. All of the tasks needed to configure HTTP compression in Local Traffic Manager, as well as the compression software itself, are centralized on the BIG-IP system.
Note: The string that you specify in the URI List or the Content List setting can be either a pattern string or a regular expression. Note that list types are case-sensitive for pattern strings. For example, the system treats the pattern string www.f5.com differently from the pattern string www.F5.com. You can override this case-sensitivity by using the Linux regexp command.
Important: The HTTP compression profile uses a default compression strategy named Speed. The Speed compression strategy ensures that Local Traffic Manager uses the hardware compression provider whenever possible, to maximize performance. You can change the compression strategy by using a command line interface.
If you want to enable HTTP compression for specific connections, you can write an iRule that specifies the HTTP:compress enable command.
1.
First, Local Traffic Manager 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 profile is set to Disabled, Local Traffic Manager 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, Local Traffic Manager inserts the Content-Encoding header, specifying the compression method that it has chosen to use. Local Traffic Manager 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, Local Traffic Manager can use either the gzip or deflate method to compress the response data. In this case, the default method that Local Traffic Manager uses is gzip.
4.
Finally, Local Traffic Manager 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 Local Traffic Manager HTTP compression feature, you can include or exclude certain types of URIs or files that you specify. Exclusion 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.
Although creating a custom HTTP compression profile is the primary way to implement data compression on Local Traffic Manager, there are other ways to implement data compression:
You can implement the default httpcompression profile as is.
You can implement the default wan-optimized-compression profile as is. This profile contains settings that are already configured to optimize data compression. This is a simpler configuration task, but it gives you less control over the type of data being compressed.
You can create a custom profile based on the wan-optimized-compression profile, and then modify the compression settings.
For a more advanced compression implementation, you can create a custom profile based on the default httpcompression profile, and then configure a different compression strategy, using tmsh. A compression strategy affects the way that the system uses hardware and software compression providers to provide the most efficient compression possible.
If you want to enable HTTP compression for specific connections, you can write an iRule that includes the command HTTP::compress <enable>. This is known as selective compression.
When you enable data compression, Local Traffic Manager compresses HTTP server content for any responses matching a set of criteria that you specify in an HTTP Compression type of profile.
Displays the settings for including or excluding certain Request-URI responses. Possible values are URI List or Not Configured.
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.
Note: When you use pattern strings, this list type is case-sensitive. For more information, see the previous section of this chapter.
Displays the settings for including or excluding certain Content-Type responses. Possible values are Content List or Not Configured.
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.
Note: When you use pattern strings, this list type is case-sensitive. For more information, see the previous section of this chapter.
In the Include List box, default values are:
text/
application/(xml|x-javascript)
Specifies the compression method that you want to use to compress the response. Possible values are gzip and deflate.
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.
Specifies the maximum number of compressed bytes that the BIG-IP system buffers before deciding whether or not to insert a Content-Length header into the response that specifies the compressed size.
Specifies the number of kilobytes of memory that the BIG-IP system uses for internal compression buffers when compressing a server response.
Specifies the number of kilobytes in the window size that the BIG-IP system uses when compressing a server response.
Enables or disables the insertion of a Vary header into cacheable server responses.
Keep Accept Encoding
When enabled, allows the target server to perform the HTTP compression instead of the BIG-IP system.
Browser Workarounds
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.
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.
Specifies the amount of CPU usage that causes the system to revert back to user-defined compression values.
If you enable compression, you probably do not want Local Traffic Manager to compress every kind of server response. Therefore, you can instruct Local Traffic Manager 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 Local Traffic Manager to include in, or exclude from, compression. For example, you can specify that you want Local Traffic Manager to compress all .htm responses by typing the regular expression .*.htm. Local Traffic Manager then compares that response type to the URI specified within each client request, and if the system finds a match, takes some action.
Note: The string that you specify can be either a pattern string or a regular expression. Note that list types are case-sensitive for pattern strings. For example, the system treats the pattern string www.f5.com differently from the pattern string www.F5.com. You can override this case-sensitivity by using the Linux regexp command.
If you enable compression, you probably do not want Local Traffic Manager to compress every kind of server response. therefore, you can instruct Local Traffic Manager 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 Local Traffic Manager to include in, or exclude from, compression. For example, you can specify that you want Local Traffic Manager to compress all .htm responses by typing the regular expression .*.htm. Local Traffic Manager 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.
Note: The string that you specify can be either a pattern string or a regular expression. Note that list types are case-sensitive for pattern strings. You can override this case-sensitivity by using the Linux regexp command.
You can specify the compression method that you want Local Traffic Manager to use when compressing responses. The two possible compression methods are gzip and deflate.
When compression is enabled, you can specify the minimum length of a server response in uncompressed bytes that Local Traffic Manager requires for compressing that response. Local Traffic Manager 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 that you assign for minimum content length, Local Traffic Manager does not compress the response. The length in bytes applies to content length only, not headers.
For example, using the default value of 1024, Local Traffic Manager 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, Local Traffic Manager compresses the response, regardless of size.
When compression is enabled, you can specify the maximum number of compressed bytes that Local Traffic Manager 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, Local Traffic Manager buffers up to 4096 bytes of compressed data before deciding whether or not to preserve the connection and rewrite the Content-Length header.
Local Traffic Managers decision to rewrite the Content-Length header depends on whether response chunking is enabled (using the Response Chunking profile setting). Table 6.6, shows the behavior of Local Traffic Manager with respect to compression buffer size and response chunking.
Keeps the connection open (if the Connection header is not set to Close).
Closes the connection by changing the value of the Connection header to Close.
Does not insert a Content-Length header with a compressed response size.
Inserts a Content-Length header with a compressed response size.
A gzip compression level defines the extent to which data is compressed, as well as the compression rate. You can set the gzip level in the range of 1 through 9. The higher the gzip level, the better the quality of the compression, and therefore the more resources the system must use to reach that specified quality. Setting a gzip level yields these results:
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.
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.
For example, you might set the gzip compression level to 9 if you are utilizing Local Traffic Manager cache feature to store response data. The reason for this is that the stored data in the cache is continually re-used in responses, and therefore you want the quality of the compression of that data to be very high.
As the traffic flow on the BIG-IP system increases, the system automatically decreases the compression quality from the gzip compression level that you set in the profile. When the gzip compression level decreases to the point where the hardware compression provider is capable of providing the specified compression level, the system uses the hardware compression providers rather than the software compression providers to compress the HTTP server responses.
Tip: You can change the way that Local Traffic Manager uses gzip levels to compress data by configuring the compression strategy. The compression strategy determines the particular compression provider (hardware or software) that the system uses for HTTP responses. The available strategies are: Speed (the default strategy), Size, Ratio, and Adaptive.
You can define the number of kilobytes of memory that Local Traffic Manager uses to compress data when using the gzip or deflate compression method. The memory level is a power-of-2 integer, in bytes, ranging from 1 to 256.
Generally, a higher value causes Local Traffic Manager to use more memory, but results in a faster and higher compression ratio. Conversely, a lower value causes Local Traffic Manager to use less memory, but results in a slower and lower compression ratio.
You can specify a value representing the number of kilobytes in window size that Local Traffic Manager uses when compressing a server response using the gzip or deflate compression method. This value is a power-of-2 integer, in bytes, ranging from 1 to 128.
Generally, a higher value causes Local Traffic Manager to use more memory, but results in a higher compression ratio. Conversely, a lower value causes Local Traffic Manager to use less memory, but results in a lower compression ratio.
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, Local Traffic Manager 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, Local Traffic Manager 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.
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, Local Traffic Manager only compresses responses in either of the following cases:
When the server responds with a Connection: close header
To enable compression for HTTP/1.0 requests, locate the HTTP/1.0 Requests setting and check the box.
Normally, when you enable HTTP compression, Local Traffic Manager strips out the Accept-Encoding header from the HTTP request. This causes Local Traffic Manager 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 Local Traffic Manager to perform the HTTP compression, simply enable this setting.
When you enable the Browser Workarounds setting, the system uses built-in workarounds for several common browser issues that occur when compressing content. The default setting is disabled (cleared). 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.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.
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 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 CPU Saver Low Threshold specifies the percent CPU usage at which the system resumes content compression at the user-defined rates.
If you need more control over the way that Local Traffic Manager compresses data than what the standard HTTP compression profile configuration provides, you can enable a compression strategy other than the default strategy. The default compression strategy is Speed.
Note: The tmsh command line interface is the only tool available for setting the compression strategy.
When using the command line interface to configure compression for a BIG-IP system, you can choose from four compression strategies: Speed, Size, Ratio, and Adaptive. The BIG-IP system uses the compression strategy that you select (a hardware card or the zlib program) to determine which compression provider to use for a given HTTP response. Once an HTTP response is assigned to a compression provider, the response remains associated with that compression provider until the response is completed.
Table 6.7 describes the four compression strategies.
The system uses the hardware compression provider to the fullest extent possible. Only when the hardware is busy does the system use a software compression provider to compress HTTP server responses. The Speed strategy is best used for bulk compression and for limiting CPU overhead.
The system performs as much compression in the software as possible using a ratio of TMM and Offload. Only when the software is busy does the system use the hardware compression provider to compress HTTP server responses. The Size strategy gives the best ratio at the expense of CPU overhead.
The system uses a weighted Round Robin approach to decide which compression provider to use to compress data. The Ratio strategy limits CPU overhead while giving good compression ratios.
The system first uses a software compression provider to compress HTTP server responses. The system switches to the hardware compression providers based on both the gzip compression level that you set in the HTTP compression profile and the hardware compression provider that the system contains.
As load on the system increases, the system responds by reducing the desired gzip compression level (specified in the HTTP compression profile). The system utilizes the hardware compression provider only when the provider can deliver the specified or systematically-reduced gzip compression level.
To configure caching, you need to configure a Web Acceleration type of profile. These settings provide the ability to turn on the cache and fine-tune it for a specific implementation. Using a Web Accleration type of profile, the system can store HTTP objects stored in memory that are reused by subsequent connections to reduce the amount of load on the back-end servers.
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 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 the 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 files, javascript files, or images and logos.
Content compression
For compressible data, the 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 cache takes stress off of the BIG-IP system and the content servers.
The 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 cache feature to cache the following content types:
200, 203, 206, 300, 301, and 410 responses
Responses to GET methods, by default
Content based on the User-Agent and Accept-Encoding values. The cache holds different content for Vary headers.
HEAD, PUT, DELETE, TRACE, and CONNECT methods, by default
The default cache configuration caches only responses to HTTP GET methods. However, you can use the cache to cache other methods, too, including non-HTTP methods. You do this by specifying a URI in the URI Include or Pin list within a Web Acceleration profile, or by writing an iRule.
What is the effect of adding URIs to the Include List in the Web Acceleration profile?
What is the order of preference that Local Traffic Manager uses when processing the Pin List, Include List, and Exclude List?
Local Traffic Manager determines which responses to cache by evaluating both the HTTP request and the response. Table 6.8 shows the criteria within both a request and a response that the system uses before determining whether to include or exclude a response from the cache.
The system invokes a CACHE::disable command within an HTTP_REQUEST event.
The request matches an item in the Exclude list of the Web accekeration profile.
The request matches an item in the Pin list of the Web Acceleration rofile.
The request matches an item in the Include list of the Web Acceleration profile.
The request specifies a method other than GET, including non-standard HTTP methods.
Always, except when overridden by an item in the Pin or Include lists, or by an iRule.
The value of the Vary header consists of the User-Agent and/or Accept-Encoding request header only.
Include multiple response for a single URL
The value of the Vary header changes in a subsequent response for the same resource.
Invalidates any existing cache entries
The value of the Vary header consists of any other request headers or the special value * (asterisk)
200 (OK)
203 (Non-Authoritative Information)
206 (Partial Content)
300 (Multiple Choices)
301 (Permanent Redirect)
410 (Gone)
The value of the Content-Length header in the response is 0.
Always, except when the response has no Content-Length header, that is, with chunked Transfer-Encoding, or the response relies on connection termination by the server.
The object size of the response is outside the configured minimum and maximum response object size and the maximum cache size.
Note: The term object size refers to response headers as well as the body of the response.
Always, whenever the object size exceeds the maximum cache size.
Otherwise, always, except when overridden by an item in the Pin or Include lists, or by an iRule.
The response contains an Expires header that has an invalid value.
Always, except when overridden by an item in the Pin or Include lists, or by an iRule.
Always, except when overridden by an item in the Pin or Include lists, or by an iRule.
The response contains a Cache-Control header with any of these values: no-store, no-cache, or private.
Always, except when overridden by an item in the Pin or Include lists, or by an iRule.
The request contains an Authorization header, and the Cache-Control header in the response lacks any of these values: s-maxage, must-revalidate, public.
For URIs in the Include List of a Web accekeratuin profile, Local Traffic Manager caches responses for all request methods. All other constraints still apply.
When using URI lists to determine which response you want Local Traffic Manager to cache, the system uses the following order of preference, in decreasing order:
Exclude List
Pin List
Include List
Local Traffic Manager takes certain actions on cached content, depending on the type of content. Table 6.9 lists and describes these actions.
Local Traffic Manager adds a Date header to cached content that includes the current time on the BIG-IP system.
The system also adds an Age header to cached content that reflects the amount of time that the item has been in the cache. Note that this setting is enabled by default in the Web Acceleration profile. You can disable this setting by disabling the Insert Age Header in the profile.
The 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, the item expires and the system removes it from the cache. You can use Web Acceleration profile attributes to control the size of each cache instance and the rate at which Local Traffic Manager removes expired items from the cache.
You can use one of the default Web Acceleration profiles or a customer Web Acceleration profile to configure caching on the system. Table 6.10 lists the settings of the default webacceleration profile.
With no WebAcceleratorTM system provisioned, this setting specifies size of the maximum size in megabytes reserved for the cache. When the cache reaches the maximum size, the system begins to remove the oldest entries.
With a provisioned WebAccelerator system, this setting defines the minimum reserved cache size. The maximum size of the minimum reserved cache is 64GB (with provisioned cache availability).
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.
Specifies the Uniform Resource Identifiers (URIs) that the system either includes in or excludes from caching.
Pin List
Lists the URIs for responses that you want the system to store indefinitely in the RAM cache.
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 system caches the GET methods 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.
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
Disregards client Cache-Control directive max-age specifically with a value of zero (max-age=0).
None
Specifies that the system honors all Cache-Control headers.
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.
Specifies how quickly the system ages a cache entry. The aging rate ranges from 0 (slowest aging) to 10 (fastest aging).
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)