Surrogate-Control Response-Header Field Using the Surrogate-Control Response Header as an Alternative to Caching Rules

Caching and Compressing Content 6-25 Usage Notes ■ Control directives are case sensitive. ■ content=ORAESI9.0.4, content=ESI-Inline1.0, content=ESI-INV1.0, content=ESI1.0 are mutually exclusive with content=webcache1.0 Refer to http:www.esi.orgspec.html for the Edge Architecture Specification, which contains specification information about the Surrogate-Control response header. Example Usage In the following example, the Surrogate-Control response-header field specifies that the object is to expire 30 seconds after it enters the cache and be removed 60 seconds after expiration. It also specifies that the object contains ESI tags that require processing: Surrogate-Control: max-age=30+60, content=ORAESI9.0.4 In the following example, the Surrogate-Control response-header field specifies that the object is not to be cached: Surrogate-Control: no-store In the following example, the Surrogate-Control response-header field specifies ESI processing with the content control directive. The vary control directive specifies to cache versions of the multiple-version object based on the HTTP Accept request header value, regardless of whether the request contains the HTTP Accept request header. Surrogate-Control: content=ORAESI9.0.4, vary=headersAccept In the following similar example, the Surrogate-Control response-header field specifies ESI processing with the content control directive. The vary control directive specifies to cache versions of the multiple-version object only if the request contains the Accept and MyCustomHeader headers and news and sports cookies. Surrogate-Control: content=ORAESI9.0.4, vary=headersAcceptf MyCustomHeaderf;cookiesnewsf sportsf 6-26 Oracle Fusion Middleware Administrators Guide for Oracle Web Cache 7 Invalidating Content 7-1 7 Invalidating Content This chapter explains how to send invalidation requests to Oracle Web Cache. This chapter includes the following topics: ■ Section 7.1, Overview of Invalidation ■ Section 7.2, About Out-of-Band Invalidations ■ Section 7.3, About ESI Inline Invalidations ■ Section 7.4, About Response Header Invalidations ■ Section 7.5, Format of Invalidation Requests for Out-of-Band and ESI Inline Mechanisms ■ Section 7.6, About Search Keys in Invalidations ■ Section 7.7, Initiating Out-of-Band Invalidations ■ Section 7.8, Enabling Response-Header Invalidation ■ Section 7.9, Enabling Search Keys for Invalidations ■ Section 7.10, Security Considerations

7.1 Overview of Invalidation

As described in Section 6.7 , you create expiration policies and associate them with caching rules to refresh content from the origin server. Even with expiration policies, it is often difficult to predict when exactly content becomes stale. As an alternative, Oracle Web Cache provides mechanisms for explicitly invalidating content when an administrator or application knows that such content has become stale. With invalidation, Oracle Web Cache marks objects as invalid. When objects are marked as invalid and a client requests them, they are removed and then refreshed with new content from the origin servers. You can choose to remove and refresh invalid objects immediately, or base the removal and refresh on the current load of the origin servers. Oracle Web Cache supports the following forms of invalidation: ■ Invalidation through a special invalidation port. This type of invalidation is known as an out-of-band invalidation, because such invalidation requests do not go through the Oracle Web Cache listening port. See Section 7.2 . ■ ESI inline invalidation where the invalidation directive comes as an ESI tag through the response body to a normal request. See Section 7.3 . 7-2 Oracle Fusion Middleware Administrators Guide for Oracle Web Cache ■ Response-header invalidation where the invalidation directive comes as a special and proprietary response header in the response to a normal request. See Section 7.4 .

7.2 About Out-of-Band Invalidations

To invalidate objects in the cache, you can send an HTTP POST request from the invalidator account through the invalidation listening port. The invalidator account is authorized to send invalidation requests. As shown in Figure 7–1 , you send invalidation requests using these methods: ■ Manually, using Fusion Middleware Control or telnet ■ Automatically, using database triggers, scripts, or application logic Figure 7–1 Invalidation The following sections describe the specific methods you can use: ■ Section 7.7.1, Using Telnet to Send Invalidation Requests ■ Section 7.7.2, Using Oracle Web Cache Manager to Send Invalidation Requests ■ Section 7.7.3, Using Application Program Interfaces APIs for Automated Invalidation Requests ■ Section 7.7.4, Using Database Triggers for Automated Invalidation Requests ■ Section 7.7.5, Using Scripts for Automated Invalidations

7.3 About ESI Inline Invalidations

Inline invalidation is implemented as part of Edge Side Includes ESI and provides a useful way for origin servers to piggyback invalidation messages on HTTP responses sent to Oracle Web Cache. Specifically, origin servers embed an XML invalidation document within the HTML of the response body using ESI tags. Oracle Database Application Server Oracle Web Cache Internet Browser Running Oracle Web Cache Manager Manual or Scripted Programmatic Database Trigger Invalidating Content 7-3 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. For more information about using ESI invalidation, see Section 11.3 .

7.4 About Response Header Invalidations

Response header invalidation is Oracle Web Cache functionality that enables an origin server to return a transactional response whose response body contains something other than HTML. This is a circumstance in which ESI inline invalidation does not work; Oracle Web Cache can only use ESI invalidation tags in conjunction with a response body that contains HTML. With response header invalidation, origin servers can send invalidation directives in a proprietary invalidation response header. In addition to its greater flexibility in terms of response body content returned, response header invalidation requires less coding effort on the part of the Web applications since building an invalidation header is a fairly lightweight task. Response header invalidation functions similarly to inline invalidation; origin servers piggyback invalidation directives on responses sent to Oracle Web Cache. However, the response header invalidation enables invalidation when the response body contains something other than HTML. The origin server adds a special invalidation header to its response. Oracle Web Cache extracts the invalidation header, invalidates the corresponding content and forwards the response to its client but without the invalidation header in the response. Origin Servers can piggyback an invalidation response header on any random response. For example, an origin server may delay the sending of an invalidation directive and then send it later in a response to a request that has nothing to do with the request that caused the invalidation in the first place. Oracle Web Cache strips out the invalidation response header when returning the response to a Web client. Oracle Web Cache even strips out the invalidation response header when returning the response to another member of an cache cluster, since cluster propagation forwards the invalidation to other peers in the cluster. For more information about enabling response header invalidation, see Section 7.8 .

7.5 Format of Invalidation Requests for Out-of-Band and ESI Inline Mechanisms

The out-of-band mechanisms send out-of-band HTTP POST invalidation requests in Extensible Markup Language XML syntax. The ESI inline mechanism also uses the same syntax within the esi:invalidate tag. The contents of the XML request body instructs the cache which URLs to mark as invalid. The following sections describe invalidation request syntax: ■ Section 7.5.1, Invalidation Request Syntax ■ Section 7.5.2, Invalidation Response Syntax ■ Section 7.5.3, Invalidation Preview Request Syntax ■ Section 7.5.4, Invalidation Preview Response Syntax ■ Section 7.5.5, Invalidation Examples