Applies To:
Show Versions
BIG-IP AAM
- 14.1.3, 14.1.2, 14.1.0, 14.0.1, 14.0.0, 13.1.5, 13.1.4, 13.1.3, 13.1.1, 13.1.0, 13.0.1, 13.0.0
Overview: Lifetime rules
The length of time that a client browser, upstream device, or BIG-IP system keeps compiled content in its cache before refreshing it is called content lifetime. Content lifetime is expressed in the form of a time to live (TTL) value, and can vary for each cached response.
When content is in cache longer than its TTL value, the BIG-IP system considers the content expired. When the BIG-IP system receives a request for expired content, it sends that request to the origin web servers for fresh content, replaces the expired cached content with the fresh response, and then responds to the request.
Lifetime managed requests
The HTTP Cache-Control version 1.1 header specification identifies headers that are used to control web entities, such as the BIG-IP. Clients that are HTTP version 1.1-compliant are capable of providing request headers, which contain directives that control caching behavior.
If the Honor Headers In Request setting is enabled, the BIG-IP obeys any HTTP Cache-Control header directives configured for the client. If this setting is enabled and the client includes an HTTP Cache-Control header directive that indicates the client is not willing to accept content served from a cache, the BIG-IP refreshes the corresponding cached content for the request, even if that content has not yet expired.
If you want to use HTTP lifetime headers, but want to be able to serve valid content that the BIG-IP cached when applicable, you can move the no_cache list item for Honor Headers In Request, in the BIG-IP Cache Settings area, from the Selected list to the Available list.
Lifetime managed responses
BIG-IP lifetime rules only apply to responses; they are not relevant to requests. The BIG-IP applies lifetime rules only to responses that it receives from the origin web server. You can define how the BIG-IP manages cached content for responses, through the following lifetime rule settings.
| Lifetime Rule Settings | Description |
|---|---|
| WebAccelerator Cache Settings | These settings specify how long the BIG-IP retains cached content, how long the BIG-IP serves cached content if the origin web server is not available, and when to expire cached content. These settings also specify whether the BIG-IP honors the TTL values provided with the headers in the request and provided with the headers sent from the origin web server. |
| Client Cache Settings | These settings specify whether the client browser (or other upstream device) should store content locally and, if so, the maximum time the browser should store content. They also specify whether the BIG-IP should honor any existing no-cache directives, use custom Cache-Control directives, or replace origin web server directives with a no-cache directive. |
These settings apply to any HTTP response that matches to a leaf node for a specific acceleration policy, for which the option is set.
About specifying the amount of time to store cached content
If you have certain content that rarely changes, you can increase the amount of time that the BIG-IP and client store that content. This reduces the load on your origin web server and increases the perceived performance of your site.
The value under WebAccelerator Cache Settings for the Maximum Age setting determines how long the BIG-IP stores cached content. The values under Client Cache Settings for the Maximum Age and S-Max Age settings determine how long the client stores cached content. The S-Max Age setting can only be used for a shared cache. When the limit is met, the BIG-IP or client browser requests fresh content from the origin web server.
Specifying the amount of time for the BIG-IP to store cached content
Under WebAccelerator Cache Settings, the Maximum Age can be configured either as a heuristic value or as a specific amount of time.
For Use HTTP Lifetime Heuristic, the %Heuristic value is a percentage of time that the BIG-IP uses to calculate the lifetime for cached content from the last time it was refreshed. To determine the lifetime based on this setting, the BIG-IP reviews the value for the HTTP LAST_MODIFIED response header, and computes the cache expiration according to the value specified for the %Heuristic percentage. The formula for this calculation is as follows: ((current time - HTTP LAST_MODIFIED response header = X) * (lifetime heuristic)) + (current time) = content expiration
For example, if the HTTP LAST_MODIFIED response header specifies that the object was last modified at 9:00 a.m., the current time is 11:00 a.m., and the %Heuristic setting is a value of 50, then the content expiration is 12:00 p.m.
The Use HTTP Lifetime Heuristic setting is only in effect if you are using HTTP headers to identify content lifetime. Use this setting only if you want to use the HTTP LAST_MODIFIED response header to set compiled response TTL values.
Clearing the Use HTTP Lifetime Heuristic check box enables you to configure a specific amount of time for the Maximum Age value, with units of time ranging from Seconds through Days. Setting the Maximum Age value to 0 initiates a refresh for each request, preventing the BIG-IP from caching the associated content. A Maximum Age setting of 0 can significantly reduce the load on the origin web server, especially for large files and frequently accessed files, because the BIG-IP initiates a refresh for each request, instead of full GET request.
Specifying the amount of time for a client to store cached content
Under Client Cache Settings, the Preserve Origin Web Server headers/directives to downstream devices option and the Custom Cache-Control Directives option use the Maximum Age and S-Max Age settings to configure a specific amount of time, with units of time ranging from Seconds through Days.
Setting the Maximum Age or S-Max Age value to 0 initiates a refresh for each request, preventing the client from caching the associated content.
About serving cached content when origin web server content is unavailable
The BIG-IP can continue to serve content from its cache when an origin web server responds with specific HTTP status codes. By specifying a Stand-in Period and a Stand-in Code, you can enable the BIG-IP to provide stale content for those specific conditions.
Stand-in Period
In the WebAccelerator Cache Settings area, the value for the Stand-in Period setting identifies how long the BIG-IP continues to serve content from cache if the origin web server responds to the BIG-IP's requests for fresh content with an HTTP 404 (page not found), 500 (internal server error), or 504 (service unavailable) response. If the BIG-IP cannot retrieve fresh content from the origin web server after the stand-in period expires, or if the stand-in period is undefined, the BIG-IP provides the HTTP 404, 500, or 504 response from the origin web server.
The stand-in period requires an origin web server response. If the origin web server is down, and provides no response, the stand-in period is not applied.
Stand-in Code
If network failure occurs, or if the origin web server responds with certain error codes, the BIG-IP cannot validate cache with the origin web server. However, you can configure the BIG-IP to serve stale content during these conditions, by using the WebAccelerator Cache Settings Stand-in Code settings. The BIG-IP serves invalid content to the client if the origin web server response code meets these conditions. If a stand-in response code is not configured, the BIG-IP uses default values (404, 500, or 504) to determine whether it is serving stale content.
About preserving origin web server headers and directives to downstream devices
When you select the Preserve origin web server headers/directives to downstream devices option, under Client Cache Settings, the BIG-IP directs the client browser to store content locally on the client, in accordance with the cache directives that are defined in the HTTP headers sent from the origin web server.
To preserve a cache control directive and send it to downstream devices, you must include the directive for Origin Web Server Headers in the Selected list.
You can also specify a Maximum Age or an S-Max Age value to use when these directives are not specified by the origin web server. The BIG-IP uses the specified Maximum Age and S-Max Age value only when the origin web server value is not provided.
When you add Cache-Control extensions to the Custom Cache Extensions list, the BIG-IP preserves the specified extensions to send to the client. Unless specified, any Cache-Control extensions from the origin web server are removed from the response.
Custom Cache-Control directives
When you select the Custom Cache-Control directives option in Client Cache Settings, the BIG-IP enables you to do the following:
- Specify which origin web server headers to preserve and send to the client.
- Apply specified Maximum Age and S-Max Age headers
to the specified origin web server headers. Note: The specified Maximum Age and S-Max Age headers are used only when they are not provided by the origin web server.
-
Preserve Cache-Control extension headers sent from the origin web server.
When you add Cache-Control extension headers to the Custom Cache Extensions list, the BIG-IP preserves the specified extensions to send to the client. Unless specified, any Cache-Control extensions from the origin web server are removed from the response.
About replacing origin web server headers and directives with a no-cache directive
In Client Cache Settings, when you select the Replace Origin Web Server Headers/Directives with no-cache option, the BIG-IP inserts a no-cache directive into the HTTP Cache-Control header that is returned from the origin web server. This header instructs the client browser to not cache content.
When you add Cache-Control extensions to the Custom Cache Extensions list, the BIG-IP preserves the specified extensions to send to the client. Unless specified, any Cache-Control extensions from the origin web server are removed from the response.
