Applies To:Show Versions
- 11.5.10, 11.5.9, 11.5.8, 11.5.7, 11.5.6, 11.5.5, 11.5.4, 11.5.3, 11.5.2, 11.5.1
Introduction to HTTP profiles
BIG-IP® Local Traffic Manager™ 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.
You can configure an HTTP profile to ensure that HTTP traffic management suits your specific needs. You can configure the profile settings either when you create a profile or after you create the profile by modifying the profile’s settings. For all profile settings, you can specify values where none exist, or modify any default values to suit your needs. The BIG-IP system also includes default profiles that you can use as is, if you do not want to create a custom profile.
To manage HTTP traffic, you can use any of these profile types:
- HTTP (Hypertext Transfer Protocol)
- HTTP Compression
- Web Acceleration
In addition to the HTTP 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.
General HTTP properties
There are a few general settings that you can configure to create a basic HTTP type of profile that uses most of the default settings.
The HTTP profile provides three proxy modes: Reverse, Explicit, and Transparent. You can configure a custom HTTP profile that uses a specific proxy mode, and assign the custom HTTP profile to a virtual server to manage proxying of HTTP traffic, as necessary.
|Reverse||Default. You can specify the Reverse Proxy Mode to enable the BIG-IP® system to manage responses from multiple servers.|
|Explicit||The Explicit Proxy Mode enables the BIG-IP system to handle HTTP proxy requests and function as a gateway. By configuring browser traffic to use the proxy, you can control whether to allow or deny a requested connection, based on configured policies. The Explicit Proxy Mode requires a DNS resolver, specified in the Explicit Proxy area of the screen.|
|Transparent||The Transparent Proxy Mode enables the BIG-IP system to forward invalid HTTP traffic to a specified server, instead of dropping the connection. By configuring an HTTP profile to forward invalid HTTP traffic, you can manage various atypical service provider scenarios, such as HTTP traffic from non-browser clients that function as web browsers.|
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.
There are several general settings that you can configure to create an HTTP type of profile.
Basic Auth Realm
The Basic Auth Realm setting provides a quoted string for the basic authentication realm. The BIG-IP® system sends this string to a client whenever authorization fails.
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 server sends in the response. For example, you can specify a redirection as http://redirector.siterequest.com.
Fallback error codes
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.
Headers in HTTP requests
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 preferred 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.
Content erasure from HTTP headers
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.
The client header with the contents to be erased must be specified as a quoted string.
Headers in an HTTP response
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.
Possible chunking behaviors of Local Traffic Manager
The BIG-IP® system takes specific action on a response depending on whether the response is chunked or unchunked.
|Action||Original response is chunked||Original response is unchunked|
|Unchunk||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.|
|Rechunk||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.|
|Selective||Same as Rechunk.||Local Traffic Manager processes the HTTP content and then passes the response on untouched.|
|Preserve||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 OneConnect™ 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:
- A client sends an HTTP/1.0 request.
- The server sends a response, which initially includes a Connection: Close header.
- Local Traffic Manager™ transforms the Connection: Close header to Connection: Keep-Alive.
- 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.
- 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.
Rewrites of HTTP redirections
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.
When configuring Local Traffic Manager to rewrite HTTP redirections, you specify one of these values:
- The system does not rewrite any redirections. This is the default value.
- 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.
- The system rewrites the URI in any HTTP redirect responses that match the request URI (minus an optional trailing slash).
- 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).
Examples of rewriting HTTP redirections with the system listening on port 443
This table 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.
|Original Redirection||Rewrite of Redirection|
Examples of rewriting HTTP redirections with the system listening on port 4443
This table 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.
|Original Redirection||Rewrite of Redirection|
Cookie encryption and decryption
You can use the BIG-IP 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.
X-Forwarded-For header insertion
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.
Maximum columns for linear white space
You can specify the maximum number of columns allowed for a header that is inserted into an HTTP request.
Linear white space separators
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.
Maximum number of requests
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, which 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.
Proxy Via headers
You can configure the BIG-IP® system to remove, preserve, or append Via headers in HTTP client requests, HTTP server responses, or both.
Overview: Using Via headers
Via headers provide useful information about intermediate routers that can be used in network analysis and troubleshooting.
About using Via headers in requests and responses
The Via header, configured in an HTTP profile, provides information about each intermediate router that forwards a message. Intermediate routers between a client and an origin web server use the Via header to indicate intermediate protocols and recipients. This information can be used for the following tasks:
- Identifying the intermediate routers that forward messages.
- Identifying the protocols for intermediate routers.
About identifying intermediate routers with a Via header
The Via header, configured in an HTTP profile, concatenates information for each router in a response or request, separated by commas. For example, the following Via header includes two routers, with each router comprising the required protocol and address:
Via: 1.1 wa.www.siterequest1.com, 1.1 wa.www.siterequest2.com
When a client initiates a request with a Via header to an origin web server, the origin web server returns a response with a Via header often following a similar path. For example, a Via header router sequence for the request would be 1, 2, 3, and the router sequence for the client's response would be 3, 2, 1.
The inverse is true when an origin web server initiates a response with a Via header to a client. For example, a Via header router sequence for a response would be 1, 2, 3, and the router sequence for the client's request would be 3, 2, 1.
About identifying protocols for intermediate routers with a Via header
You can identify specific protocols and versions of protocols for intermediate routers by using a Via header, configured in an HTTP profile. When a client sends a request to an origin web server, the header information is concatenated for each intermediate router, including the protocol type (if different from HTTP) and version.
The Via header includes both required and optional protocol information about each router, as follows:
The HTTP protocol name is optional; however, other protocol names are required.
The protocol version of the message is required, which for HTTP is 1.0, 1.1, and so on.
The host name is required. For privacy purposes, however, an alias can replace the actual host name.
The port number associated with the host name is optional. When the port number is omitted, the default port applies.
A comment describing the router is optional, and includes whatever string you specify in the Send Proxy Via Header Host Name field, by selecting Append in the list for Send Proxy Via Header In Request or Send Proxy Via Header In Response.Note: If you prefer to replace the host name with another string, instead of appending a string to the Via header, you must use an iRule or the command line.
Because the Via header includes the protocol name and version, applications are able to acquire this information for the various intermediate routers and use it, as necessary.
Via Header settings
This table describes controls and strings for Via Header settings in an HTTP profile.
|Send Proxy Via Header In Request||Remove||Specifies whether to Remove,
Preserve, or Append
Via headers included in a client request to an origin web server.
|Send Proxy Via Header In Response||Remove||Specifies whether to Remove,
Preserve, or Append
Via headers included in an origin web server response to
|Send Proxy Via Header Host Name||None||Specifies a string to append as a comment when sending a
Via header in a request to an origin web server or in
a response to a client.
Note: If you prefer to replace the host name with another string, instead of appending a string to the Via header, you must use an iRule or the command line.
X-Forwarded-For header acceptance
This setting enables or disables trusting the client IP address, and statistics from the client IP address, based on the request's X-Forwarded-For (XFF) headers, if they exist.
Alternate X-Forwarded-For headers
Specifies alternative XFF headers instead of the default X-Forwarded-For header. If you are specifying more than one alternative XFF header, separate the alternative XFF headers with a blank space, such as client1 proxyserver 22.214.171.124.
Server agent name
When you create an HTTP profile, you can specify the string used as the server name in traffic generated by the BIG-IP® system. The default value is BigIP.
There are some settings related to enforcement that you can configure to create an HTTP type of profile.
Allow truncated redirects
The Allow Truncated Redirect setting determines the way in which the BIG-IP® system passes through traffic, when a redirect that lacks the trailing carriage-return and line-feed pair at the end of the headers is parsed. The default is Disabled, which silently drops the invalid HTTP request.
Maximum header size
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.
Oversize client headers
The Oversize Client Headers setting determines the way in which the BIG-IP® system passes through HTTP traffic when the Maximum Header Size value is exceeded by the client. The default is disabled, which rejects the connection.
Oversize server headers
The Oversize Server Headers setting determines the way in which the BIG-IP® system passes through HTTP traffic when the Maximum Header Size value is exceeded by the server. The default is disabled, which rejects the connection.
Maximum header count
The Maximum Header Count setting determines the maximum number of headers in an HTTP request or response that the BIG-IP® system accepts. If a client or server sends a request or response with the number of headers exceeding the specified value, then the connection is dropped. The default value is 64.
Excess client headers
The Excess Client Headers setting specifies the way in which the BIG-IP® system passes through HTTP traffic when the Maximum Header Count value is exceeded by the client. The default is disabled, which rejects the connection.
Excess server headers
The Excess Server Headers setting specifies the way in which the BIG-IP® system passes through HTTP traffic when the Maximum Header Count value is exceeded by the server. The default is disabled, which rejects the connection.
Support for pipelining
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.
The Unknown Method setting determines the way in which the BIG-IP® system manages HTTP traffic when an unknown HTTP method is parsed. You can configure the Unknown Method setting to allow, reject, or pass through the HTTP traffic. The default is to allow unknown methods.
Explicit proxy settings
when you set the proxy mode to Explicit, you must also configure the settings in the Explicit Proxy area of the HTTP profile.
The DNS Resolver setting specifies the DNS resolver to use for DNS inquiries handled by the virtual servers associated with the HTTP explicit forward proxy profile you are creating.
You can configure an HTTP profile to specify the route domain that is used for outbound connect requests for the explicit forward proxy feature. The default route domain is 0.
The Tunnel Name setting specifies the tunnel that is used for outbound connect requests when the explicit forward proxy feature is used. Specifying a tunnel enables other virtual servers to receive connections initiated by the proxy service.
The Host Name setting specifies the name of hosts that should not be proxied when an explicit forward proxy is used.
Default Connect Handling
The Default Connect Handling setting specifies the behavior of the forward explicit proxy service when handling outbound requests. By default, this setting is disabled.
- Enabled (checked) indicates that outbound requests are delivered directly, regardless of the presence of listening virtual servers.
- Disabled (check box cleared) indicates that outbound requests are delivered only if another virtual server is listening on the tunnel for the requested outbound connection. With this setting, virtual servers are required, and the system processes the outbound traffic before it leaves the device.
Connection Failed Message
You can configure an http explicit forward proxy profile to specify the message that appears when a connection failure occurs. You can include TCL expressions.
DNS Lookup Failed Message
You can configure an http explicit forward proxy profile to specify the message that appears when a DNS lookup failure occurs. You can include TCL expressions.
Bad Request Message
You can configure an http explicit forward proxy profile to specify the message that appears when a bad request occurs. You can include TCL expressions.
Bad Response Message
You can configure an http explicit forward proxy profile to specify the message that appears when a bad response occurs. You can include TCL expressions.
You can configure the HTTP profile to use sFlow technology to monitor traffic passing through the BIG-IP system.
You can configure an HTTP profile to specify the maximum interval in seconds between two pollings. The default value is Default, which represents the value set on the System :: sFlow :: Global Settings :: http :: Properties screen. The initial default value is 10 seconds.
You can configure an HTTP profile to specify the ratio of packets observed to the samples generated. For example, a sampling rate of 2000 specifies that the system randomly generates 1 sample for every 2000 packets observed. The default value is Default, which represents the value set on the System :: sFlow :: Global Settings :: http :: Properties screen. The initial default value is 1024 packets.
About HTTP compression profiles
HTTP compression reduces the amount of data to be transmitted, thereby significantly reducing bandwidth usage. All of the tasks needed to configure HTTP compression on the BIG-IP® system, as well as the compression software itself, are centralized on the BIG-IP system. The tasks needed to configure HTTP compression for objects in an Application Acceleration Manager module policy node are available in the Application Acceleration Manager, but an HTTP compression profile must be enabled for them to function.
When configuring the BIG-IP system to compress data, you can:
- Configure the system to include or exclude certain types of data.
- Specify the levels of compression quality and speed that you want.
You can enable the HTTP compression option by setting the URI Compression or the Content Compression setting of the HTTP Compression profile to URI List or Content List, respectively. This causes the BIG-IP system to compress HTTP content for any responses in which the values that you specify in the URI List or Content List settings of an HTTP profile match the values of the Request-URI or Content-Type response headers.
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.
HTTP Compression profile options
You can use an HTTP Compression profile alone, or with the BIG-IP® Application Acceleration Manager, to reduce the amount of data to be transmitted, thereby significantly reducing bandwidth usage. The tasks needed to configure HTTP compression for objects in an Application Acceleration Manager policy node are available in the Application Acceleration Manager, but an HTTP Compression profile must be enabled for them to function.
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 (LTM®) 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 LTM to compress all .htm responses by typing the regular expression .*.htm. LTM then compares that response type to the URI specified within each client request, and if the system finds a match, takes some action.
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 (LTM®) 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 LTM 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.
Preferred compression methods
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.
Minimum content length for compression
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 (LTM®) 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, LTM 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, LTM compresses the response, regardless of size.
Compression buffer 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 (LTM®) buffers up to 4096 bytes of compressed data before deciding whether or not to preserve the connection and rewrite the Content-Length header.
The Local Traffic Manager decision to rewrite the Content-Length header depends on whether response chunking is enabled (using the Response Chunking profile setting).
About 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, 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.
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, Local Traffic Manager™ 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 select the check box.
About the Accept-Encoding header
Normally, when you enable HTTP compression, Local Traffic Manager™ strips out the Accept-Encoding header from the HTTP request. This causes Local Traffic Manager, instead of the target server, to perform the HTTP compression.
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 exists:
- 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.
About Web Acceleration profiles
When used by BIG-IP® Local Traffic Manager™ without other provisioned modules, the Web Acceleration profile uses basic default acceleration.
Web Acceleration profile settings
This table describes the Web Acceleration profile configuration settings and default values.
|Name||No default||Specifies the name of the profile.|
|Parent Profile||Selected predefined or user-defined profile||Specifies the selected predefined or user-defined profile.|
|Partition / Path||Common||Specifies the partition and path to the folder for the profile objects.|
This setting specifies the maximum size in megabytes (MB) reserved for the cache. When the cache reaches the maximum size, the system starts removing the oldest entries.
|Maximum Entries||10000||Specifies the maximum number of entries that can be in the cache.|
|Maximum Age||3600||Specifies how long in seconds that the system considers the cached content to be valid.|
|Minimum Object Size||500||Specifies the smallest object in bytes that the system considers eligible for caching.|
|Maximum Object Size||50000||Specifies the largest object in bytes that the system considers eligible for caching.|
|URI Caching||Not Configured||Specifies whether the system retains or excludes certain Uniform Resource Identifiers (URIs) in the 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.|
|URI List||No default value||Specifies the URIs that the system either includes in or excludes from caching.
|Ignore Headers||All||Specifies how the system processes client-side
Cache-Control headers when caching is enabled.
|Insert Age Header||Enabled||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 that the content has been in the cache.|
|Aging Rate||9||Specifies how quickly the system ages a cache entry. The aging rate ranges from 0 (slowest aging) to 10 (fastest aging).|
|AM Applications||No default||Lists enabled Application Acceleration Manager applications in the Enabled field and available applications in the Available field.|