11
Sending Invalidation Requests

This chapter explains how to send invalidation requests to OracleAS Web Cache.

This chapter contains these topics:

Invalidation from External Sources

To invalidate documents in the cache, send an HTTP POST message from the invalidator or administrator account through an invalidation listening port.

The invalidator account is an administrator authorized to send invalidation messages. In a cache hierarchy of OracleAS Web Cache servers, the central cache or provider cache uses the invalidator account name and password of the remote or subscriber OracleAS Web Cache server. The invalidation request specifies the documents to invalidate, as well as the site host name of the documents. The site host name is compared with the IP address of the cache from which the invalidation request propagated. If there is a match, the cache processes the invalidation request. Otherwise, the request is rejected.

While the administrator typically sends configuration and operational requests to OracleAS Web Cache, it can also send invalidation requests. Because the administrator account is authorized with more privileges than the invalidator account, an invalidation request sent by an administrator account does not need to specify the site host name. Invalidation messages sent with OracleAS Web Cache Manager use the administrator account.

Note:
For automatic propagation of invalidation messages, OracleAS Web Cache passes the encoded invalidator password in the page request between the central and remote cache or the provider and subscriber cache during the hierarchy registration process. This HTTP traffic is susceptible to network sniffing. If the network is unprotected and insecure, configure HTTPS ports as follows:

In the Listen Ports page (Ports > Listen Ports) of the central or provider cache, disable the default HTTP port and configure an HTTPS port in its place. See "Task 6: Configure OracleAS Web Cache with Listening Ports for Incoming Browser Requests".

In the Operations Ports page (Ports > Operations Ports) of the remote or subscriber cache, disable the default HTTP port for invalidation and configure an HTTPS port in its place. See "Task 8: Configure OracleAS Web Cache with Operations Ports".

See Also:
"Invalidation in Hierarchies"

Invalidation requests are HTTP POST requests written in Extensible Markup Language (XML) syntax. The contents of the XML request body instructs the cache which URLs to mark as invalid. As shown in Figure 11-1, invalidation requests can be sent using one of the following methods:

Manually, using either OracleAS Web Cache Manager or telnet
Automatically, using database triggers, scripts, or application logic

Figure 11-1 Invalidation

Text description of owcag025.gif follows

Text description of the illustration owcag025.gif

This section describes how to send invalidation requests using one of the following methods:

Using Telnet to Send Invalidation Requests

When you send an invalidation request with an HTTP POST request, you specify the host name of OracleAS Web Cache, the invalidation listening port number, and the invalidation request.

For example, if you are using telnet, you send an invalidation request using the following procedure:

Connect to OracleAS Web Cache at the invalidation listening port:
```
telnet web_cache_host invalidation_port
```

Specify a POST message header and authenticate the invalidator account using Base64 encoding string with the following syntax:

POST /x-oracle-cache-invalidate http/1.0|1
Authorization: BASIC <base64 encoding of invalidator:invalidator_password> 
content-length:#bytes

The following shows an example of the Authorization line:

Authorization: BASIC aW52YWxpZGF0b3I6aW52YWxpZGF0b3I=

In this example, aW52YWxpZGF0b3I6aW52YWxpZGF0b3I= is the invalidator user name and password (invalidator:invalidator) encoded.

See Also:

http://www.rfc-editor.org/ for information about password Base64 encoding

readme.examples.html in the $ORACLE_HOME/webcache/docs directory on UNIX and ORACLE_HOME\webcache\docs directory on Windows for further information about using the EncodeBase64.java script to generate the Base64 string for invalidator:invalidator_password

"Task 2: Modify Security Settings" for further information about changing the invalidation password

Enter one carriage return.
Send the invalidation request with XML syntax.

Invalidation request syntax is described in the following sections:

Invalidation Request Syntax

Use the following syntax to invalidate documents contained within an exact URL that includes the complete path and file name:

<?xml version="1.0"?>
<!DOCTYPE INVALIDATION SYSTEM "internal:///WCSinvalidation.dtd">
<INVALIDATION VERSION="WCS-1.1">
   <SYSTEM>
    <SYSTEMINFO NAME="name" VALUE="value"/>
   </SYSTEM>  
   <OBJECT>
     <BASICSELECTOR URI="URL"/>
     <ACTION REMOVALTTL="TTL"/>
     <INFO VALUE="value"/>
   </OBJECT>
</INVALIDATION>

Use the following syntax to invalidate documents based on more advanced invalidation selectors:

<?xml version="1.0"?>
<!DOCTYPE INVALIDATION SYSTEM "internal:///WCSinvalidation.dtd">
<INVALIDATION VERSION="WCS-1.1">
   <SYSTEM>
    <SYSTEMINFO NAME="name" VALUE="value"/>
   </SYSTEM>  
   <OBJECT>
     <ADVANCEDSELECTOR URIPREFIX="prefix"
                       URIEXP="URL_expression"
                       HOST="host_name:port"
                       METHOD="HTTP_request_method"
                       BODYEXP="HTTP_body"/>
       <COOKIE NAME="cookie_name" VALUE="value"/>
       <HEADER NAME="HTTP_request_header" VALUE="value"/>
       <OTHER NAME="URI|BODY|QUERYSTRING_PARAMETER|SEARCHKEY"
             TYPE="SUBSTRING|REGEX"
             VALUE="value"/>
     </ADVANCEDSELECTOR>
     <ACTION REMOVALTTL="TTL"/>
     <INFO VALUE="value"/>
   </OBJECT>
</INVALIDATION>

The body of a valid invalidation request must begin with the following:

<?xml version="1.0"?>
<!DOCTYPE INVALIDATION SYSTEM "internal:///WCSinvalidation.dtd">

The first line denotes version 1.0 of XML. The second line denotes that the request is an invalidation request using the WCSinvalidation.dtd file as the XML document type. WCSinvalidation.dtd is the Document Type Definition (DTD) that defines the grammar of invalidation requests and responses.

Note the following:

No white space is allowed before "<?xml".
If an application is sharing invalidation requests with a third-party XML parser, replace "internal:///WCSinvalidation.dtd" with the following path:
```
"http://www.oracle.com/webcache/90400/WCSinvalidation.dtd"
```

The root element INVALIDATION contains one or more of the attributes and elements described in Table 11-1.

Table 11-1 INVALIDATION Elements and Attributes

Invalidation Element/Attribute	Description
`VERSION` attribute	Required attribute in the `INVALIDATION` element Denote the version of the `WCSinvalidation.dtd` file to use as the XML document type. For versions 9.0.`x`, always use `VERSION=`"`WCS-1.1`", unless you require previous existing applications to remain unchanged. For these applications, you can use `VERSION=`"`WCS-1.0`", but the new invalidation functionality will not be available.
`SYSTEM` element	Optional element in the `INVALIDATION` element. The `SYSTEM` element requires the `SYSTEMINFO` element.
`SYSTEMINFO` element	Required element in the `SYSTEM` element The possible `NAME`/`VALUE` pairs are: `NAME=`"`WCS_PROPAGATE`" `VALUE=`"`TRUE\|FALSE`" This pair specifies whether or not invalidation requests are propagated to cache cluster members. If `WCS_PROPAGATE` is `TRUE`, it overrides the setting for invalidation propagation in the configuration. If `WCS_PROPAGATE` is `FALSE`, it uses the setting specified in the configuration. The default is `FALSE`. `NAME=`"`WCS_DISCONNECTED_MODE_OK`" `VALUE=`"`TRUE\|FALSE`" This pair specifies how soon invalidation takes place. If `WCS_DISCONNECTED_MODE_OK` is `TRUE`, invalidation is not immediately performed. The invalidation response is sent as soon as the invalidation request is received. Set this element to `TRUE`, if you do not want to wait for the invalidation result. If `WCS_DISCONNECTED_MODE_OK` is `FALSE`, invalidation is completed immediately and the invalidation result is sent. The default is `FALSE`.
`OBJECT` element	Required element in the invalidation request. You can specify more than one `OBJECT` element in the request.
`BASICSELECTOR` element	`URI` attribute: Required attribute of the `BASICSELECTOR` element. Specify the URL of the documents to be invalidated. Use one of the following formats: `http://``host_name``:``port``/``path``/``filename` `https://``host_name``:``port``/``path``/``filename` `host_name``:``port` is not required if the `administrator` account is sending the request.
`ADVANCEDSELECTOR` element	`URIPREFIX` attribute: Required attribute of the `ADVANCEDSELECTOR` element. Specify the path prefix of the documents to be invalidated. The path prefix must begin with `http\|https://``host_name``:``port``/``path``/``filename` or "`/`" and end with "`/`". `host_name``:``port` is required if the `HOST` attribute is not specified and the `invalidator` account is sending the request. The prefix is interpreted literally, including reserved regular expression characters. These characters include periods (`.`), question marks (`?`), asterisks (`*`), brackets (`[]`), curly braces (`{}`), carets (`^`), dollar signs (`$`), and backslashes (`\`).
	`URIEXP` attribute: Optional attribute of the `ADVANCEDSELECTOR` element. Specify the URL of the documents to be invalidated underneath the `URIPREFIX`. If no value is entered, everything under the `URIPREFIX` will be matched. Regular expression characters are permitted. To interpret these characters literally, escape them with a backslash (`\`). Notes: The request URL that browsers send to OracleAS Web Cache and the URL that OracleAS Web Cache uses internally for that request are different. When OracleAS Web Cache serves a page request, it alphabetically sorts any embedded URL parameters of the URL. However, the invalidation requests are matched against only the internal representation of the URL in which any embedded URL parameters are sorted. To ensure invalidation requests are matched correctly, sort and enter the embedded URL parameters alphabetically. When the invalidation request is sent, OracleAS Web Cache performs a regular expression match of `URIEXP`. This can take processing time. As an alternative, you can use the `OTHER` element to specify a substring match rather than a regular expression match.
	`HOST` attribute: This attribute is required if the `URIPREFIX` value does not include `host_name``:``port` and the `invalidator` account is sending the request. Specify the host name and port number of the site (`host_name``:``port`). Port 80 is the default port for HTTP.
	`METHOD` attribute: Optional attribute of the `ADVANCEDSELECTOR` element. Specify HTTP request method (`GET` or `POST`) of the documents to be invalidated. `GET` is the default value.
	`BODYEXP` attribute: Optional attribute of the `ADVANCEDSELECTOR` element. If the `METHOD` is `POST`, specify HTTP `POST` body of the documents to be invalidated. Note: When the invalidation request is sent, OracleAS Web Cache performs a regular expression match of `BODYEXP`. This can take processing time. As an alternative, you can use the `OTHER` element to specify a substring match rather than a regular expression match.
`COOKIE` element	Optional element in the invalidation request. Use the following attributes: `NAME` attribute: Required attribute for the `COOKIE` element attribute. Specify the cookie name to invalidate documents based on the cookie. `VALUE` attribute: Optional attribute for the `COOKIE` element. Specify the value of the cookie. If no value is present, only documents with the named cookie but without a value are invalidated.
`HEADER` element	Optional element in the invalidation request. Use the following attributes: `NAME` attribute: Required attribute for the `HEADER` element. Specify the HTTP request header and its value to invalidate based on the request header. `VALUE` attribute: Optional attribute for the `HEADER` element. Specify the value of the header.
`OTHER` element	Optional element in the invalidation request. Use the following attributes: `NAME` attribute: Required attribute of the `OTHER` element. `NAME` supports the following values: - `URI` to specify a match of the URL underneath the `URIPREFIX` - `BODY` to specify a match of the HTTP `POST` body - `QUERYSTRING_PARAMETER` to specify a match of an embedded URL parameter - `SEARCHKEY` to specify a match of a search key in the `Surrogate-Key` response header `TYPE` attribute: Required attribute for `URI`, `BODY`, and `QUERYSTRING_PARAMETER`. This attribute is not recognized for `SEARCHKEY`. `TYPE` supports the following values: - `SUBSTRING` to specify an exact string match for `QUERYSTRING_PARAMETER` and a substring match for `URI` and `BODY`. - `REGEX` to specify a regular expression match `VALUE` attribute: Required attribute for `URI`, `BODY`, `QUERYSTRING_PARAMETER`, and `SEARCHKEY`. Specify the value of `URI`, `BODY`, `QUERYSTRING_PARAMETER`, or `SEARCHKEY`. If you specify a `TYPE` of `REGEX`, then escape regular expression characters that you want to interpreted literally with a backslash (`\`). See Also: "Invalidation Examples" to optimize advanced invalidations "Using Search Keys in Surrogate-Key Response Header and Invalidation Requests" to configure search keys
`ACTION` element	Required element in the invalidation request `REMOVALTTL` attribute Optional attribute of the `ACTION` element. Specify the maximum time that documents can reside in the cache before they are invalidated. The default is 0 seconds.
`INFO` element	Optional element in the invalidation request `VALUE` attribute Required attribute of the `INFO` element. Specify a comment to be included in the invalidation result. After the invalidation request is complete, the message that contains the comment, along with the result of the invalidation, is written to the event log: [13/Dec/2002:19:26:46 +0000] [notification 11748] [invalidation] [ecid: 21085932167,0] Invalidation with INFO 'INFO_comment' has returned with status 'status'; number of documents invalidated: 'number'.

Note:
The following special XML characters must be escaped in the fields: ampersand (&) with "&", greater than sign (>) with "&gt", less than sign (<) with "&lt", double quotes (") with "&quot", and single quotes (') with "'".

Note:
OracleAS Web Cache continues to support invalidation requests sent in the following release 1.0 format:
<?xml version="1.0"?> <!DOCTYPE INVALIDATION SYSTEM "internal:///invalidation.dtd"> <INVALIDATION> <URL EXP="URL" PREFIX="YES|NO"> <VALIDITY LEVEL="validity" REFRESHTIME="seconds"/> <COOKIE NAME="cookie_name" VALUE="value" NONEXIST="YES|NO"/> <HEADER NAME="HTTP_request_header" VALUE="value"/> </URL> </INVALIDATION>

See Also:
"Invalidation Request and Response DTD" for further information about invalidation request syntax

Invalidation Response Syntax

Invalidation responses are returned in the following format for BASICSELECTOR invalidation requests:

<?xml version="1.0"?> 
<!DOCTYPE INVALIDATIONRESULT SYSTEM "internal:///WCSinvalidation.dtd">
<INVALIDATIONRESULT VERSION="WCS-1.1">
   <SYSTEM>
     <SYSTEMINFO NAME="name" VALUE="value"/>
   </SYSTEM>  
   <OBJECTRESULT>
     <BASICSELECTOR URI="URL">
     </BASICSELECTOR>
     <RESULT ID="ID" STATUS="status" NUMINV="number"/>
     <INFO VALUE="value"/>
   </OBJECTRESULT>
</INVALIDATIONRESULT>

Invalidation responses are returned in the following format for ADVANCEDSELECTOR invalidation requests:

<?xml version="1.0"?> 
<!DOCTYPE INVALIDATIONRESULT SYSTEM "internal:///WCSinvalidation.dtd">
<INVALIDATIONRESULT VERSION="WCS-1.1">
   <SYSTEM>
     <SYSTEMINFO NAME="name" VALUE="value"/>
   </SYSTEM>  
   <OBJECTRESULT>
    <ADVANCEDSELECTOR URIPREFIX="prefix"
                      URIEXP="URL_expression"
                      HOST="host_name:port"
                      METHOD="HTTP_request_method"
                      BODYEXP="HTTP_body"/>
      <COOKIE NAME="cookie_name" VALUE="value"/>
      <HEADER NAME="HTTP_request_header" VALUE="value"/>
      <OTHER NAME="URI|BODY|QUERYSTRING_PARAMETER|SEARCHKEY"
             TYPE="SUBSTRING|REGEX"
             VALUE="value"/>
     </ADVANCEDSELECTOR>
     <RESULT ID="ID" STATUS="status" NUMINV="number"/>
     <INFO VALUE="value"/>
   </OBJECTRESULT>
</INVALIDATIONRESULT>

The body of a valid invalidation response begins with the following:

<?xml version="1.0"?>
<!DOCTYPE INVALIDATIONRESULT SYSTEM "internal:///WCSinvalidation.dtd">

The first line denotes version 1.0 of XML. The second line denotes the response is an invalidation response using the WCSinvalidation.dtd file as the XML document type.

The root element INVALIDATIONRESULT contains one or more of the attributes and elements described in Table 11-2. BASICSELECTOR and ADVANCEDSELECTOR are described in Table 11-1 .

Table 11-2 INVALIDATIONRESULT Elements and Attributes

Invalidation Element/Attribute	Description
`VERSION` attribute	Version number of the `WCSinvalidation.dtd` file to use as the XML document type
`SYSTEM` element	Optional element in the `INVALIDATIONRESULT` element. The `SYSTEM` element is optional. The `SYSTEM` element requires the `SYSTEMINFO` element.
`SYSTEMINFO` element	Required element in the `SYSTEM` element The possible `NAME`/`VALUE` pairs are as follows: `NAME=`"`WCS_CACHE_NAME`" `VALUE=`"`string`" This pair specifies the name of the cache. `NAME=`"`WCS_DISCONNECTED_MODE_OK`" `VALUE=`"`TRUE\|FALSE`" This pair specifies how soon invalidation takes place. If `WCS_DISCONNECTED_MODE_OK` is `TRUE`, invalidation is not immediately performed. The invalidation response is sent as soon as the invalidation request is received. Set this element to `TRUE`, if you do not want to wait for the invalidation result. If `WCS_DISCONNECTED_MODE_OK` is `FALSE`, invalidation is completed immediately and the invalidation result is sent. The default is `FALSE`.
`RESULT` element	`Use the following attributes:` `ID` attribute: Sequence number of all the invalidation objects sent in the invalidation response. If there are multiple selectors specified in the invalidation request, the sequence number starts at 1 for the first URL and continues sequentially for each additional selector. `STATUS` attribute: Status of the invalidation. Status is one of the following: - `SUCCESS` for successful invalidations - `URI NOT CACHEABLE` for documents that are not cacheable - `URI NOT FOUND` for documents not found `NUMINV` attribute: Number of documents invalidated during the invalidation request
`INFO` element	Returns the comment specified in the `INFO` element of the invalidation request

See Also:
"Invalidation Request and Response DTD" for further information about invalidation response syntax

Invalidation Preview Request Syntax

To test invalidation, use the following syntax to preview the list of BASICSELECTOR documents to be invalidated:

<?xml version="1.0"?>
<!DOCTYPE INVALIDATIONPREVIEW SYSTEM "internal:///WCSinvalidation.dtd">
<INVALIDATIONPREVIEW VERSION="WCS-1.1" STARTNUM="start_number" MAXNUM="max_
number">
     <BASICSELECTOR URI="URL"/>
</INVALIDATIONPREVIEW>

Use the following syntax to preview the list of ADVANCEDSELECTOR documents to be invalidated:

<?xml version="1.0"?>
<!DOCTYPE INVALIDATIONPREVIEW SYSTEM "internal:///WCSinvalidation.dtd">
<INVALIDATIONPREVIEW VERSION="WCS-1.1" STARTNUM="start_number" MAXNUM="max_
number">
    <ADVANCEDSELECTOR URIPREFIX="prefix"
                      URIEXP="URL_expression"
                      HOST="host_name:port"
                      METHOD="HTTP_request_method"
                      BODYEXP="HTTP_body"
      <COOKIE NAME="cookie_name" VALUE="value"/>
      <HEADER NAME="HTTP_request_header" VALUE="value"/>
      <OTHER NAME="URI|BODY|QUERYSTRING_PARAMETER|SEARCHKEY"  
             TYPE="SUBSTRING|REGEX"
             VALUE="value"/>
    </ADVANCEDSELECTOR>
</INVALIDATIONPREVIEW>

The body of a valid invalidation preview request must begin with the following:

<?xml version="1.0"?>
<!DOCTYPE INVALIDATIONPREVIEW SYSTEM "internal:///WCSinvalidation.dtd">

The first line denotes version 1.0 of XML. The second line denotes the request is an invalidation preview request using the WCSinvalidation.dtd file as the XML document type.

The root element INVALIDATIONPREVIEW contains one or more of the attributes described in Table 11-3. BASICSELECTOR and ADVANCEDSELECTOR are described in Table 11-1 .

Table 11-3 INVALIDATIONPREVIEW Attributes

Invalidation Element/Attribute Description

Invalidation Element/Attribute	Description
`VERSION` attribute	Required attribute in the invalidation preview Use `VERSION=`"`WCS-1.1`" as the version of the `WCSinvalidation.dtd` file to use as the XML document type.
`STARTNUM` attribute	Required attribute in the invalidation preview Enter the number representing the first document to be listed. OracleAS Web Cache begins the count of documents with the number 0.
`MAXNUM` attribute	Required attribute in the invalidation preview Enter the number of documents to be listed. If fewer documents than the number specified meet the invalidation criteria, OracleAS Web Cache lists only the URLs for those documents that meet the criteria. If more documents than the number specified meet the invalidation criteria, OracleAS Web Cache lists the URLs for the number of documents requested. It also returns the total number of documents that meet the invalidation criteria. To obtain the list of URLs for addition documents, send another preview request with a different `STARTNUM` that specifies the start of the next set of documents.

VERSION attribute

Required attribute in the invalidation preview

Use VERSION="WCS-1.1" as the version of the WCSinvalidation.dtd file to use as the XML document type.

STARTNUM attribute

Required attribute in the invalidation preview

Enter the number representing the first document to be listed. OracleAS Web Cache begins the count of documents with the number 0.

MAXNUM attribute

Required attribute in the invalidation preview

Enter the number of documents to be listed.

If fewer documents than the number specified meet the invalidation criteria, OracleAS Web Cache lists only the URLs for those documents that meet the criteria.

If more documents than the number specified meet the invalidation criteria, OracleAS Web Cache lists the URLs for the number of documents requested. It also returns the total number of documents that meet the invalidation criteria. To obtain the list of URLs for addition documents, send another preview request with a different STARTNUM that specifies the start of the next set of documents.

Invalidation Preview Response Syntax

Invalidation preview responses for preview requests are returned in the following format:

<?xml version="1.0"?> 
<!DOCTYPE INVALIDATIONPREVIEWRESULT SYSTEM "internal:///WCSinvalidation.dtd">
<INVALIDATIONPREVIEWRESULT VERSION="WCS-1.1" STATUS="status" NUMURLS="number" 
TOTALNUMURLS="total_number">
   <SELECTURL VALUE="URL">
   </SELECTEDURL>
</INVALIDATIONPREVIEWRESULT>

The body of a valid invalidation preview response begins with the following:

<?xml version="1.0"?> 
<!DOCTYPE INVALIDATIONPREVIEWRESULT SYSTEM "internal:///WCSinvalidation.dtd">

The first line denotes version 1.0 of XML. The second line denotes that the response is an invalidation preview response using the WCSinvalidation.dtd file as the XML document type.

Note the following:

No white space is allowed before "<?xml".
If an application is sharing invalidation requests with a third-party XML parser, replace "internal:///WCSinvalidation.dtd" with the following path:
```
"http://www.oracle.com/webcache/90400/WCSinvalidation.dtd"
```

The root element INVALIDATIONPREVIEWRESULT contains one or more of the attributes and elements described in Table 11-4. BASICSELECTOR and ADVANCEDSELECTOR are described in Table 11-1 .

Table 11-4 INVALIDATIONPREVIEWRESULT Elements and Attributes

Invalidation Element/Attribute	Description
`VERSION` attribute	Version number of the `WCSinvalidation.dtd` file to use as the XML document type
`STATUS` attribute	Status of the preview. Status can be one of the following: `SUCCESS` for successful invalidations `URI NOT CACHEABLE` for documents that are not cacheable `URI NOT FOUND` for documents not found
`STARTNUM` attribute	Number representing the first document to be listed
`NUMURLS` attribute	Number of URLs returned in this preview result
`TOTALNUMURLS` attribute	Number of URLs matching the `BASICSELECTOR` or `ADVANCEDSELECTOR` selectors
`SELECTEDURL` element	URLs matching the `BASICSELECTOR` or `ADVANCEDSELECTOR` selectors to be invalidated

Using OracleAS Web Cache Manager to Send Invalidation Requests

OracleAS Web Cache Manager provides an easy-to-use interface for invalidating cached objects. The message mechanics are much like the telnet example. The advantage of using OracleAS Web Cache Manager is that the administrator is isolated from the intricacies of the HTTP and XML formats, and consequently, there is less chance for error. The administrator need only specify which objects to invalidate and how invalid those objects should be.

Note:
If you receive the following error when you submit invalidation requests from the Basic Content Invalidation or Advanced Content Invalidation pages, restart the cache or admin server processes.
Internal error: can't connect to OracleAS Web Cache Invalidation Listening Port
If you changed the property of an Invalidation port, restart the cache server process.
If you changed the password for the administrator account in the Security page, restart the cache and admin server process.
Until the cache server process is restarted for either configuration change, invalidation requests will return the error.

Submitting Basic Invalidation Requests

To send a basic invalidation request using OracleAS Web Cache Manager:

Start OracleAS Web Cache Manager.

See Also:
"Starting OracleAS Web Cache Manager"
In the navigator frame, select Operations > Basic Content Invalidation.

The Basic Content Invalidation page appears in the right pane.
From the For Cache list, select a cache. (More than one cache is listed only if you configured a cache cluster. If you configured the cluster to propagate invalidation, the cache you select is designated the invalidation coordinator, which will propagate the invalidation request to other cache cluster members. If you did not configure the cluster to propagate invalidation, the cache you select is the only cache from which documents are invalidated.)
In the Search Criteria section, select the search criteria:
- Remove all cached documents: Select to remove all documents from the cache.
- Enter exact URL for removal: Specify the URL of the documents to be invalidated. Include the complete path and file name.
  
  Note: Because OracleAS Web Cache escapes the following characters, you can enter them in this field: ampersand (&), greater than sign (>), less than sign (<), double quotes ("), and single quotes (').
Optionally, you can preview the list of documents to be invalidated to ensure that you are removing only the documents you want to remove. To preview the list of documents:
1. In the Action section, choose Preview list of documents that match invalidation criteria.
2. Specify the Document Range:
  - From: Enter the number representing the first document to be listed. OracleAS Web Cache begins the count of documents with the number 0.
  - To: Enter the number of documents to be listed.
    
    If fewer documents than the number specified meet the invalidation criteria, OracleAS Web Cache lists the URLs for only those documents that meet the criteria.
    
    If more documents than the number specified meet the invalidation criteria, OracleAS Web Cache lists the URLs for the number of documents requested. It also returns the total number of documents that meet the invalidation criteria. To obtain the list of URLs for addition documents, send another preview request with a different From number that specifies the start of the next set of documents.
3. Click Submit.
  
  OracleAS Web Cache displays the Invalidation Preview Results message box, which lists the documents that meet the invalidation criteria. OracleAS Web Cache Manager lists only those documents that are valid. Although the cache may contain documents that are expired or that have been invalidated, those documents are not listed.
  
  If the documents listed are those that you want to invalidate, continue with the next step. If they are not, modify the invalidation criteria and preview the list again.

In the Action section, select one of the following options to specify how to process invalid documents:

Remove immediately: OracleAS Web Cache marks documents as invalid and removes them immediately. A document is refreshed from the origin server when the cache receives the next request for it.

Remove documents no later than <number> <time> after submission: OracleAS Web Cache marks documents as invalid and then refreshes them based on origin server capacity. Enter the maximum time in which the documents can reside in the cache.

Note:
Performance assurance heuristics apply when you configure documents to be refreshed based on when the origin servers can refresh them; performance assurance heuristics do not apply when documents are immediately removed.

Click Submit.

OracleAS Web Cache processes the invalidation request, and returns the Cache Cleanup Result dialog box that the shows the invalidation status and the number of objects invalidated. The following figure shows the dialog box:

Text description of invalid.gif follows.

Text description of the illustration invalid.gif

In a cache cluster environment, if Propagate Invalidation is enabled, OracleAS Web Cache sends the invalidation request to one cluster member who acts as the invalidation coordinator. The coordinator propagates the invalidation request to other cluster members. When the invalidation has been completed for all cluster members, OracleAS Web Cache returns a Cache Cleanup box, that lists, for each cluster member, the cache name, the status of the invalidation request, and the number of objects invalidated.

See Also:

"Task 1: Configure Cache Cluster Settings" for information about enabling invalidation propagation

"Invalidation in Cache Clusters" for further information about invalidation propagation in a cache cluster

Submitting Advanced Invalidation Requests

To send an advanced invalidation request using OracleAS Web Cache Manager:

Start OracleAS Web Cache Manager.

See Also:
"Starting OracleAS Web Cache Manager"
In the navigator frame, select Operations > Advanced Content Invalidation.

The Advanced Content Invalidation page appears in the right pane.
From the For Cache list, select a cache. (More than one cache is listed only if you configured a cache cluster.)

In the Search Criteria section, select the search criteria:

Note:
Because OracleAS Web Cache escapes the following characters, you can enter them in the search criteria fields: ampersand (&), greater than sign (>), less than sign (<), double quotes ("), and single quotes (').

URL Path Prefix: Required. Specify the path prefix of the documents to be invalidated. The path prefix must begin with http|https://host_name:port/path/filename or with "/" and end with "/".

host_name:port is optional. You can also specify the site host name and port in the Host Name field.

The prefix is interpreted literally, including reserved regular expression characters. These characters include periods (.), question marks (?), asterisks (*), brackets ([]), curly braces ({}), carets (^), dollar signs ($), and backslashes (\).
Host Name: Optional. Specify the host name and port number of the site (host_name:port). Port 80 is the default port for HTTP.

This field is required if the URL Path Prefix does not include http|https://host_name:port/path/filename.
HTTP Method: Optional. Select the HTTP request method (GET or POST) of the documents to be invalidated. The default value is GET.
URL Expression: Optional. Specify the URL of the documents to be invalidated under the URL Path Prefix. Then, specify how to match by selecting either substring for an exact string match or regular expression for a regular expression match.

If no value is entered, everything under the URL Path Prefix is matched.

POST Body Expression: Optional. If POST is selected for the HTTP Method, enter the HTTP POST body of the objects to be invalidated, and then specify how to match by selecting either substring for a substring string match or regular expression for a regular expression match.

Note:
If regular expression is selected for the URL Expression or POST Body Expression fields, OracleAS Web Cache interprets the following reserved regular expression characters: periods (.), question marks (?), asterisks (*), brackets ([]), curly braces ({}), carets (^), dollar signs ($), and backslashes (\). To interpret these characters literally, escape them with a backslash (\).

Optionally, in the Cookie/Header Information section, specify the use of cookies or HTTP request headers in the search criteria:
1. From the list, select Cookie or Header.
2. Provide the following information:
  - Cookie: Enter the cookie name used by the objects to be invalidated in the Name field, and enter its value in the Value field.
  - Header: Enter the HTTP request header used by the objects to be invalidated in the Name field, and enter its value in the Value field.
Optionally, in the URL Parameters section, enter the name of the embedded URL parameter used by the objects to be invalidated in the Name field, enter its value in the Value field, and then specify how to match by selecting either exact strings or regular expression.
Optionally, in the Search Keys section, enter the name of a search key from the Surrogate-Key response-header field used by the objects to be invalidated in the Key field.

See Also:
"Surrogate-Key Response-Header Field"
Optionally, you can preview the list of documents to be invalidated to ensure that you are removing only the documents you want to remove. To preview the list of documents:
1. In the Action section, choose Preview list of documents to be removed.
2. Specify the Document Range:
  - From: Enter the number representing the first document to be listed. OracleAS Web Cache begins the count of documents with the number 0.
  - To: Enter the number of documents to be listed.
  If fewer documents than the number specified meet the invalidation criteria, OracleAS Web Cache lists the URLs for only those documents that meet the criteria.
  
  If more documents than the number specified meet the invalidation criteria, OracleAS Web Cache lists the URLs for the number of documents requested. It also returns the total number of documents that meet the invalidation criteria. To obtain the list of URLs for addition documents, send another preview request with a different From number that specifies the start of the next set of documents.
3. Click Submit.
  
  OracleAS Web Cache displays the Invalidation Preview Results message box, which lists the documents that meet the invalidation criteria. OracleAS Web Cache Manager lists only those documents that are valid. Although the cache may contain documents that are expired or that have been invalidated, those documents are not listed.
  
  If the documents listed are those that you want to invalidate, continue with the next step. If they are not, modify the invalidation criteria and preview the list again.

In the Action section, select one of the following options to specify how to process invalid documents:

Remove immediately: OracleAS Web Cache marks documents as invalid and then removes them immediately. A document is refreshed from the origin server when the cache receives the next request for it.

Note:
Performance assurance heuristics apply when you configure documents to be refreshed based on when the application Web servers can refresh them; performance assurance heuristics do not apply when documents are immediately removed.

Click Submit.

OracleAS Web Cache processes the invalidation request, and returns a Cache Cleanup dialog box that the shows the invalidation status and the number of objects invalidated.

Note:
For prefix-based invalidations that require OracleAS Web Cache to traverse a complex directory structure, invalidation can take some time. Therefore, do not click Submit again until the Cache Cleanup Result dialog box appears. Creating a queue of invalidation requests can degrade the performance of OracleAS Web Cache.

Using Applications for Automated Invalidation Requests

Invalidation requests can originate from a Web site's underlying application logic or from the content management application used to design Web pages.

OracleAS Web Cache ships with the following Application Program Interfaces (APIs) that you can implement:

jawc.jar for a Java invalidation API

wxvutil.sql and wxvappl.sql for a PL/SQL invalidation API

These APIs are located in the $ORACLE_HOME/webcache/toolkit directory on UNIX and ORACLE_HOME\webcache\toolkit directory on Windows

See Also:

Oracle Application Server Web Cache Invalidation API Reference for reference information

readme.toolkit.html in the $ORACLE_HOME/webcache/docs directory on UNIX and ORACLE_HOME\webcache\docs directory on Windows for further information about the APIs

OracleAS Web Cache also ships with the following sample code for generating invalidation requests. You can create invalidation tools following these examples and use them with your applications.

EncodeBase64.java for encoding the password using Base 64 encoding
invalidate.c for C source
Invalidate.java or WCSInvalidate.java for Java source
invalidate.sh for a shell script that invalidates documents with a telnet session
invalidate.pl for PERL source
Invalidate.sql for PL/SQL source

These files are located in the $ORACLE_HOME/webcache/examples directory on UNIX and ORACLE_HOME\webcache\examples directory on Windows.

See Also:
readme.examples.html in the $ORACLE_HOME/webcache/docs directory on UNIX and ORACLE_HOME\webcache\docs directory on Windows for further information about these files

Using Database Triggers for Automated Invalidation Requests

Database triggers are procedures that are stored in the database and activated ("fired") when specific conditions occur, such as adding a row to a table. You can use triggers to send invalidation requests. To do this, use the UTL_TCP Oracle supplied package to send invalidation requests through database triggers.

See Also:

readme.examples.html in the $ORACLE_HOME/webcache/docs directory on UNIX and ORACLE_HOME\webcache\docs directory on Windows for further information about using the cre_invalid_trig.sql script to create a database trigger and the utl_proc.sql script to demonstrate invalidation with database triggers

Oracle PL/SQL documentation

Using Scripts for Automated Invalidations

Many Web sites use scripts for uploading new content to databases and file systems. A large online book retailer, for instance, might run a PERL script once a day to bulk load new book listings and price changes into its catalog database. The retailer would want the price changes and availability listings to be reflected in the item views and search results currently cached in OracleAS Web Cache. To achieve this, the PERL script can be modified such that when the bulk loading operation has completed, the script will send an invalidation request to the cache invalidating all catalog views and search results. (Note that the invalidation request need not list every individual search page or item view that might be effected by the data change.) The performance assurance feature of OracleAS Web Cache enables administrators to use broad brush strokes when invalidating content, making it safe to invalidate all catalog content even if only a fraction of that content has changed.

Invalidation Examples

This section contains the following invalidation request examples:

The examples in this section require using the POST method which also requires sending the number of bytes (or characters) in the content_length: #bytes portion of the header. Please note that one carriage return is required after the content_length: #bytes line and before the XML request or BODY information.

Example: Invalidating One Document

The following request invalidates the file /images/logo.gif:

<?xml version="1.0"?>
<!DOCTYPE INVALIDATION SYSTEM "internal:///WCSinvalidation.dtd">
<INVALIDATION VERSION="WCS-1.1">
   <OBJECT>
     <BASICSELECTOR URI="http://www.company.com:80/images/logo.gif"/>
     <ACTION/>
   </OBJECT>
</INVALIDATION>

Invalidation response:

<?xml version="1.0"?> 
<!DOCTYPE INVALIDATIONRESULT SYSTEM "internal:///WCSinvalidation.dtd">
<INVALIDATIONRESULT VERSION="WCS-1.1">
   <OBJECTRESULT>
     <BASICSELECTOR URI="http://www.company.com:80/images/logo.gif"/>
     <RESULT ID="1" STATUS="SUCCESS" NUMINV="1"/>
     </OBJECTRESULT>
</INVALIDATIONRESULT>

The following request invalidates a document exactly matching /contacts/contacts.html using the BASICSELECTOR element:

<?xml version="1.0"?>
<!DOCTYPE INVALIDATION SYSTEM "internal:///WCSinvalidation.dtd">
<INVALIDATION VERSION="WCS-1.1">
  <OBJECT>
    <BASICSELECTOR URI="http://www.company.com:80/contacts/contacts.html"/>
    <ACTION REMOVALTTL="0"/>
  </OBJECT>
</INVALIDATION>

This request is equivalent to the following request using the ADVANCEDSELECTOR element. This request specifies the site information in the HOST attribute.

<?xml version="1.0"?>
<!DOCTYPE INVALIDATION SYSTEM "internal:///WCSinvalidation.dtd">
<INVALIDATION VERSION="WCS-1.1">
  <OBJECT>
    <ADVANCEDSELECTOR URIPREFIX="/contacts/" URIEXP="^/contacts/contacts\.html$" 
HOST="www.company.com:80"/>
    <ACTION REMOVALTTL="0"/>
  </OBJECT>
</INVALIDATION>

The second request specifies the site information in the URIPREFIX attribute:

<?xml version="1.0"?>
<!DOCTYPE INVALIDATION SYSTEM "internal:///WCSinvalidation.dtd">
<INVALIDATION VERSION="WCS-1.1">
  <OBJECT>
    <ADVANCEDSELECTOR URIPREFIX="http://www.company.com/contacts/" 
URIEXP="^/contacts/contacts\.html$"/>
    <ACTION REMOVALTTL="0"/>
  </OBJECT>
</INVALIDATION>

The ADVANCEDSELECTOR element uses the URIPREFIX attribute. This attribute is used to traverse the directory structure. The quicker invalidation reaches the right tree level, the quicker the invalidation process is done. The request with the BASICSELECTOR element is the more efficient of the two examples because there is no directory structure traversal involved.

Example: Invalidating Multiple Objects

The following request invalidates two different objects, summary.jsp and summary.gif. In addition, the request provides the comments "summary.jsp" and "summary.gif" to be included in the invalidation result and event log.

<?xml version="1.0"?>
<!DOCTYPE INVALIDATION SYSTEM "internal:///WCSinvalidation.dtd">
<INVALIDATION VERSION="WCS-1.1">
  <OBJECT>
    <ADVANCEDSELECTOR URIPREFIX="/global/sales/" URIEXP="summary.jsp\?year=2001" 
HOST="www.company.com:80"/>
      <COOKIE NAME="group" VALUE="asia"/>
    </ADVANCEDSELECTOR>
    <ACTION />
    <INFO VALUE="summary.jsp"/>
  </OBJECT>
  <OBJECT>
    <ADVANCEDSELECTOR URIPREFIX="/image/" URIEXP="summary.*\.gif$" 
HOST="www.company.com:80"/>
    <INFO VALUE="summary.gif"/>
    <ACTION />
  </OBJECT>
</INVALIDATION>

Invalidation response:

<?xml version="1.0"?> 
<!DOCTYPE INVALIDATIONRESULT SYSTEM "internal:///WCSinvalidation.dtd">
<INVALIDATIONRESULT VERSION="WCS-1.1">
  <OBJECTRESULT>
    <ADVANCEDSELECTOR URIPREFIX="/global/sales/" URIEXP="summary.jsp\?year=2001" 
HOST="www.company.com:80"/>
      <COOKIE  NAME="group"  VALUE="asia"  />
    </ADVANCEDSELECTOR>
    <RESULT ID="1" STATUS="SUCCESS" NUMINV="2"/>
    <INFO VALUE="summary.jsp"/>
  </OBJECTRESULT>
  <OBJECTRESULT>
    <ADVANCEDSELECTOR URIPREFIX="/image/" URIEXP="summary.*\.gif$" 
HOST="www.company.com:80"/>
    </ADVANCEDSELECTOR>
    <RESULT ID="2" STATUS="SUCCESS" NUMINV="14"/>
    <INFO VALUE="summary.gif"/>
  </OBJECTRESULT>
</INVALIDATIONRESULT>

The following messages are written to the event log:

[13/Dec/2002:19:26:46 +0000] [notification 11748] [invalidation] [ecid: 
21085932167,0] Invalidation with INFO 'summary.jsp' has returned with status 
'SUCCESS'; number of documents invalidated: '2'.
.
.
.
[13/Dec/2002:19:26:46 +0000] [notification 11748] [invalidation] [ecid: 
21085932167,0] Invalidation with INFO 'summary.gif' has returned with status 
'SUCCESS'; number of documents invalidated: '14'.

Example: Invalidating a Subtree of Documents

The following request invalidates all documents under the /images/ directory:

<?xml version="1.0"?>
<!DOCTYPE INVALIDATION SYSTEM "internal:///WCSinvalidation.dtd">
<INVALIDATION VERSION="WCS-1.1">
   <OBJECT>
     <ADVANCEDSELECTOR URIPREFIX="/images/" HOST="www.company.com:80"/>
     <ACTION REMOVALTTL="0"/>
   </OBJECT>
</INVALIDATION>

Invalidation response:

<?xml version="1.0"?> 
<!DOCTYPE INVALIDATIONRESULT SYSTEM "internal:///WCSinvalidation.dtd">
<INVALIDATIONRESULT VERSION="WCS-1.1">
   <OBJECTRESULT>
     <ADVANCEDSELECTOR URIPREFIX="/images/" HOST="www.company.com:80"/>
     <RESULT ID="1" STATUS="SUCCESS" NUMINV="125"/>
   </OBJECTRESULT>
</INVALIDATIONRESULT>

The following request invalidates all documents under the /contacts/ directory whose file names end in .html and uses cookie name cust with a value of oracle:

<?xml version="1.0"?>
<!DOCTYPE INVALIDATION SYSTEM "internal:///WCSinvalidation.dtd">
<INVALIDATION VERSION="WCS-1.1">
  <OBJECT>
    <ADVANCEDSELECTOR URIPREFIX="/contacts/" URIEXP="\.html$" 
HOST="www.company.com:80"/>
      <COOKIE NAME="cust" VALUE="oracle"/>
    </ADVANCEDSELECTOR>
    <ACTION REMOVALTTL="0"/>
  </OBJECT>
</INVALIDATION>

Invalidation response:

<?xml version="1.0"?> 
<!DOCTYPE INVALIDATIONRESULT SYSTEM "internal:///WCSinvalidation.dtd">
<INVALIDATIONRESULT VERSION="WCS-1.1">
   <OBJECTRESULT>
     <ADVANCEDSELECTOR URIPREFIX="/contacts"/> URIEXP="\.html$" 
HOST="www.company.com:80"/>
      <COOKIE NAME="cust" VALUE="oracle"/>
     </ADVANCEDSELECTOR>
      <RESULT ID="1" STATUS="SUCCESS" NUMINV="45"/>
   </OBJECTRESULT>
</INVALIDATIONRESULT>

Example: Invalidating All Documents for a Web Site

The following request invalidates all documents under /.

<?xml version="1.0"?>
<!DOCTYPE INVALIDATION SYSTEM "internal:///WCSinvalidation.dtd">
<INVALIDATION VERSION="WCS-1.1">
   <OBJECT>
     <ADVANCEDSELECTOR URIPREFIX="/" HOST="www.company.com:80"/>
     <ACTION REMOVALTTL="0"/>
   </OBJECT>
</INVALIDATION>

Invalidation response:

<?xml version="1.0"?> 
<!DOCTYPE INVALIDATIONRESULT SYSTEM "internal:///WCSinvalidation.dtd">
<INVALIDATIONRESULT VERSION="WCS-1.1">
   <OBJECTRESULT>
     <ADVANCEDSELECTOR URIPREFIX="/" HOST="www.company.com:80"/>
      <RESULT ID="1" STATUS="SUCCESS" NUMINV="17"/>
   </OBJECTRESULT>
</INVALIDATIONRESULT>

Example: Invalidating Documents Using Prefix Matching

To better understand the relationship of the URIPREFIX and URIEXP attributes, consider the examples that follow.

The following syntax invalidates sample.gif files within the /cec/cstage/graphic* directories:

<ADVANCEDSELECTOR URIPREFIX="/cec/cstage/"
   URIEXP="graphic.*/sample\.gif">
</ADVANCEDSELECTOR>

Note that ".*" in "graphic.*/sample\.gif" are regular expression characters that match all directories starting with graphic. The "." in "sample\.gif" is escaped for a literal interpretation.

The following syntax instructs OracleAS Web Cache to locate a directory named graphic*:

<ADVANCEDSELECTOR URIPREFIX="/cec/cstage/graphic*/" URIEXP="sample\.gif" 
HOST="www.company.com:80"/>
</ADVANCEDSELECTOR>

The following syntax invalidates documents contained within /cec/cstage?ecaction=viewitem:

<ADVANCEDSELECTOR URIPREFIX="/cec/" URIEXP="cstage\?ecaction=viewitem" 
HOST="www.company.com:80"/>
</ADVANCEDSELECTOR>

Note that "?" is escaped with a backslash.

URLs such as /cec/cstage?ecaction=viewitem&zip=94405 and /cec/cstage?ecaction=viewitem&zip=94305 match and are invalidated, but /usa/cec/cstage?ecaction=viewitem&zip=94209 does not match and is not invalidated.

Example: Invalidating Documents Using Substring and Query String Matching

The following request invalidates all documents under / matching the substrings /post/ and htm. In addition, the request provides the comment "remove-htm-under-all-post-dir" to be included in the invalidation result and event log.

<?xml version="1.0"?>
<!DOCTYPE INVALIDATION SYSTEM "internal:///WCSinvalidation.dtd">
<INVALIDATION VERSION="WCS-1.1">
  <OBJECT>
    <ADVANCEDSELECTOR URIPREFIX="/"
                      HOST="www.company.com:80">
      <OTHER NAME="URI" TYPE="SUBSTRING" VALUE="/post/"/>
      <OTHER NAME="URI" TYPE="SUBSTRING" VALUE="htm"/>
    </ADVANCEDSELECTOR>
    <ACTION REMOVALTTL="0" />
    <INFO VALUE="remove-htm-under-all-post-dir"/>
  </OBJECT>
</INVALIDATION>

Invalidation response:

<?xml version="1.0"?> 
<!DOCTYPE INVALIDATIONRESULT SYSTEM "internal:///WCSinvalidation.dtd">
<INVALIDATIONRESULT VERSION="WCS-1.1">
   <OBJECTRESULT>
     <ADVANCEDSELECTOR URIPREFIX="/" HOST="www.company.com:80"/>
       <OTHER NAME="URI" TYPE="SUBSTRING" VALUE="/post/"/>
       <OTHER NAME="URI" TYPE="SUBSTRING" VALUE="htm"/>      
      <RESULT ID="1" STATUS="SUCCESS" NUMINV="52"/>
      <INFO VALUE="remove-htm-under-all-post-dir"/>
   </OBJECTRESULT>
</INVALIDATIONRESULT>

The following message is written to the event log:

[13/Dec/2002:19:26:46 +0000] [notification 11748] [invalidation] [ecid: 
21085932167,0] Invalidation with INFO 'remove-htm-under-all-post-dir has 
returned with status 'SUCCESS'; number of documents invalidated: '12'.

The following request invalidates all documents under /corporate/asp/, matching the substring /view_building.asp and the embedded URL parameter value pairs of building=8 and floor=10. In addition, the request provides the comment "remove-view-building8-10th-floor" to be included in the invalidation result and event log.

<?xml version="1.0"?>
<!DOCTYPE INVALIDATION SYSTEM "internal:///WCSinvalidation.dtd">
<INVALIDATION VERSION="WCS-1.1">
  <OBJECT>
    <ADVANCEDSELECTOR URIPREFIX="/corporate/asp/"
                      HOST="www.company.com:80">
      <OTHER NAME="URI" TYPE="SUBSTRING" VALUE="/view_building.asp"/>
      <OTHER NAME="QUERYSTRING_PARAMETER" TYPE="SUBSTRING" VALUE="building=8"/>
      <OTHER NAME="QUERYSTRING_PARAMETER" TYPE="SUBSTRING" VALUE="floor=10"/>
    </ADVANCEDSELECTOR>
    <ACTION REMOVALTTL="0" />
    <INFO VALUE="remove-view-building8-10th-floor"/>
  </OBJECT>
</INVALIDATION>

Invalidation response:

<?xml version="1.0"?> 
<!DOCTYPE INVALIDATIONRESULT SYSTEM "internal:///WCSinvalidation.dtd">
<INVALIDATIONRESULT VERSION="WCS-1.1">
   <OBJECTRESULT>
     <ADVANCEDSELECTOR URIPREFIX="/" HOST="www.company.com:80"/>
       <OTHER NAME="URI" TYPE="SUBSTRING" VALUE="/view_building.asp"/>
       <OTHER NAME="QUERYSTRING_PARAMETER" TYPE="SUBSTRING" VALUE="building=8"/>
       <OTHER NAME="QUERYSTRING_PARAMETER" TYPE="SUBSTRING" VALUE="floor=10"/>     
      <RESULT ID="1" STATUS="SUCCESS" NUMINV="3"/>
      <INFO VALUE="remove-view-building8-10th-floor"/>
   </OBJECTRESULT>
</INVALIDATIONRESULT>

The following message is written to the event log:

[13/Dec/2002:19:26:46 +0000] [notification 11748] [invalidation] [ecid: 21085932
167,0] Invalidation with INFO 'remove-view-building8-10th-floor' has returned 
with status 'SUCCESS'; number of documents invalidated: '3'.

See Also:
"Enhance Query String Invalidations" to optimize invalidations using QUERYSTRING_PARAMETER

Example: Invalidating Documents Using Search Key Matching

The following request invalidates all objects under /pls/publicuser/, matching the following:

Substring /pls/publicuser/!MODULE.wwpob_page.show
HTTP request header x-oracle-cache-user and value PUBLICUSER

Surrogate-Key response-header field containing a search key of template_id=33,31345.

<?xml version="1.0"?>
<!DOCTYPE INVALIDATION SYSTEM "internal:///WCSinvalidation.dtd">
<INVALIDATION VERSION="WCS-1.1">
<OBJECT>
    <ADVANCEDSELECTOR URIPREFIX="/pls/publicuser/" HOST="www.company.com:80"
      METHOD="POST">
      <OTHER NAME="SEARCHKEY" VALUE="template_id=33,31345"/>
      <HEADER NAME="x-oracle-cache-user" VALUE="PUBLICUSER"/>
      <OTHER NAME="URI" TYPE="SUBSTRING"
        VALUE="/pls/publicuser/!MODULE.wwpob_page.show"/>
    </ADVANCEDSELECTOR>
    <ACTION REMOVALTTL="0"/>
</OBJECT>
</INVALIDATION>

Invalidation response:

<?xml version="1.0"?> 
<!DOCTYPE INVALIDATIONRESULT SYSTEM "internal:///WCSinvalidation.dtd">
<INVALIDATIONRESULT VERSION="WCS-1.1">
   <OBJECTRESULT>
    <ADVANCEDSELECTOR URIPREFIX="/pls/publicuser/" HOST="www.company.com:80"
      METHOD="POST">
      <OTHER NAME="SEARCHKEY" VALUE="template_id=33,31345"/>
      <HEADER NAME="x-oracle-cache-user" VALUE="PUBLICUSER"/>
      <OTHER NAME="URI" TYPE="SUBSTRING"
        VALUE="/pls/publicuser/!MODULE.wwpob_page.show"/>
      <RESULT ID="1" STATUS="SUCCESS" NUMINV="3"/>
   </OBJECTRESULT>
</INVALIDATIONRESULT>

Example: Propagating Invalidation Requests Throughout a Cache Cluster

In a cache cluster, you can enable or disable the propagation of invalidation requests to all cluster members. You specify the setting on the Clustering page (Properties > Clustering) of OracleAS Web Cache Manager.

You can override the setting by using a pair of name/value attributes of the SYSTEMINFO element. If NAME is set to WCS_PROPAGATE and VALUE is set to TRUE, it overrides the setting specified in OracleAS Web Cache Manager. If NAME is set to WCS_PROPAGATE and VALUE is set to FALSE, it reads the setting specified in OracleAS Web Cache Manager.

The following request invalidates the file /images/logo.gif and propagates the request to all cluster members. In this example, there are three cluster members:

<?xml version="1.0"?>
<!DOCTYPE INVALIDATION SYSTEM "internal:///WCSinvalidation.dtd">
<INVALIDATION VERSION="WCS-1.1">
   <SYSTEM>
      <SYSTEMINFO NAME="WCS_PROPAGATE" VALUE="TRUE"/>
   </SYSTEM>
   <OBJECT>
     <BASICSELECTOR URI="/hostname:port/images/logo.gif"/>
     <ACTION/>
   </OBJECT>
</INVALIDATION>

Invalidation response:

<?xml version="1.0"?> 
<!DOCTYPE INVALIDATIONRESULTDETAIL SYSTEM "internal:///WCSinvalidation.dtd">
<INVALIDATIONRESULTDETAIL VERSION="WCS-1.1">
  <INVALIDATIONRESULT VERSION="WCS-1.1">
     <SYSTEM>
       <SYSTEMINFO NAME="WCS_CACHE_NAME" VALUE="Cache_A"/>
     </SYSTEM>
     <OBJECTRESULT>
       <BASICSELECTOR URI="http://www.company.com:80/images/logo.gif"/>
       <RESULT ID="1" STATUS="SUCCESS" NUMINV="1"/>
     </OBJECTRESULT>
  </INVALIDATIONRESULT>
  <INVALIDATIONRESULT VERSION="WCS-1.1">
     <SYSTEM>
       <SYSTEMINFO NAME="WCS_CACHE_NAME" VALUE="Cache_B"/>
     </SYSTEM>
     <OBJECTRESULT>
       <BASICSELECTOR URI="http://www.company.com:80/images/logo.gif"/>
       <RESULT ID="1" STATUS="SUCCESS" NUMINV="1"/>
     </OBJECTRESULT>
  </INVALIDATIONRESULT>
  <INVALIDATIONRESULT VERSION="WCS-1.1">
     <SYSTEM>
       <SYSTEMINFO NAME="WCS_CACHE_NAME" VALUE="Cache_C"/>
     </SYSTEM>
     <OBJECTRESULT>
       <BASICSELECTOR URI="http://www.company.com:80/images/logo.gif"/>
       <RESULT ID="1" STATUS="SUCCESS" NUMINV="1"/>
     </OBJECTRESULT>
  </INVALIDATIONRESULT>
</INVALIDATIONRESULTDETAIL>

Example: Previewing Invalidation

The following request previews up to 50 documents ending in *.htm:

<?xml version="1.0"?>
<!DOCTYPE INVALIDATIONPREVIEW SYSTEM
"internal:///WCSinvalidation.dtd">
<INVALIDATIONPREVIEW VERSION="WCS-1.1" STARTNUM="0" MAXNUM="50">
  <ADVANCEDSELECTOR URIPREFIX="http://company-sun/"
                    URIEXP=".*\.htm" >
  </ADVANCEDSELECTOR>
</INVALIDATIONPREVIEW>

Invalidation response:

"<?xml version="1.0"?>
<!DOCTYPE INVALIDATIONPREVIEWRESULT SYSTEM
"internal:///WCSinvalidation.dtd">
<INVALIDATIONPREVIEWRESULT VERSION="WCS-1.1" STATUS="SUCCESS"
                           STARTNUM="0" NUMURLS="2" TOTALNUMURLS="2">
  <SYSTEM>
    <SYSTEMINFO NAME="WCS_CACHE_NAME" VALUE="server-cache"/>
  </SYSTEM>
  <SELECTEDURL VALUE="/company-sun:80/index.htm "/>
  <SELECTEDURL VALUE="/company-sun:80/dtd.htm "/>
</INVALIDATIONPREVIEWRESULT>

Inline Invalidation in HTTP Response

Inline invalidation is implemented as part of Edge Side Includes (ESI) and provides a useful way for origin servers to "piggyback" invalidation messages on transactional responses sent to Web Cache. For instance, when a customer purchases a vegetarian cookbook on an e-commerce site, the confirmation response could contain instructions for invalidating all catalog pages related to the book, its author and vegetables. The ability to send invalidation message inline reduces the connection overhead associated with sending out-of-band invalidations and is a useful tool for ESI developers.

To configure inline invalidation:

In the template page, configure the HTTP response with the Surrogate-Control response-header field that includes content="ESI-INV/1.0":
```
Surrogate-Control: content="ESI-INV/1.0"
```

In the body of the same response, use the <esi:invalidate> tag to insert either a basic or advanced inline invalidation request.

You can insert an inline invalidation request anywhere in the ESI template. You can insert more than one, but only the first one will be processed. The execution of the inline invalidation is blocking. That is, if the ESI template contains other ESI features, inline invalidation will be executed first.

Basic invalidation syntax:

<esi:invalidate [output="yes"]>
 <?xml version="1.0"?>
 <!DOCTYPE INVALIDATION SYSTEM "internal:///WCSinvalidation.dtd">
  <INVALIDATION VERSION="WCS-1.1">
    <SYSTEM>
     <SYSTEMINFO NAME="name" VALUE="value"/>
    </SYSTEM>  
    <OBJECT>
      <BASICSELECTOR URI="URL"/>
      <ACTION REMOVALTTL="TTL"/>
      <INFO VALUE="value"/>
    </OBJECT>
 </INVALIDATION>
</esi:invalidate>

Advanced invalidation syntax:

<esi:invalidate [output="yes"]>
 <?xml version="1.0"?>
 <!DOCTYPE INVALIDATION SYSTEM "internal:///WCSinvalidation.dtd">
 <INVALIDATION VERSION="WCS-1.1">
    <SYSTEM>
     <SYSTEMINFO NAME="name" VALUE="value"/>
    </SYSTEM>

       <OBJECT>
         <ADVANCEDSELECTOR URIPREFIX="prefix"
                           URIEXP="URL_expression"
                           HOST="host_name:port"
                           METHOD="HTTP_request_method"
                          BODYEXP="HTTP_body"/>
          <COOKIE NAME="cookie_name" VALUE="value"/>
          <HEADER NAME="HTTP_request_header" VALUE="value"/>
          <OTHER NAME="URI|BODY|QUERYSTRING_PARAMETER|SEARCHKEY"
                 TYPE="SUBSTRING|REGEX"
                 VALUE="value"/>
         </ADVANCEDSELECTOR>
       </OBJECT>

 </INVALIDATION>
</esi:invalidate>

See Also:

"Invalidation Request Syntax" for invalidation request syntax

"ESI invalidate Tag" for a description of the <esi:invalidate> tag

Example: Using Inline Invalidation

Following is an example about an online bike shop using inline invalidation in their simple Web application. It has two CGI scripts written in Perl. show_bike.pl displays how many bikes of a certain model are in stock. Since it involves database query and its result remains the same until a purchase occurs, show_bike.pl is cached. buy_bike.pl is used by customers to buy a bike. Once this page is requested, show_bike.pl is no longer valid--an invalidation is needed.

Example 11-1 shows the code for show_bike.pl.

Example 11-1 show_bike.pl Code

#!/usr/local/bin/perl

# first, retrieve how many bikes are in stock 
# and assign it to $nBikes (omitted!)

print <<END;
Content-Type: text/html
Cache-Control: private
Surrogate-Control: max-age=3600

<html>
<body>
<h1>Bike: model 2002</h1>

<p>There are $nBikes bike(s) in stock for purchase!</p>
<p>Click <a href="/cgi/buy_bike.pl">here</a> to purchase a bike.</p>

</body>
</html>
END

Note that max-age=3600 informs OracleAS Web Cache to only cache this page for up to an hour.

Example 11-2 shows the code for buy_bike.pl with an inline invalidation request.

Example 11-2 buy_bike.pl Code with an Inline Invalidation Request

#!/usr/local/bin/perl

print <<END;
Content-Type: text/html
Cache-Control: private
Surrogate-Control: content="ESI/1.0 ESI-INV/1.0"

<html>
<body>
<h1>Thank you for purchasing bike model 2000.</h1>

<p>Click <a href="/cgi/show_bike.pl">here</a> to read more 
about this model.</p>

<esi:invalidate>
 <?xml version="1.0"?>
 <!DOCTYPE INVALIDATION SYSTEM "internal:///WCSinvalidation.dtd">
  <INVALIDATION VERSION="WCS-1.1">
    <OBJECT>
      <BASICSELECTOR URI="/cgi/show_bike.pl"/>
      <ACTION REMOVALTTL="0"/>
    </OBJECT>
 </INVALIDATION>
</esi:invalidate>

<p>Thanks again!</p>
</body>
</html>
END

The ESI-INV/1.0 token in Surrogate-Control instructs OracleAS Web Cache to process the <esi:invalidate> tag.

Example 11-3 shows the browser response for buy_bike.pl. Because OracleAS Web Cache has already processed the inline invalidation request, the inline invalidation is not present in the response.

Example 11-3 Browser Response of buy_bike.pl

Content-Type: text/html
Cache-Control: private
Surrogate-Control: content="ESI/1.0 ESI-INV/1.0"

<html>
<body>
<h1>Thank you for purchasing bike model 2000.</h1>

<p>Click <a href="/cgi/show_bike.pl">here</a> to read more 
about this model.</p>

<p>Thanks again!</p>
</body>
</html>

Debugging Tips

To facilitate debugging, the application developer can perform the following:

Add the Surrogate-Capability request header that includes "ESI-INV/1.0":
```
Surrogate-Capability: content="ESI-INV/1.0"
```
When the Surrogate-Capability request header is added for inline invalidation, OracleAS Web Cache includes the invalidation request in the response.
Enable the output attribute of the <esi:invalidate> tag.

When the output attribute is enabled, OracleAS Web Cache includes the invalidation result in the response enclosed within comments .

Example 11-4 shows the browser response of buy_bike.pl when both the Surrogate-Capability request header is enabled for the inline invalidation and the output attribute of the <esi:invalidate> tag is enabled.

Example 11-4 Browser Response of show_bike.pl with Diagnostic Inline Invalidation Information

Content-Type: text/html
Cache-Control: private
Surrogate-Control: content="ESI/1.0 ESI-INV/1.0"

<html>
<body>
<h1>Thank you for purchasing bike model 2000.</h1>

<p>Click <a href="/cgi/show_bike.pl">here</a> to read more 
about this model.</p>

<esi:invalidate output="yes">
 <?xml version="1.0"?>
 <!DOCTYPE INVALIDATION SYSTEM "internal:///WCSinvalidation.dtd">
  <INVALIDATION VERSION="WCS-1.1">
    <OBJECT>
      <BASICSELECTOR URI="/cgi/show_bike.pl"/>
      <ACTION REMOVALTTL="0"/>
    </OBJECT>
 </INVALIDATION>
</esi:invalidate>

<!--
<?xml version="1.0"?> 
<!DOCTYPE INVALIDATIONRESULT SYSTEM "internal:///WCSinvalidation.dtd">
<INVALIDATIONRESULT VERSION="WCS-1.1">
   <OBJECTRESULT>
     <BASICSELECTOR URI="/cgi/show_bike.pl/>
     <RESULT ID="1" STATUS="SUCCESS" NUMINV="1"/>
     </OBJECTRESULT>
</INVALIDATIONRESULT>
-->

<p>Thanks again!</p>
</body>
</html>

Reducing Invalidation Overhead

When OracleAS Web Cache receives an advanced invalidation request, it traverses the contents of the cache to locate the objects to invalidate. Depending on the structure and number of objects cached, it can take time for OracleAS Web Cache to invalidate content. Here are some ways you can expedite cache content traversal:

Send Basic Invalidation Requests for Invalidating One Object

When you need to invalidate one object in the cache, send a basic rather than an advanced invalidation request to avoid cache traversal.

To send a basic invalidation request, use the Basic Content Invalidation page (Operations > Basic Content Invalidation) in OracleAS Web Cache Manager or specify the BASICSELECTOR element. For example, the following request invalidates a document exactly matching /contacts/contacts.html using the BASICSELECTOR element:

<?xml version="1.0"?>
<!DOCTYPE INVALIDATION SYSTEM "internal:///WCSinvalidation.dtd">
<INVALIDATION VERSION="WCS-1.1">
   <OBJECT>
     <BASICSELECTOR URI="http://www.company.com:80/contacts/contacts.html"/>
     <ACTION REMOVALTTL="0"/>
   </OBJECT>
</INVALIDATION>

Advanced invalidation requests should be reserved for invalidation of multiple objects. To send an advanced invalidation request, use the Advanced Content Invalidation page or specify the ADVANCEDSELECTOR element.

Use Substring Matching for Invalidating Multiple Objects in Advanced Invalidations

When multiple objects share a common URL, request POST body, or an embedded URL parameter, you can express the common elements in multiple ways:

Common URL:
- Use the URL Expression field in the Advanced Content Invalidation page (Operations > Advanced Content Invalidation) in OracleAS Web Cache Manager.
- Use the URIEXP attribute of the ADVANCEDSELECTOR element.
- Use the OTHER element of the ADVANCEDSELECTOR element with a NAME attribute value of URI.
Common request POST body:
- Use the HTTP Method and POST Body Expression fields in the Advanced Content Invalidation page.
- Use the METHOD and BODYEXP attributes of the ADVANCEDSELECTOR element.
- Use the OTHER element of the ADVANCEDSELECTOR element with a NAME attribute value of BODY.
Common embedded URL parameter:
- Use the URL Parameters section in the Advanced Content Invalidation page.
- Use the OTHER element of the ADVANCEDSELECTOR element with a NAME attribute value of QUERYSTRING_PARAMETER.

For the quickest invalidation, Oracle Corporation recommends using the OTHER element to specify a substring for literal matching rather than regular expression for pattern matching.

To send an advanced invalidation request with substring matching, use either XML message syntax or OracleAS Web Cache Manager. Table 11-5 compares the steps for each.

Table 11-5 Configuring Invalidation Requests to Use Substring Matching

XML Message...	OracleAS Web Cache Manager...
Specify the `OTHER` element in a manual invalidation request that uses the `ADVANCEDSELECTOR` element. Specify the `NAME` attribute to use a value of `URI`, `BODY`, or `QUERYSTRING_PARAMETER`. Specify the `TYPE` attribute to use a value of `SUBSTRING`. Specify the `VALUE` attribute to use the value of `URI`, `BODY`, or `QUERYSTRING_PARAMETER`.	Use the substring option for the URL Expression field, POST Body Expression field, or URL Parameters section in the Advanced Content Invalidation page (Operations > Advanced Content Invalidation) in OracleAS Web Cache Manager.

For example, the following request searches for any documents below http://www.company.com:1100/pls/portal/!PORTAL.wwpro_app_provider.execute_portlet/595897563/, that match the following criteria:

The HTTP request method is an HTTP POST request method.
The URI contains the substring showPortlet.Show.
The HTTP POST body contains the substring _language=EN-US.
The HTTP request headers are x-oracle-cache-user and x-oracle-cache-subid with respective values of PORTAL and 1.

The embedded URL parameters exactly match _portlet_id and _provider_id.

<?xml version="1.0"?>
<!DOCTYPE INVALIDATION SYSTEM
"http://www.oracle.com/webcache/90400/WCSinvalidation.dtd">
<INVALIDATION VERSION="WCS-1.1">
  <OBJECT>
    <ADVANCEDSELECTOR
URIPREFIX="/pls/portal/!PORTAL.wwpro_app_provider.execute_portlet/595897563/"
HOST="wc-cluster.company.com:1100" METHOD="POST">
      <OTHER NAME="QUERYSTRING_PARAMETER" TYPE="SUBSTRING"
VALUE="_portlet_id=2"/>
      <OTHER NAME="QUERYSTRING_PARAMETER" TYPE="SUBSTRING"
VALUE="_provider_id=595897563"/>
      <HEADER NAME="x-oracle-cache-user" VALUE="PORTAL"/>
      <HEADER NAME="x-oracle-cache-subid" VALUE="1"/>
      <OTHER NAME="BODY" TYPE="SUBSTRING" VALUE="_language=EN-US"/>
      <OTHER NAME="URI" TYPE="SUBSTRING" VALUE="showPortlet.Show"/>
    </ADVANCEDSELECTOR>
    <ACTION REMOVALTTL="0"/>
    <INFO VALUE="Invalidate an old portlet based on portlet ID and
provider ID"/>
  </OBJECT>
</INVALIDATION>

Enhance Query String Invalidations

If you are using the QUERYSTRING_PARAMETER in an invalidation request, it can take additional processing time for OracleAS Web Cache to match and invalidate the objects.

To optimize the invalidation process for query string invalidations:

Use a text editor to open the webcache.xml file.

Locate the SECURITY and WATCHDOG elements:

...
  <SECURITY>
    <USER .../>
    <USER .../>
    <SECURESUBNET ...>
    </SECURESUBNET>
    <DEBUGINFO HEADER="YES" BODY="NO"/>
  </SECURITY>      

  <WATCHDOG ENABLE="YES"/>
...

Between the SECURITY and WATCHDOG elements, add an INVALIDATIONINDEX element in the following format:

  <SECURITY>
  ...
  </SECURITY>

  <INVALIDATIONINDEX>
   <INDEXPARAM VALUE="NAME_OF_QUERYSTRING_PARAMETER"/>
   <INDEXPARAM VALUE="NAME_OF_QUERYSTRING_PARAMETER"/>
  </INVALIDATIONINDEX>

  <WATCHDOG ENABLE="YES|NO"/>

Restart OracleAS Web Cache with the following command:
```
opmnctl restartproc ias-component=WebCache
```

The following example request invalidates all documents under /corporate/asp/ matching the substring /view_building.asp and the embedded URL parameter value pairs of building=8 and floor=10. In addition, the request provides the comment "remove-view-building8-10th-floor" to be included in the invalidation result and event log.

<?xml version="1.0"?>
<!DOCTYPE INVALIDATION SYSTEM "internal:///WCSinvalidation.dtd">
<INVALIDATION VERSION="WCS-1.1">
  <OBJECT>
    <ADVANCEDSELECTOR URIPREFIX="/corporate/asp/"
                      HOST="www.company.com:80">
      <OTHER NAME="URI" TYPE="SUBSTRING" VALUE="/view_building.asp"/>
      <OTHER NAME="QUERYSTRING_PARAMETER" TYPE="SUBSTRING" VALUE="building=8"/>
      <OTHER NAME="QUERYSTRING_PARAMETER" TYPE="SUBSTRING" VALUE="floor=10"/>
    </ADVANCEDSELECTOR>
    <ACTION REMOVALTTL="0" />
    <INFO VALUE="remove-view-building8-10th-floor"/>
  </OBJECT>
</INVALIDATION>

To optimize this search, update webcache.xml file with the following:

...
  <SECURITY>
  ...
  </SECURITY>      

  <INVALIDATIONINDEX>
    <INDEXPARAM VALUE="building"/>
    <INDEXPARAM VALUE="floor"/>
  </INVALIDATIONINDEX>

  <WATCHDOG ENABLE="YES"/>
...

See Also:

Table 11-1, " INVALIDATION Elements and Attributes" for a description of the invalidation request syntax

"Example: Invalidating Documents Using Substring and Query String Matching"

Using Search Keys in Surrogate-Key Response Header and Invalidation Requests

You can base invalidation on one or more search keys used in the Surrogate-Key response-header field of objects in the cache.

To enable this feature:

Configure the HTTP response with the Surrogate-Key response-header field as follows:
```
Surrogate-Key: search-key=("key" "key" "key" ...)
```
See Also:
"Surrogate-Key Response-Header Field" for a complete description of the Surrogate-Key response-header field

By default, OracleAS Web Cache supports up to 20 search keys. To increase the limit:
1. Use a text editor to open the webcache.xml file.
2. Locate the MAXSEARCHKEYSPERDOC in the SEARCHKEYOPTIONS element:
```
 <SEARCHKEYOPTIONS  ENABLE="YES" MAXSEARCHKEYSPERDOC="20"/>
```
3. Modify the value to larger value.
  
  The following example shows a search key limit of 35.
```
...
<GLOBALCACHINGRULES TREATPARAMETERSASSET="YES">
      <SEARCHKEYOPTIONS ENABLE="YES" MAXSEARCHKEYSPERDOC="35"/>
      <URLREWRITERULE
...
```

Specify the search key in the invalidation request using one of the following methods:

Use the Search Keys section the Advanced Content Invalidation page (Operations > Advanced Content Invalidation) in OracleAS Web Cache Manager.

Specify the OTHER element in a manual XML invalidation request to use the ADVANCEDSELECTOR element, and specify the NAME and VALUE attributes to use SEARCHKEY and the search key value, respectively.

See Also:

"Submitting Advanced Invalidation Requests" for instructions on using OracleAS Web Cache Manager

Table 11-1, " INVALIDATION Elements and Attributes" for a description of manual invalidation request syntax

"Example: Invalidating Documents Using Search Key Matching" for an example scenario

11 Sending Invalidation Requests

Invalidation from External Sources

Figure 11-1 Invalidation

Using Telnet to Send Invalidation Requests

Invalidation Request Syntax

Table 11-1 INVALIDATION Elements and Attributes

Invalidation Response Syntax

Table 11-2 INVALIDATIONRESULT Elements and Attributes

Invalidation Preview Request Syntax

Table 11-3 INVALIDATIONPREVIEW Attributes

Invalidation Preview Response Syntax

Table 11-4 INVALIDATIONPREVIEWRESULT Elements and Attributes

Using OracleAS Web Cache Manager to Send Invalidation Requests

Submitting Basic Invalidation Requests

Submitting Advanced Invalidation Requests

Using Applications for Automated Invalidation Requests

Using Database Triggers for Automated Invalidation Requests

Using Scripts for Automated Invalidations

Invalidation Examples

Example: Invalidating One Document

Example: Invalidating Multiple Objects

Example: Invalidating a Subtree of Documents

Example: Invalidating All Documents for a Web Site

Example: Invalidating Documents Using Prefix Matching

Example: Invalidating Documents Using Substring and Query String Matching

Example: Invalidating Documents Using Search Key Matching

Example: Propagating Invalidation Requests Throughout a Cache Cluster

Example: Previewing Invalidation

Inline Invalidation in HTTP Response

Example: Using Inline Invalidation

Example 11-1 show_bike.pl Code

Example 11-2 buy_bike.pl Code with an Inline Invalidation Request

Example 11-3 Browser Response of buy_bike.pl

Debugging Tips

Example 11-4 Browser Response of show_bike.pl with Diagnostic Inline Invalidation Information

Reducing Invalidation Overhead

Send Basic Invalidation Requests for Invalidating One Object

Use Substring Matching for Invalidating Multiple Objects in Advanced Invalidations

Table 11-5 Configuring Invalidation Requests to Use Substring Matching

Enhance Query String Invalidations

Using Search Keys in Surrogate-Key Response Header and Invalidation Requests

11
Sending Invalidation Requests