Default settings for the integrated cache

The NetScaler integrated cache feature provides built-in policies with default settings as well as initial settings for the Default content group. The information in this section defines the parameters for the built-in policies and Default content group.

Default caching policies

The integrated cache has built-in policies. The NetScaler appliance evaluates the policies in a particular order, as discussed in the following sections.

You can override these built-in policies with a user-defined policy that is bound to a request-time override or response-time override policy bank.

Note If you configured policies prior to release 9.0 and specified the -precedeDefRules parameter when binding the policies, they are automatically assigned to override-time bind points during migration.

View default policies

The built-in policy names start with an underscore (_). You can view the built-in policies from the command line and the administrative console using the show cache policy command.

Default request policies

You can override the following built-in request time policies by configuring new policies and binding them to the request-time override processing point. In the following policies, note that the MAY_NOCACHE action stipulates that the transaction is cached only when there is a user-configured or built-in CACHE directive at response time.

The following policies are bound to the _reqBuiltinDefaults policy label. They are listed in priority order.

Do not cache a response for a request that uses any method other than GET.

The policy name is _nonGetReq. The following is the policy rule:

!HTTP.REQ.METHOD.eq(GET)

Set a NOCACHE action for a request with header value that contains If-Match or If-Unmodified-Since.

The policy name is _advancedConditionalReq. The following is the policy rule:

HTTP.REQ.HEADER("If-Match").EXISTS || HTTP.REQ.HEADER("If-Unmodified-Since").EXISTS

Set a MAY_NOCACHE action for a request with the following header values: Cookie, Authorization, Proxy-authorization or a request which contains the NTLM or Negotiate header.

The policy name is _personalizedReq. The following is the policy rule:

HTTP.REQ.HEADER("Cookie").EXISTS || HTTP.REQ.HEADER("Authorization").EXISTS || HTTP.REQ.HEADER("Proxy-Authorization").EXISTS || HTTP.REQ.IS_NTLM_OR_NEGOTIATE

Default response policies

You can override the following default response-time policies by configuring new policies and binding them to the response-time override processing point.

The following policies are bound to the _resBuiltinDefaults policy label and are evaluated in the order in which they are listed:

  1. Do not cache HTTP responses unless they are of type 200, 304, 307, 203 or if the types are between 400 and 499 or between 300 and 302.

    The policy name is _uncacheableStatusRes. The following is the policy rule:

    !((HTTP.RES.STATUS.EQ(200)) || (HTTP.RES.STATUS.EQ(304)) || (HTTP.RES.STATUS.BETWEEN(400,499)) || (HTTP.RES.STATUS.BETWEEN(300, 302)) || (HTTP.RES.STATUS.EQ(307))|| (HTTP.RES.STATUS.EQ(203)))

  2. Do not cache an HTTP response if it has a Vary header with a value of anything other than Accept-Encoding.

    The compression module inserts the Vary: Accept_Encoding header. The name of this expression is _uncacheableVaryRes. The following is the policy rule:

    ((HTTP.RES.HEADER("Vary").EXISTS) && ((HTTP.RES.HEADER("Vary").INSTANCE(1).LENGTH > 0) || (!HTTP.RES.HEADER("Vary").STRIP_END\_WS.SET_TEXT_MODE(IGNORECASE).eq("Accept-Encoding"))))

  3. Do not cache a response if its Cache-Control header value is No-Cache, No-Store, or Private, or if the Cache-Control header is not valid.

    The policy name is _uncacheableCacheControlRes. The following is the policy rule:

    ((HTTP.RES.CACHE\_CONTROL.IS\_PRIVATE) || (HTTP.RES.CACHE\_CONTROL.IS\_NO\_CACHE) || (HTTP.RES.CACHE\_CONTROL.IS\_NO\_STORE) || (HTTP.RES.CACHE\_CONTROL.IS\_INVALID))

  4. Cache responses if the Cache-Control header has one of the following values: Public, Must-Revalidate, Proxy-Revalidate, Max-Age, S-Maxage.

    The policy name is _cacheableCacheControlRes. The following is the policy rule:

    ((HTTP.RES.CACHE_CONTROL.IS_PUBLIC) || (HTTP.RES.CACHE_CONTROL.IS_MAX_AGE) || (HTTP.RES.CACHE_CONTROL.IS_MUST_REVALIDATE) || (HTTP.RES.CACHE_CONTROL.IS_PROXY_REVALIDATE) || (HTTP.RES.CACHE_CONTROL.IS_S_MAXAGE))

  5. Do not cache responses that contain a Pragma header.

    The name of the policy is _uncacheablePragmaRes. The following is the policy rule:

    HTTP.RES.HEADER("Pragma").EXISTS

  6. Cache responses that contain an Expires header.

    The name of the policy is _cacheableExpiryRes. The following is the policy rule:

    HTTP.RES.HEADER("Expires").EXISTS

  7. If the response contains a Content-Type header with a value of Image, remove any cookies in the header and cache it.

    The name of the policy is _imageRes. The following is the policy rule:

    HTTP.RES.HEADER("Content-Type").SET_TEXT_MODE(IGNORECASE).STARTSWITH("image/")

    You could configure the following content group to work with this policy:

    add cache contentgroup nocookie -group -removeCookies YES

  8. Do not cache a response that contains a Set-Cookie header.

    The name of the policy is _ personalizedRes. The following is the policy rule:

    HTTP.RES.HEADER(“Set-Cookie”).EXISTS   HTTP.RES.HEADER(“Set-Cookie2”).EXISTS

Restrictions on default policies

You cannot override the following built-in request time policies with user-defined policies.

These policies are listed in priority order.

  1. Do not cache any responses if the corresponding HTTP request lacks a GET or POST method.
  2. Do not cache any responses for a request if the HTTP request URL length plus host name exceeds 1744 byes.
  3. Do not cache a response for a request that contains an If-Match header.
  4. Do not cache a request that contains an If-Unmodified-Since header.

Note This is different from the If-Modified-Since header.

5. Do not cache a response if the server does not set an expiry header.

You cannot override the following built-in response time policies. These policies are evaluated in the order in which they are listed:

  1. Do not cache responses that have an HTTP response status code of 201, 202, 204, 205, or 206.
  2. Do not cache responses that have an HTTP response status code of 4xx, with the exceptions of status codes 403, 404, and 410.
  3. Do not cache responses if the response type is FIN terminated, or the response does not have one of the following attributes: Content-Length, or Transfer-Encoding: Chunked.
  4. Do not cache the response if the caching module cannot parse its Cache-Control header.

Initial settings for the default content group

When you first enable integrated caching, the NetScaler appliance provides one predefined content group named the Default content group. The following table shows the settings for this group. |Parameter|Description|Default Value| |— |— |— | |Hit parameters|The hit parameters contain the parameter names that are significant for generating a response. In parameterized hit selection, NetScaler appliance matches the URL stem byte-for-byte, matches normalized values of the hit parameters, and matches the target service information.|none| |Invalidation Parameters|These parameters mark a cached object as obsolete during parameterized selection. Specific objects, or all objects in a content group, are selected if the values of the invalidation parameters in the object and in the request are same after normalization. The invalidation parameters are a subset of the hit parameters.|none| |Poll Every Time|Poll every time for the objects in this content group.|NO| |Ignore reload request|Specifies whether a request can force the system to reload a cached object from the origin. To guard against Denial of Service attacks, you must set this flag to YES. To get RFC-compliant behavior you should set it to NO.|YES| |Remove Response Cookies|If this option is disabled for a content group, and if the response contains cookies, the cookies are stored and served with every cache hit. By default, the remove cookies option is enabled for a content group, to prevent the integrated cache from storing any responses with Set-Cookie or Set-Cookie2 headers unless the response is an image.|YES| |Prefetch|The Prefetch option refreshes an object when it is about to expire. This ensures that the object remains stale or inactive (and therefore it cannot be served) for a shorter duration of time.|YES| |Prefetch period|This duration in seconds during which prefetch should be attempted, immediately before the object’s calculated expiry time.|heuristic| |Maximum outstanding prefetches|The number of items that can be subjected to a prefetch at a time.|4294967295| |Flashcache|Determines whether to enable queuing of client requests and simultaneous distribution of responses to all clients in the queue.|NO| |Expire at last byte|Determines whether to expire a cached response immediately after serving it.|NO| |Insert Via header|Defines a string to be inserted in a Via header. By default, a Via header is inserted in all responses served from a content group. The Via header is not inserted for responses that are served by the origin server.|YES| |Insert Age header|The Age header contains information about the age of the object in seconds as calculated by the integrated cache.|YES| |Insert ETag header|With ETag header insertion, the integrated cache does not serve full responses on repeat requests. This is done by forcing the user agent to cache the dynamic response sent by the cache the first time.|YES| |Cache-control header|You can enable caching of dynamic objects in the user agent by replacing the Cache-Control headers that are inserted by the origin server. You must configure the new Cache-Control header to be inserted in the content group.|NONE| |Quick abort size|If the size of an object that is being downloaded is less than or equal to the quick abort value, and a client aborts during the download, the cache stops downloading the response. If the object is larger than the quick abort size, the cache continues to download the response.|4194303 KBytes (maximum)| |Minimum Response Size|You can control memory use by setting a minimum response size. Cached objects must be larger than the minimum response size.|0 KBytes| |Maximum Response Size|You can control memory use by setting a maximum response size. Cached objects must be smaller than the maximum response size.|80 KBytes| |Memory usage limit|Sets the maximum amount of memory that the cache can use. The effective limit is based on the available memory of the NetScaler appliance. The minimum value is 0 and the maximum value is unlimited.|UNLIMITED| |Ignore caching headers in request|Disregards Cache-Control and Pragma headers in HTTP requests.|YES| |MinHits configured|Number of hits that are required to qualify a response for storage in this content group.|0| |Always evaluate policies|NO| |Pinned|By default, when the cache is full the NetScaler appliance replaces the least recently used response first. The NetScaler appliance does not apply this behavior to content groups that are marked as pinned.|NO| |Lazy DNS resolution|If set to YES, DNS resolution is performed for responses only if the destination IP address in the request does not match the destination IP address of the cached response.|YES|