Example Usage Enabling Response-Header Invalidation

7-30 Oracle Fusion Middleware Administrators Guide for Oracle Web Cache

7.8.1.3 Asychronous Invalidation

In the examples so far, we have not specified a synchronicity directive, so by default Oracle Web Cache would complete the invalidation before returning the response to the client. If Harry wanted the example from Section 7.8.1.2 to proceed asynchronously, that is, if he did not want Oracle Web Cache to wait for the invalidation to complete before returning the response, his Web application could send an invalidation response header that looks like this: Oracle-WebCache-Invalidate: SYNCHRONOUS=OFF, URI_DIR=http:www.harryshardware.comproductstoolshammers Notice that the response header above contained a fully qualified URI directory. If the original request specified the host name www.harryshardware.com explicitly, the application could return an invalidation response header with a path-only URI directory: Oracle-WebCache-Invalidate: SYNCHRONOUS=OFF, URI_DIR=productstoolshammers

7.8.1.4 Search Key Invalidation with Explicit URI

Suppose that Harry wants to reduce the price of all TrueSaw saws but not the handsaws, just the power saws for example, skill saws and chainsaws. His Web application could invalidate all the necessary entries with an invalidation response header that looks like this: Oracle-WebCache-Invalidate: URI_ DIR=http:www.harryshardware.comproductstoolssaws;S_KEY=PowerTool; S_KEY=TrueSaw Notice the addition of the S_KEY directives to ensure the invalidation of only TrueSaw power saws. Remember, when an invalidation response header contains multiple directives separated by semicolons, an Oracle Web Cache entry must match all directives for the invalidation to take place. Notice also that the response header above contained a fully qualified URI directory. If the original request specified the host name www.harryshardware.com explicitly, the application could return an invalidation response header with a path-only URI directory: Oracle-WebCache-Invalidate: URI_DIR=productstoolssaws;S_KEY=PowerTool;S_ KEY=TrueSaw

7.8.1.5 Search Key Invalidation with Implicit URI

Suppose that Harry sets up an additional site for selling large appliances dishwashers, refrigerators, etc.. Suppose also that he defines this site using a path prefix of productsappliances. The following Table 7–6 are the site definitions for the Web site: Table 7–6 Web Site Definitions Scheme Host Port Number Path Prefix http www.harryshardware.c om 80 productsappliances Invalidating Content 7-31 The first site pertains strictly to large appliances; the second site applies to everything else in Harrys store. Suppose further that Harry changes the price for all KeepCold refrigerators and that the site definition for an incoming request pertains to Harrys appliance site; scheme http, host name www.harryshardware.com, optional port 80 and path prefix of productsappliances. His Web application could invalidate all the necessary entries with an invalidation response header that looks like this: S_KEY=KeepCold;S_KEY=Refrigerators Notice that the invalidation response header contains only search key directives; it does not contain a URI directory directive. When this happens, Oracle Web Cache forms an implicit URI directory from the site definition associated with the incoming request. In this case the implicit directory corresponds to: http:www.harryshardware.comproductsappliances As before, with multiple directives separated by semicolons, an Oracle Web Cache entry must match all directives for the invalidation to take place. The equivalent invalidation response header with an explicit, fully qualified URI directory would look like this: Oracle-WebCache-Invalidate: URI_ DIR=http:www.harryshardware.comproductsappliances;S_KEY=KeepCold; S_KEY=Refrigerators The equivalent invalidation response header with an explicit, path-only URI directory would look like this: Oracle-WebCache-Invalidate: URI_DIR=productsappliances;S_KEY=PowerTool; S_KEY=TrueSaw

7.8.1.6 Multiple Invalidation Directives

Suppose that Harry wants to upgrade his entire inventory of drills and wrenches. His Web application could invalidate all the necessary entries with a response containing the following invalidation response header: Oracle-WebCache-Invalidate: URI_ DIR=http:www.harryshardware.comproductstoolsdrills, URI_DIR=http:www.harryshardware.comproductstoolswrenches Remember, when an invalidation response header contains two consecutive invalidation specifications separated by a comma, an Oracle Web Cache entry only needs to match one invalidation specification for the invalidation to take place. Notice that the response header above contained fully qualified URI directories. If the original request specified the host name www.harryshardware.com explicitly, the application could return an invalidation response header with path-only URI directories: Oracle-WebCache-Invalidate: URI_DIR=productstoolsdrills, URI_ http www.harryshardware.c om 80 Table 7–6 Cont. Web Site Definitions Scheme Host Port Number Path Prefix 7-32 Oracle Fusion Middleware Administrators Guide for Oracle Web Cache DIR=productstoolswrenches

7.8.1.7 Mixing Commas and Semicolons

Suppose that Harry wants to put both the Thor hammer and all TrueSaw power saws on sale. His Web application could invalidate all the necessary entries with a response containing the following invalidation response header: Oracle-WebCache-Invalidate: URI=http:www.harryshardware.comproductstoolshammersThor.html, URI_DIR=http:www.harryshardware.comproductstoolssaws;S_KEY=PowerTools;S_ KEY=TrueSaw Notice the use of both the comma and semicolon as separators. In this instance, the first directive consists of only the URI for the Thor hammer. The second directive consists of three invalidation specifications: the URI directory for saws and the search keys for Power Tools and TrueSaw tools. Semicolons take precedence over commas. Notice also that the response header above contained a fully qualified URI and a fully qualified URI directory. If the original request specified the host name www.harryshardware.com explicitly, the application could return an invalidation response header with a path-only URI and a path-only URI directory: Oracle-WebCache-Invalidate: URI=productstoolshammersThor.html URI_DIR=productstoolssaws;S_KEY=PowerTools;S_KEY=TrueSaw

7.8.1.8 Multiple Invalidation Response Headers

Returning to the example of Section 7.8.1.6 , a Web application, alternatively, could invalidate all the necessary entries with a response containing two separate invalidation response headers: Oracle-WebCache-Invalidate: URI_ DIR=http:www.harryshardware.comproductstoolsdrills Oracle-WebCache-Invalidate: URI_ DIR=http:www.harryshardware.comproductstoolswrenches The directives from two different invalidation response headers in the same response are treated as if they were separate directives in a single response header—that is, they are treated as if they were separated by commas in a single invalidation response header. Notice, too, the response headers contained a fully qualified URI directory. If the original request specified the host name www.harryshardware.com explicitly, the application could return invalidation response headers with path-only URI directories: Oracle-WebCache-Invalidate: URI_DIR=productstoolsdrills Oracle-WebCache-Invalidate: URI_DIR=productstoolswrenches

7.9 Enabling Search Keys for Invalidations

To enable this feature: 1. Configure the HTTP response with the Surrogate-Key response-header field as follows: Surrogate-Key: search-key=key key key ... See Section 7.6 for a complete description of the Surrogate-Key response-header field. By default, Oracle Web Cache supports up to 20 search keys. To increase the limit: Invalidating Content 7-33 a. Use a text editor to open the webcache.xml file. b. Locate the MAXSEARCHKEYSPERDOC attribute in the SEARCHKEYOPTIONS element: GLOBALCACHINGRULES SEARCHKEYOPTIONS ENABLE=YES MAXSEARCHKEYSPERDOC=20 ERRORPAGES c. Modify the value to larger value. The following example shows a search key limit of 35. GLOBALCACHINGRULES SEARCHKEYOPTIONS ENABLE=YES MAXSEARCHKEYSPERDOC=35 ERRORPAGES d. Save webcache.xml. 2. Specify the search key in the invalidation request using these methods: ■ For out-of-band invalidations: – Use the Search Keys section from the Advanced Content Invalidation page Operations Advanced Content Invalidation of Oracle Web Cache Manager. See Section 7.7.2 for instructions on using Oracle 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 Section 7.5.1 . ■ For ESI inline invalidations, specify the esi:invalidate tag with the OTHER element to use the ADVANCEDSELECTOR element, and specify the NAME and VALUE attributes to use SEARCHKEY and the search key value, respectively. See Section 11.4.6 . ■ For response header invalidation, specify the S_KEY option directive. See Section 7.8 .

7.10 Security Considerations

This section covers the following topics: ■ Section 7.10.1, About the invalidator account ■ Section 7.10.2, Propagation of Invalidation Messages

7.10.1 About the invalidator account

To invalidate objects in the cache, send an HTTP POST request from the invalidator account through an invalidation listening port. The invalidator account is an administrator authorized to send invalidation requests. See Section 5.2 for further information about configuring password security. 7-34 Oracle Fusion Middleware Administrators Guide for Oracle Web Cache

7.10.2 Propagation of Invalidation Messages

Propagation of invalidation messages from one Oracle Web Cache server to another occurs in the following deployments: ■ Cache cluster with multiple Oracle Web Cache servers ■ Cache hierarchy whereby one Oracle Web Cache server acts as an origin server to another Oracle Web Cache server

7.10.2.1 Invalidation in Cache Clusters

In a cache cluster, administrators can decide whether to propagate invalidation messages to all cache cluster members or to send invalidation messages individually to cache cluster members. When Oracle Web Cache propagates invalidation messages, the cache that received the invalidation request acts as the invalidation coordinator for that request. The coordinator propagates the invalidation messages to the other cluster members. The coordinator waits for responses from all cluster members. When the propagation completes, the coordinator returns a message to the sender that lists, for each cluster member, the cluster member name, the status of the invalidation request, and the number of objects invalidated. If any cluster member cannot be reached, Oracle Web Cache returns an error message and does not propagate the invalidation messages. During a cache cluster upgrade, you upgrade one cache cluster member at a time. The caches continue to respond to requests. However, because other cluster members have a different version of the configuration, the caches do not forward invalidation messages to those cache cluster members operating with a different version. Instead, if the requested object is not cached by that cache or by cluster members with the same version of the configuration, Oracle Web Cache forwards the request to the origin server. When the cache cluster members are not running the same version of Oracle Web Cache, you can still invalidate objects, and you can propagate the invalidation to other cluster members, but the invalidation message must originate from the cache that is operating with the earlier version of Oracle Web Cache. See the Oracle Fusion Middleware Upgrade Planning Guide for more information about upgrading Oracle Web Cache to 11g Release 1 11.1.1, including information about upgrading cache cluster members

7.10.2.2 Invalidation in Hierarchies

In a configuration with a hierarchy of Oracle Web Cache servers, a cache hierarchy , it is likely that content is cached on multiple servers. Figure 7–2 depicts a distributed cache hierarchy . A central cache is located in the United States office, and a remote cache is located in the Japan office. While the central cache stores content from an application Web server, the remote cache stores content from the central cache. In other words, the central cache acts as an origin server to the remote cache in Japan. The central cache uses the invalidator account name and password of the remote or subscriber Oracle Web Cache server. The invalidation request specifies the objects to invalidate, as well as the site host name of the objects. The site host name is compared with the IP address of the cache from which the invalidation request was propagated. If there is a match, the cache processes the invalidation request. Otherwise, the request is rejected.