Script for Setting File Permissions on UNIX

6 Caching and Compressing Content 6-1 6 Caching and Compressing Content This chapter introduces techniques to cache and compress content using Oracle Web Cache. It discusses cache population, consistency, and rules. The chapter describes the properties for configuring caching rules and expiration policies. This chapter includes the following topics: ■ Section 6.1, About Cache Population ■ Section 6.2, About Cache Consistency ■ Section 6.3, About Caching Decisions ■ Section 6.4, Introduction to Creating Caching Rules ■ Section 6.5, Introduction to Configuring Advanced Settings ■ Section 6.6, Basic Tasks for Configuring and Monitoring Caching Rules ■ Section 6.7, Configuring Expiration Policies ■ Section 6.8, Configuring and Monitoring Caching Rules ■ Section 6.9, Monitoring Summary Settings for Caching Rules ■ Section 6.10, Using the Surrogate-Control Response Header as an Alternative to Caching Rules

6.1 About Cache Population

You define caching rules to determine which objects to cache. When you establish a caching rule, objects matching the rule are not cached until there is a client request for them. When a client first requests an object, Oracle Web Cache sends the request to the origin server . This request is a cache miss . Because this URL has an associated caching rule, Oracle Web Cache caches the object for subsequent requests. When Oracle Web Cache receives a second request for the same object, Oracle Web Cache serves the object from its cache to the client. This request is a cache hit . When you stop Oracle Web Cache, the cache clears all objects. In addition, Oracle Web Cache clears and resets statistics. See Section 6.3 for a description of how Oracle Web Cache determines cache population through caching rules.

6.2 About Cache Consistency

Consistency is crucial for the reliability of Oracle Web Cache. The following features ensure consistency between the cache and origin servers: 6-2 Oracle Fusion Middleware Administrators Guide for Oracle Web Cache ■ Section 6.2.1, Expiration ■ Section 6.2.2, HTTP Cache Validation ■ Section 6.2.3, Invalidation

6.2.1 Expiration

With expiration , Oracle Web Cache marks objects as invalid after a certain amount of time in the cache. Expirations are useful if you can accurately predict when content changes on an origin server or database. To prevent objects from remaining in the cache indefinitely, Oracle recommends creating expiration policies for all cached objects. For instructions on creating expiration policies, see Section 6.7 .

6.2.2 HTTP Cache Validation

Oracle Web Cache uses HTTP1.1 validation models to determine how to best serve a response to clients. Validation works by the comparing two validators to determine if they represent the same or different entities. Specifically, Oracle Web Cache uses the If-Modified-Since and If-None-Match headers to determine the following validity: ■ Browser header is valid as compared with the cached copys header ■ Cached copys header is valid as compared with the origin servers header For further information about validation, see: ■ Section 13.3 Validation Model of the HTTP1.1 specification available at http:www.ietf.orgrfcrfc2616.txt for further information about the validation caching ■ Section 6.2.3 for instructions on invalidating content ■ Section 6.7 for instructions on configuring expiration policies

6.2.3 Invalidation

You use invalidation for content that does not have predictable expiration times. 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. For further information about invalidation, see Chapter 7, Invalidating Content.

6.3 About Caching Decisions

You can choose to cache or not to cache content for static objects, multiple-version objects, personalized pages, pages that support a session cookie , embedded URL parameter , or POST body parameter , and dynamic pages with caching rules. Note: Oracle Web Cache does not support weak validators for the If-None-Match validator. Oracle Web Cache supports all other If-None-Match request-header field formatting. Caching and Compressing Content 6-3 You configure a caching rule by specifying caching attributes based on the URL or the Content-Type response header with Fusion Middleware Control, or you set the caching attributes for a specific object within a Surrogate-Control response-header field. Those objects matching the rule are not cached until there is a client request for them. Oracle Web Cache uses the following priority to determine object cacheability: 1. Surrogate-Control response header 2. Caching rule configured with Fusion Middleware Control 3. Other HTTP headers: ■ Authorization request header ■ Proxy-Authorization request header ■ Pragma: no-cache response header ■ Warning response header If any of these headers are present, then Oracle Web Cache does not cache the object. 4. Cookie values from Cookie request header and Set-Cookie response header 5. Cache-Control response header 6. Expires response header The Surrogate-Control response-header field enables the origin server to override the caching rules configured through Fusion Middleware Control. When both a Surrogate-Control response header and a caching rule for the same object are present, Oracle Web Cache merges the two. For example, if there is a caching rule for an non-cacheable object set in Fusion Middleware Control with compression enabled, and the response header contains Surrogate-Control: max-age=30+60, then Oracle Web Cache respects both settings. Oracle Web Cache uses the max-age control directive from the Surrogate-Control response-header to cache the object and the compression setting from the caching rule. If there is a conflict between the Surrogate-Control response header and a caching rule, then Oracle Web Cache uses the settings from the Surrogate-Control response header. If no caching rules or the Surrogate-Control response header are specified, then Oracle Web Cache behaves just as HTTP proxy cache does, that is, it relies on HTTP header information to determine what is cacheable. Generally, HTTP proxy caches store only pages with static content. For a description of how Oracle Web Cache determines cache population, see Section 6.1 . Notes: ■ You can pre-populate the cache using Web crawler freeware such as WGET to warm up the cache on restart or after bulk invalidation operations. See http:www.gnu.orgsoftwarewgetwget.html for further information about WGET. ■ When you stop Oracle Web Cache, all objects are cleared from the cache. In addition, all statistics are cleared.