The BIG-IP triggers an invalidations rule for a request, only when the following conditions exist.

• An invalidations rule is active.

  You can create invalidations rules and enable or disable them at any time.

• The invalidations rule contains a path parameter for both the Request Header Matching Criteria and the Cached Content to Invalidate settings.

  If you do not want to assign a specific path, you can use a single slash (/).

• The invalidations rule has reached its effective time.

  You can specify that invalidations rules are effective immediately, or you can set a time in the future.

• The BIG-IP has refreshed the cached content that corresponds to the request, before the effective date on the invalidations rule.

  This ensures that the BIG-IP module does not invalidate a compiled response more than once, under the same invalidations rule. A compiled response’s refresh time identifies the last time the BIG-IP refreshed that compiled response with content from the origin web server. If the compiled response was refreshed after the invalidations rule went into effect, the BIG-IP considers the content current.

• The request matches the configured request header matching criteria that you specified. The information that appears on the request must match all the HTTP request data type parameters that you specified for the Request Header Matching Criteria within the invalidations rule.

  For example, the following requests are candidates for invalidation for an invalidations rule that specifies, in the Request Header Matching Criteria, that the product query parameter must be Computers and that the path for the request must begin with /apps.

  http://www.somesite.com/apps/shop.jsp?action=show&product=Computers

  http://web1.somesite.com/apps/search/simple.jsp?product=Computers& category=desktop

  While the following requests are not candidates for invalidation.

  http://www.somesite.com/shop.jsp?action=show&product=Computers

  http://web1.somesite.com/apps/search/simple.jsp?product=Organizers& category=desktop

Invalidations rules are typically targeted at a range of compiled responses. The BIG-IP does not invalidate a compiled response until it matches a request to the invalidations rule for that compiled response, and it does not invalidate a range of compiled responses until it receives a request for each individual response in the range.

By assigning an appropriate lifetime for a rule, the BIG-IP ensures that it refreshes every targeted compiled response, before it discards the rule. The BIG-IP assigns the lifetime value for the invalidations rule by examining the maximum lifetime values set for all compiled responses targeted by the rule, and using the longest TTL value it finds. When the longest TTL value for the compiled responses is reached, the BIG-IP considers those compiled responses expired and refreshes them, even if an invalidation trigger has not occurred.

For example, if you created an invalidations rule for any requests that have either /apps or /srch in their path, your Policy Tree would include two nodes with application matching rules set so that requests with /apps in the path match to one node, and requests with /srch match to the other node. For this example, the /srch node has a lifetime rule specifying a maximum age of 15 minutes, while the /apps node uses the system’s maximum lifetime of 24 hours.

Compiled responses that the BIG-IP creates to service requests matching the /srch node have a maximum lifetime of 15 minutes. Compiled responses that the BIG-IP creates to service requests matching the /apps node uses a maximum lifetime of 24 hours. Based on this, the BIG-IP assigns a 24-hour lifetime for the invalidations rule.

During the 24 hours that the rule is in effect, the BIG-IP refreshes compiled responses either because they match an invalidations rule or because they have exceeded the set lifetime value. Either way, the BIG-IP refreshes any content matching the invalidations rule at least once before it discards the rule.

When configuring an invalidations rule, you must specify parameters for the following settings.

• Request Header Matching Criteria. You define the parameters that the BIG-IP must match in a request, in order to trigger the invalidations rule.
• Cached Content to Invalidate. You define the content to invalidate and refresh, if the BIG-IP finds the parameters in the HTTP request header that are specified in the Request Header Matching Criteria setting.

For the Request Header Matching Criteria setting, you specify the HTTP request data type parameter that the BIG-IP must find in an HTTP request header, in order to trigger the invalidations rule. For the BIG-IP to apply an invalidations rule, the HTTP request must match to a leaf node as well the associated parameters specified for the Request Header Matching Criteria setting.

Not all requests that match a node that you define will trigger the invalidations rule. You can define a subset of matching requests by specifying additional parameters for the source as part of the rule. Then, only the defined subset of requests trigger the invalidations rule.

For example, assume that to match to a particular node, a request must include /apps/shopping in the path and the query parameter cart must be present. To configure the Request Header Matching Criteria setting parameters for this node, you specify that a request must include the query parameter cart and the value of cart must equal Add. In this case, not all requests that match the node prompt the invalidation. The BIG-IP only invalidates requests where cart=add.

The BIG-IP only matches a request to an invalidation rule if it first finds the parameters set for the Request Header Matching Criteria setting. If it matches a request to the parameters configured for the Request Header Matching Criteria setting, only then does the BIG-IP review the parameters set for the Cached Content to Invalidate setting. If a match occurs, the BIG-IP invalidates the content specified, and retrieves fresh content from the origin web server. The BIG-IP stores the fresh content in cache and services the request. When configuring an invalidations rule, you must provide at least one parameter based on the Path data type for the Cached Content to Invalidate setting.