Configuring Cache Parameter Settings

Caching of Authenticated Content

The authenticated data caching feature allows basic and NT LAN Manager (NTLM) authenticated content to be cached and served to more than one user, while maintaining security. If an authenticated object is cached, then subsequent requests for that object (from new users) require authentication. The cached object is revalidated with the origin server through the authorization header for the new user. If the user is not authorized, the server sends a 401 (Unauthorized) response. If the user is authorized and the object is not modified, the cached object is served to the client. See the "NTLM Authentication" section for further information on NTLM authentication.

This example enables caching of basic and NTLM authenticated content:

Console(config)# http cache-authenticated all

 
Console(config)# show http cache-authenticated all

Basic authenticated objects are cached.
NTLM authenticated objects are cached.

Cache Freshness

The ACNS software Cache application can be tuned to balance HTTP and FTP object freshness with cache hit rate. The Cache application default parameters are weighted to ensure fresh content over maximizing the cache hit rate (to avoid the undesirable scenario of increasing the cache hit rate by serving stale content).

Table 6-1 explains the cache freshness features.

Table 6-1: Cache Freshness Settings

Configurable Cache Freshness Feature	Function
Minimum Time to Live Maximum Time to Live	Limits duration of objects in the cache.
Age multiplier	Determines at what percentage of an object's maximum Time To Live the Cache application issues an if-modified-since (IMS) request to the origin web server to validate the freshness of the object.
Revaluate each request	Forces the Cache application to revalidate all requests to the origin web server using an IMS request. The reval-each-request option enables the Content Engine to revalidate all objects requested from the cache, text objects only, or none at all.
Serve-IMS	Controls the ability of the cache to answer authoritatively on receiving an IMS request from the web browser.

Minimum and Maximum Time To Live Settings

The minimum and maximum Time To Live (TTL) settings permit the administrator to limit the duration of HTTP and FTP objects in the cache. By default, HTTP cacheable objects are kept for 5 minutes minimum and 3 to 7 days maximum (3 days for text-type objects, 7 days for binary). If an object is marked with expiry information from the web server different from the administrator settings, then the web server values take precedence.

For HTTP and FTP objects, use the http min-ttl and ftp min-ttl global configuration commands to set the minimum Time To Live, and the http max-ttl and ftp max-ttl command to set maximum Time To Live. The command syntax is as follows:

ftp max-ttl days directory-listing dlmax_days file fmax_days

ftp max-ttl hours directory-listing dlmax_hours file fmax_hours

ftp max-ttl minutes directory-listing dlmax_ min file fmax_min

ftp max-ttl seconds directory-listing dlmax_ sec file fmax_sec

ftp min-ttl min_minutes

http max-ttl days text textdays binary bindays

http max-ttl hours text texthours binary binhours

http max-ttl minutes text textminutes binary binminutes

http max-ttl seconds text textseconds binary binseconds

http min-ttl minutes

The following example configures the Cache application to keep HTTP and FTP objects in the cache for a minimum of 10 minutes, and a maximum of 24 hours (1 day).

ContentEngine(config)# http min-ttl 10

ContentEngine(config)# ftp min-ttl 10

ContentEngine(config)# http max-ttl days text 1 binary 1

ContentEngine(config)# ftp max-ttl hours directory-listing 24 file 24

Caching of Binary Content with Cookies

The Cache application can cache binary objects that were served with cookies attached. Use the
http cache-cookies global configuration command to enable this feature.

The following example enables caching of binary content with cookies attached.

ContentEngine(config)# http cache-cookies

ContentEngine(config)#

Maximum Object Size

The Cache application can specify the maximum size of an FTP or HTTP object that can be stored in the cache. The maximum size limit for both an FTP object, and an HTTP object size is 204,799 kilobytes.

The following example sets the maximum size for an HTTP object as 500 kilobytes, and the maximum FTP object size as 2 megabytes.

ContentEngine(config)# ftp object max-size 2000
ContentEngine(config)# http object max-size 500

Aborting Selected Objects

The http cache-on-abort command provides user-defined thresholds to determine whether or not the Content Engine will complete the download of an object when the client has aborted the request. When the download of an object is aborted before it is completed, the object is not stored on the Content Engine or counted in the hit-rate statistics. Typically, a client aborts a download by clicking the Stop icon on the browser, or by closing the browser during a download.

If the http cache-on-abort command is enabled, the Content Engine will use a selective algorithm to determine whether to continue to cache an object if the client has aborted the request. If disabled, the Content Engine will always continue to download an object to the cache even if a client has aborted the request.

If the http cache-on-abort min-threshold command is used, the Content Engine will continue to cache an object if the number of kilobytes remaining to download from the server is less than or equal to the Minimum Threshold value. The default value is 32 KB.

If the http cache-on-abort max-threshold command is used, the Content Engine will not continue to cache an object if the number of kilobytes remaining to download from the server is greater than the Maximum Threshold value. The default value is 256 KB.

If the http cache-on-abort percent command is used, the Content Engine will continue to cache an object if the percentage of the object already downloaded is greater than the Percentage Threshold value. The default value is 80 percent.

Note Any combination of thresholds can be specified. They are used in the order shown above. If the http cache-on-abort command is enabled and all http cache-on-abort thresholds are disabled, then the Content Engine always aborts downloading an object to the cache. If the Content Engine determines that there is another client currently requesting the same object, downloading is not aborted. The Content Engine only applies those thresholds that have been enabled.

In this example, the Content Engine is configured to always continue downloading an object to the cache:

ContentEngine(config)# no http cache-on-abort

In this example, the Content Engine is configured to use the default minimum threshold when the cache-on-abort option has been enabled, and the threshold is set to 16 kilobytes:

ContentEngine(config)# http cache-on-abort min 16

In this example, the Content Engine is configured to not consider the minimum threshold:

ContentEngine(config)# no http cache-on-abort min

The cache-on-abort max-threshold and percent thresholds are configured like the minimum threshold shown in the examples.

Caching of HTTP Range Requests

The Content Engine serves HTTP Range requests that include a Range header requesting the specified range of the object instead of the whole object from the cache if the requested range exists in the Content Engine cache. Specifically, the Content Engine handles Range requests with the following logic:

lookup the object in the cache; 
if object in the cache 
{ 
            check whether the requested ranges are in the cache; 
            if the requested ranges are in cache then serve the request from cache; 
            else pipe through the request; 
} 
else pipe through the request;

If a client has a partial copy of an entity in its cache and wishes to have an up-to-date copy of the entire entity in its cache, it could use the Range request header with a conditional GET request (using either or both If-Unmodified-Since and If-Match.) However, if the condition fails because the entity has been modified, the client would then have to make a second request to obtain the entire current entity.

The If-Range header allows a client to short-circuit the second request. Informally, the meaning of this header is "If the entity is unchanged, send me the part(s) that I am missing; otherwise, send me the entire new entity."

If-Range = "If-Range" ":" ( entity-tag | HTTP-date )

An If-Range request from the client will be handled by the cache as follows:

lookup the object in the cache; 
if (object is in the cache 
    AND requested ranges are in the cache; 
    AND entity tag given in the If-Range header 
            matches cached object's entity-tag){
        serve partial request from the cache
} else {

connect to remote server
retrieve requested range, send data to client

If the If-Range header has a valid HTTP date instead of an entity tag, then the HTTP date is matched with the Last-Modified date of the cached object.

If the client has no entity tag for an entity but does have a Last-Modified date, it may use that date in an If-Range header. The If-Range header should only be used together with a Range header, and must be ignored if the request does not include a Range header, or if the server does not support subrange operation.

If the entity tag given in the If-Range header matches the current entity tag for the entity, then the server should provide the specified subrange of the entity using a 206 (Partial content) response. If the entity tag does not match, then the server should return the entire entity using a 200 (OK) response.

Note The http cache-on-abort feature must be disabled for the caching of HTTP range requests to occur. Some client applications close the server connection immediately after receiving the response header for the normal GET request (for example, to a PDF file). If the http cache-on-abort command is enabled, later Range requests to that object will not be cacheable.