Skip Headers

Oracle Application Server Web Cache Administrator's Guide
10g (9.0.4)
Part Number B10401-01
Go To Documentation Library
Home		 Go To Product List
Solution Area		 Go To Table Of Contents
Contents		 Go To Index
Index

Go to previous page Go to next page

2
Caching Concepts

This chapter explains how OracleAS Web Cache is populated with content, how that content maintains consistency, and how dynamically generated content is assembled and cached.

This chapter contains these topics:

Cache Population

Caching rules determine which objects are cached. When a caching rule for a particular URL is first established, those objects contained within the URL are not cached until there is a browser request for them. When a document is first requested, OracleAS Web Cache appends a Surrogate-Capability request-header field to the document. The Surrogate-Capability request-header field identifies that the document passed through the cache. OracleAS Web Cache then sends the request to the origin server. This is a cache miss. If the requested document is specified as one of the documents to cache, then OracleAS Web Cache caches the document for subsequent requests. When the document is subsequently requested, OracleAS Web Cache serves the document from its cache to the browser. This is a cache hit.

You configure a caching rule by specifying caching attributes based on the URL with OracleAS Web Cache Manager, or you configure the caching attributes for a specific object within a Surrogate-Control response-header field. OracleAS Web Cache uses the following priority to determine how documents are processed by the cache:

  1. Surrogate-Control response header

  2. Caching rule configured with OracleAS Web Cache Manager

  3. Other HTTP headers:

    • Authorization request header

    • Proxy-Authorization request header

    • Pragma: no-cache response header

    • Warning response header

    • Cookie request header

    • Set-Cookie response header

    If none of the headers are present, OracleAS Web Cache looks first for the Cache-Control response header and then the Expires response header.

The Surrogate-Control response-header field enables the origin server to override the caching rules configured through OracleAS Web Cache Manager. When both a Surrogate-Control response header and a caching rule for the same object are present, OracleAS Web Cache merges the two. For example, if there a caching rule for an non-cacheable object set in OracleAS Web Cache Manager with compression enabled, and the response header contains Surrogate-Control: max-age=30+60, then OracleAS Web Cache respects both settings. OracleAS 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 configured with OracleAS Web Cache Manager, then OracleAS Web Cache uses the settings from the Surrogate-Control response header.

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.org/software/wget/wget.html for further information about WGET.

  • When you stop OracleAS Web Cache, all objects are cleared from the cache. In addition, all statistics are cleared.

How OracleAS Web Cache Processes Requests with a Range Request-Header Field

When the first browser request for a multi-part document with an HTTP Range request-header field comes in, OracleAS Web Cache sends the request to the origin server. OracleAS Web Cache serves the entire document received from the origin server response to the browser, and OracleAS Web Cache caches the entire document for the request. For a subsequent request for the document, OracleAS Web Cache serves only the part requested from the browser.

Cache Consistency and Performance Assurance

Consistency and performance are crucial for the reliability of OracleAS Web Cache. The following features ensure consistency between the cache and origin servers:

Invalidation

Invalidation is intended for frequently changing content. With invalidation, documents are marked as invalid. When documents are marked as invalid and a browser requests them, they are removed and then refreshed with new content from the origin servers. You can choose to remove and refresh invalid documents immediately, or base the removal and refresh on the current load of the origin servers.

Propagation of invalidation messages from one OracleAS Web Cache server to another occurs in the following deployments:

Invalidation in Hierarchies

In a configuration with a hierarchy of OracleAS Web Cache servers, it is likely that content will be cached on multiple servers.

Figure 2-1 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.

When an invalidation message is sent to the central cache to refresh content, the central cache automatically propagates the invalidation message to the remote cache in Japan to ensure consistency.

Figure 2-1 Scenario 1: Invalidating Content in a Distributed Cache Hierarchy

Text description of owcag058.gif follows

Text description of the illustration owcag058.gif

Figure 2-2 depicts an ESI cache hierarchy. A subscriber cache performs Edge Side Includes (ESI) assembly. Provider caches locally cache ESI fragments for ESI provider sites www.providersite1.com and www.providersite2.com. During ESI page assembly, the subscriber cache contacts the provider caches for the ESI fragments.

Figure 2-2 Scenario 2: Invalidating Content in an ESI Cache Hierarchy

Text description of owcag053.gif follows

Text description of the illustration owcag053.gif

When an invalidation message is sent to a central or provider cache to refresh content, the central or provider cache automatically propagates the invalidation message to the remote or subscriber cache to ensure consistency.

To ensure that the central or provider cache only invalidates its content, the remote or subscriber cache checks the site host name specified in the invalidation message with the IP address of the provider cache from which the invalidation message propagated. If there is a match, the remote or subscriber cache processes the invalidation request. Otherwise, the request is rejected. For distributed cache hierarchies, the site host name for the central and remote caches should be configured to be identical, making a mismatch unlikely.

See Also:

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 OracleAS 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, OracleAS Web Cache returns an error message and does not propagate the invalidation messages.

See Also:

Chapter 11, "Sending Invalidation Requests" for instructions on invalidating content

Expiration

With expiration, documents are marked as invalid after a certain amount of time in the cache. Expirations are useful if it can be accurately predicated when content will change on an origin server or database. To prevent documents from remaining in the cache indefinitely, Oracle Corporation recommends creating expiration policies for all cache documents.

See Also:

"Configuring Caching Rules and Rule Association" and "Configuring Expiration Policies" for instructions on creating expiration policies

HTTP Cache Validation

OracleAS Web Cache uses HTTP/1.1 validation models to determine how to best serve a response to browsers. Validation works by the comparing two validators, one in the request header and the other in the cached document's response header, to determine if they represent the same or different entities. Specifically, OracleAS Web Cache uses the following validators for cache hits:

For non-cacheable documents, OracleAS Web Cache passes the If-Modified-Since and If-None-Match request headers to the origin server. In turn, the origin server responds with either an HTTP 304 Not Modified or HTTP 200 OK status code. For non-cacheable misses, OracleAS Web Cache removes these request headers before passing the requests to the origin server. After a document is cached, OracleAS Web Cache applies either the time comparison of If-Modified-Since or the entity tag match with ETag, as previously described.

Note:

OracleAS Web Cache does not support weak validators for the If-None-Match validator. OracleAS Web Cache supports all other If-None-Match request-header field formatting.

See Also:

Performance Assurance Heuristics

One could logically assume that widespread cache invalidation or expiration would negatively impact performance of the origin servers, resulting in the generation of HTTP 503 Server Unavailable errors to browsers. For this reason, OracleAS Web Cache intelligently serves some of the documents stale until the origin servers have the capacity to refresh them.

OracleAS Web Cache provides minimal trade-off between performance and consistency through performance assurance heuristics that determine which documents can be served stale. These heuristics are based on a number of factors including:

Together, these factors provide OracleAS Web Cache with a logical queue of content to update from the origin servers.

Figure 2-3 illustrates how performance assurance heuristics are used during widespread invalidation. Immediately after invalidation, the number of fresh documents served decreases to 20 documents for each second. However, the number of fresh cache hits quickly increases to 5,000 documents for each second over a short period of time. This is because OracleAS Web Cache refreshes the most popular documents first so that these documents have little chance of being served stale. After the popular documents are refreshed, the less popular documents are refreshed. The total number of documents that can be revalidated in a given period of time is dependent on origin server capacity. At the end of invalidation, only fresh content is served.

Figure 2-3 Performance Assurance Heuristics Graph

Text description of owcag008.gif follows

Text description of the illustration owcag008.gif

Note:

Performance assurance heuristics do not apply to documents configured to be removed and refreshed immediately.

Caching Dynamically Generated Content

Most Web pages today are dynamically generated before delivery to the browser. Web developers frequently use technologies like JavaServer Pages (JSP), Active Server Pages (ASP), PERL, PL/SQL Server Pages (PSP), servlets, PHP Hypertext Preprocessor (PHP), and Common Gateway Interface (CGI) to design their applications. Examples of pages that are dynamically generated include:

Because of invalidation, OracleAS Web Cache knows which documents are valid and which documents are invalid. This is especially important for dynamically generated content that changes frequently.

Most traditional static caches and content distribution services have no mechanism to verify the consistency of dynamically generated Web pages with the data sources used to create them. Therefore, it is difficult for these products and services to know when content has changed. OracleAS Web Cache, on the other hand, supports several mechanisms for receiving invalidation messages from the origin server containing the original content.

For dynamically generated pages, browsers pass information about themselves to the origin server, enabling the origin server to serve appropriate content to the browser.

The HTTP protocol has a way for browsers and origin servers to share information, such as session information, in message headers that browsers pass with every request to the origin server. This message header can contain a Set-Cookie request-header field that specifies a cookie and its value: 

Set-Cookie:cookie_name=value

Cookies are stored on the browser's file system and are often used for identifying users who revisit Web sites. Browsers send a request with a Cookie request-header field with the cookie name and value that was received in the last response: 

Cookie:cookie=value

Many users choose to disable cookies in their browsers because of privacy concerns. For this reason, applications often embed parameter information in the URL or POST body. OracleAS Web Cache accepts requests that use the following characters as delimiters for an embedded URL parameter, or POST body parameter: question mark (?), ampersand (&), dollar sign ($), or semi-colon (;).

OracleAS Web Cache recognizes cookies, embedded URL parameters, and POST body parameters, enabling you to configure caching rules for documents with the following characteristics:

Multiple Versions of the Same Document

Some pages have multiple versions, enabling categorization. Figure 2-4 shows the same document, https://oraclestore.oracle.com/OA_HTML/ibeCCtpItmDspRte.jsp?item=293017&section=11538, with different prices for customers and internal Oracle employees. While customers pass a cookie name and value of ec-400-id-acctcat=WALKIN, employees pass a cookie name and value of ec-400-id-acctcat=INTERNAL.

Figure 2-4 Multiple-Version Document

Text description of owcag020_plus.gif follows.

Text description of the illustration owcag020_plus.gif

You can configure OracleAS Web Cache to recognize and cache multiple-version pages by using the:

For those documents that use a cookie (sometimes referred to as a category cookie), configure caching rules that specify the cookie name and whether to cache versions of the document that do not use the cookie.

When a browser sends an initial request for a multiple-version document, OracleAS Web Cache passes the request to the origin server. In turn, the origin server includes a Set-Cookie response-header in the response with the category cookie and its value: 

Set-Cookie:cookie=value

Upon receiving the Set-Cookie response-header field, the browser stores the cookie in memory. With its next request to the same origin server, the browser includes the Cookie request-header field with the category cookie name and value that was received in the last response: 

Cookie:cookie=value

OracleAS Web Cache evaluates whether the cookie and its value set in the Set-Cookie response-header matches the cookie and its value set in the Cookie request-header. If the cookie and value match, then the response is cached. If cookie and its value do not match, then the response is not cached. After versions of the document are cached, OracleAS Web Cache uses the value of the cookie in the browser's request to serve the appropriate version of the document to the browser.

Note:

OracleAS Web Cache does not cache the Set-Cookie response header field.

Table 2-1 shows four different versions of same URL, http://www.dot.com/page1.htm. The URL uses a cookie named user_type, which supports browser requests that contain cookie values of Customer, Internal, and Promotional. You can configure OracleAS Web Cache to recognize the user_type cookie, enabling OracleAS Web Cache to cache three different documents. In addition, you can configure OracleAS Web Cache to cache a fourth document for those requests that do not use a cookie.

Table 2-1  Multiple-Version Document with Different Cookie Values
Version URL Cookie Name/Value

1

http://www.dot.com/page1.htm

user_type=Customer

2

http://www.dot.com/page1.htm

user_type=Internal

3

http://www.dot.com/page1.htm

user_type=Promotional

4

http://www.dot.com/page1.htm

No cookie

For those documents that have different versions based on HTTP request headers, configure caching rules that specify the HTTP request header. HTTP request headers enable Web browsers to pass additional information about the request and about themselves. OracleAS Web Cache uses the header to serve the appropriate version of the URL to browsers.

OracleAS Web Cache supports all valid HTTP request headers. Table 2-2 lists the HTTP request-header fields supported by the OracleAS Web Cache Manager interface, as described in "Configuring Caching Rules and Rule Association". You can specify other HTTP request-header fields with the Surrogate-Control response-header field, as described in "Configuring Expiration Policies".

Table 2-2  HTTP Request-Header Field
Header Field Description

Accept

Specifies which media types are acceptable for the response

Example: Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, image/png, */*

Accept-Charset

Specifies which character sets are acceptable for the response

Example: Accept-Charset: iso-8859-1,*,utf-8

Accept-Encoding

Restricts the content-encodings that are acceptable in the response

Example: Accept-Encoding: gzip

Accept-Language

Specifies the set of languages that are preferred as a response

Example: Accept-Language: en

User-Agent

Contains information about the Web browser that initiated the request

Example: User-Agent: Mozilla/4.61 [en] (WinNT; U)

Note:

By default, OracleAS Web Cache does not interpret the values of these HTTP request headers. If the values for two pages are different, OracleAS Web Cache caches both pages separately.

This issue is especially problematic with the User-Agent request header, whereby the browser type, version, and operating system can result in multiple cache entries. For example, if one request sends an HTTP request-header field of User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 4.0) and another request sends an HTTP request-header field of User-Agent: Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt) for different versions of Internet Explorer, OracleAS Web Cache serves two pages for the two requests.

You can override this behavior for the User-Agent request header by configuring OracleAS Web Cache to cache and serve the same page for the same browser type, as described in "Recognizing Similar Browser Types for Multiple-Version Documents Containing HTTP Request Headers".

Personalized Attributes

Many Web pages use a personalized attribute for personalized greetings like "Hello, Name," icons, addresses, or shopping cart snippets, on an otherwise generic page. You can mark the personalized attribute information with OracleAS Web Cache HTML tags <!-- WEBCACHETAG--> and <!-- WEBCACHEEND-->.

OracleAS Web Cache processes these tags and caches the instructions for substituting values for personalized attributes based on the information contained within a cookie, embedded URL parameter, or POST body parameter.

This functionality enables OracleAS Web Cache to use the same page for multiple users. Because only one page needs to be cached, only one origin server request is required to initially populate the cache with the page. The initial request sets the personalized attribute cookie or parameter. All subsequent requests for the page that pass the cookie or parameter are served from the cache.

Note:

To achieve personalization within an HTML tag, use ESI, as described in "Using ESI for Simple Personalization".

Figure 2-5 shows two users, Jane Doe and John Doe, accessing the same page, https://oraclestore.oracle.com/OA_HTML/ibeCZzpHome.jsp?a=b. This page contains a personalized greeting suited to the user.

Figure 2-5 Page with a Personalized Attribute

Text description of owcag021_plus.gif follows.

Text description of the illustration owcag021_plus.gif

The HTML code for the personalized greeting Jane Doe uses the following HTML code: 

<B>
<!-- WEBCACHETAG="person01"-->
Jane Doe
<!-- WEBCACHEEND-->
</B>

The HTML code for personalized greeting John Doe uses the following HTML code: 

<B>
<!-- WEBCACHETAG="person01"-->
John Doe
<!-- WEBCACHEEND-->
</B>

person01 represents the personalized attribute definition assigned to the person_name cookie that Jane and John pass to OracleAS Web Cache. Jane passes a cookie name/value pair of person_name=Jane+Doe, and John Doe passes a cookie name/value pair of person_name=John+Doe. When OracleAS Web Cache receives the cookie information from Jane and John, it maps the person_name cookie to the person01 personalized attribute definition and substitutes the cookie value.

If the page supported embedded URL parameters, then the URL would contain the person_name parameter. For example, the page for Jane Doe could be https://oraclestore.oracle.com/OA_HTML/ibeCZzpHome.jsp?a=b&person_name=Jane+Doe, and the page for John Doe could be https://oraclestore.oracle.com/OA_HTML/ibeCZzpHome.jsp?a=b&person_name=John+Doe. You could configure OracleAS Web Cache with a personalized attribute definition of person_name01 to map to the person_name embedded URL parameter. OracleAS Web Cache would then use the value of the embedded parameter to substitute the appropriate name.

If the page supported POST body parameters, then the POST body for https://oraclestore.oracle.com/OA_HTML/ibeCZzpHome.jsp would contain the following code for Jane Doe and John Doe: 

person_name=Jane+Doe
&cart_items=0
&a=b

person_name=John+Doe
&cart_items=0
&a=b

To substitute personalized attribute values:

  1. Configure a personalized attribute definition with the personalized attribute cookie, embedded URL parameter, or POST body parameter.

  2. Configure a caching rule with the option Session-Encoded URL enabled. Only requests matching the caching rule will perform the substitution.

If a request does not contain the value of the cookie or parameter, OracleAS Web Cache substitutes the personalized attribute with a default string.

See Also:

"Configuring Rules for Popular Pages with Session Establishment"

Note:

You can also substitute session values between the
<!-- WEBCACHETAG--> and <!-- WEBCACHEEND--> tags. To substitute session values:

  1. Configure a session definition with the session cookie, embedded URL parameter, or POST body parameter.

  2. Configure a caching rule with the option Session-Encoded URL enabled. Only requests matching the caching rule will perform the substitution.

See Also: "Configuring Rules for Popular Pages with Session Establishment"

Controlling How Personalized Attribute Requests Are Served by the Cache

You can specify how OracleAS Web Cache serves requests with the existence or nonexistence of personalized-attribute cookies, embedded URL parameters, or POST body parameters. You can choose to:

For example, if you want to require that the request get the cookie or parameter settings from the origin server, then choose to serve cached documents to requests that have the cookie or parameter, but do not serve cached documents to requests that do not have the personalized attribute cookie or parameter.

When you choose to serve for both, you can then specify if requests with or without the cookie or parameter can share the same cached document. OracleAS Web Cache uses a default string for those requests without the cookie or parameter.

To specify how personalized attribute pages are served by OracleAS Web Cache:

  1. Configure a personalized attribute definition that specifies the name of the cookie, embedded URL parameter, or POST body parameter.

  2. Specify the behavior for caching documents with or without personalized attribute information by defining a personalized attribute-related caching rule.

  3. Associate URLs with the personalized attribute-related caching rule.

    See Also:

    "Configuring Session or Personalized Attribute Caching Policies"

Session Information

Some Web sites keep track of user sessions by assigning each user a unique session ID. When a browser first accesses a Web site that uses session IDs, the origin server includes a Set-Cookie response-header in the response with the session cookie and value in order to establish a session: 

Set-Cookie:cookie=value

Upon receiving the Set-Cookie response-header field, the browser stores the cookie in memory. With its next request to the same origin server, the browser includes the Cookie request-header field with the cookie name and value that was received in the last response: 

Cookie:cookie=value

Because of the Cookie request-header field, the origin server determines that the browser already has a session and uses the value of the session to keep track of the browser state.

When returning a response to a request that already has a session, the origin server may or may not send a Set-Cookie header. If it does send it, it may or may not change the session cookie value. Origin servers really only need to send this response-header field to establish new cookies or change the value of the cookies.

Alternatively, origin servers can track a session with the browser by including the session value in an embedded URL or POST body parameter. With its next request to the same origin server, the browser includes the embedded URL or POST body parameter. Because of the embedded URL or POST body parameter, the origin server determines that the browser already has a session.

Using session information in a cookie, embedded URL parameter, or POST body parameter, you can configure OracleAS Web Cache for the following purposes:

Excluding the Value of Embedded URL or POST Body Parameters

By default, OracleAS Web Cache distinguishes origin server responses by the request URLs. However, if the request URL contains an embedded URL or POST body session parameter, the request URL to the same page content is distinct for each session. Therefore, OracleAS Web Cache caches responses for each of the distinct URLs. This can result in low cache hit rates and redundantly cached documents.

You can configure OracleAS Web Cache to ignore the value of embedded URL or POST body parameters so that one cached document is served to multiple sessions requesting the same page. OracleAS Web Cache will then cache the response to the first request and serve subsequent requests for the page from its cache.

Consider user Jane Doe accessing a page with a request URL of: 

https://oraclestore.oracle.com/OA_HTML/ibeCCtpSctDspRte.jsp?section=10103&session_ID=33436

User John Doe requests the same page with a request URL of: 

https://oraclestore.oracle.com/OA_HTML/ibeCCtpSctDspRte.jsp?section=10103&session_ID=33437

Likewise, each request the URL https://oraclestore.oracle.com/OA_HTML/ibeCCtpSctDspRte.jsp with the following POST body for Jane Doe and John Doe, respectively: 

section=1013
&session_ID=3346

section=1013
&session_ID=3347

The only distinct part is the value of the session_ID parameter. Rather than caching and serving two versions of the same document, you can configure OracleAS Web Cache to ignore the value of session_ID so that one cached document can be served to both users.

To ignore the value of embedded URL or POST body parameters, configure a session definition in OracleAS Web Cache that specifies the name of the session embedded URL parameter. Because you specify a session definition for a site or for all sites, the specified embedded URL or POST body parameter will be ignored for all requests to the relevant sites.

See Also:

"Configuring Session Definitions to Exclude the Value of Embedded URL or POST Parameters"

Substituting Session Information in Session-Encoded URLs

The section "Excluding the Value of Embedded URL or POST Body Parameters" describes how you can ignore the value of embedded URL or POST body parameters for documents with identical content for all sessions. However, in some cases, the HTML content of documents is programmed with hyperlink tags, such as <A HREF=...>, that contain embedded session information to distinguish users. These links are called session-encoded URLs. The use of session-encoded URLs results in responses that vary slightly from session to session.

You can configure OracleAS Web Cache to substitute sessions within HTML hyperlink tags with the session values obtained from a session cookie, embedded URL parameter, or POST body parameter. By configuring session value substitution in combination with ignoring the value of embedded URL parameters, you can configure OracleAS Web Cache to cache one document for multiple sessions, even if the session parameter values in session-encoded URLs vary.

Note:

OracleAS Web Cache does not cache the Set-Cookie response header field.

Continuing with the example from "Excluding the Value of Embedded URL or POST Body Parameters", assume that Jane Doe and John Doe are again assigned an embedded URL parameters of session_ID=33436 and session_ID=33437 by the origin server. The page shown in Figure 2-6 has several <A HREF=...> links that include the session_ID parameter. The Master Index link under the Oracle9i Release 1 (9.0.1) heading for Jane Doe uses the following HTML code: 

<A HREF="https://oraclestore.oracle.com/OA_
HTML/ibeCCtpSctDspRte.jsp?section=11886&session_ID=334326">Master Index</A>

The same link for John Doe uses the following HTML code: 

<A HREF="https://oraclestore.oracle.com/OA_
HTML/ibeCCtpSctDspRte.jsp?section=11886&session_ID=334327">Master Index</A>

By using the value of the session_ID embedded URL parameter, OracleAS Web Cache substitutes the correct session information for Jane Doe and John Doe.

Figure 2-6 Session-Encoded URLs

Text description of session.gif follows.

Text description of the illustration session.gif

After the cache is populated with a page that contains session-encoded URLs, other requests for the page are served from the cache, regardless of whether the request has a session cookie, embedded URL parameter, or POST body parameter. If the request does not contain a session cookie or embedded URL parameter, OracleAS Web Cache substitutes the session information in the session-encoded URLs with a configurable default string.

To substitute session values in session-encoded URLs:

  1. Configure a session definition with the session cookie, embedded URL parameter, or POST body parameter. You can use the same session definition used for ignoring a URL parameter. When creating the session definition, configure the default string.

  2. Configure a caching rule with Session-Encoded URL enabled. Only requests matching the caching rule will perform the substitution.

    See Also:

    "Configuring Support for Session-Encoded URLs"

Controlling How Session Requests Are Served by the Cache

You can specify how OracleAS Web Cache serves requests with the existence or nonexistence of session cookies, embedded URL parameters, or POST body parameters. You can choose to:

For example, if you want the first request of a new user to establish a session from the origin server, then choose to serve cached documents to requests that have the session cookie or parameter, but do not serve cached documents to requests that do not have the session cookie or parameter.

When you choose to serve for both, you can then specify if requests with or without the session cookie or parameter can share the same cached document. OracleAS Web Cache uses a default string for those requests without the cookie or parameter.

To specify how session-related pages are served by OracleAS Web Cache:

  1. Configure a session definition that specifies the name of the session cookie, embedded URL parameter, or POST body parameter.

  2. Specify the behavior for caching documents with or without session information by defining a session-caching policy.

  3. Associate URLs with the session-caching policy.

    See Also:

Content Assembly and Partial Page Caching

OracleAS Web Cache provides dynamic assembly of Web pages with both cacheable and non-cacheable page fragments. It provides for assembly by enabling Web pages to be divided into fragments of differing caching profiles. These fragments are maintained as separate elements in the cache. The fragments are assembled into HTML pages as appropriate when requested by end users.

By enabling dynamic assembly of Web pages on OracleAS Web Cache rather than on the origin servers, you can choose to cache some of the fragments of assembled pages. With partial page caching, much more HTML content can be cached, and then assembled and delivered by OracleAS Web Cache when requested. Furthermore, page assembly can be conditional, based on information provided in HTTP request headers or end-user cookies.

The section contains the following topics:

Page Assembly Components

The basic structure that an application developer uses to create content for partial-page caching is a template page containing fragments. As depicted in Figure 2-7, the template consists of common elements, such as a logo, navigation bars, framework, and other "look and feel" elements of the page. The fragments represent dynamic subsections of the page.

Figure 2-7 Template Page

Text description of owcag026_150.gif follows.

Text description of the illustration owcag026_150.gif

The template page is associated with the URL that end users request. To include the fragments, the template page is configured with ESI markup tags that tell OracleAS Web Cache to fetch and include the HTML fragments. The fragments themselves are HTML files containing discrete text or other objects.

Each included fragment is a separate object with its own caching policy. Content providers may want to cache the template for several days, but only cache a particular fragment, such as an advertisement or stock quote, for a matter of seconds or minutes. Other fragments (such as a user's bank account total) may be declared non-cacheable.

Table 2-3 provides a summary of the main ESI tags.

Table 2-3  Summary of ESI Tags
Tag Description

<esi:choose>

Performs conditional processing based on Boolean expressions

<esi:comment>

Specifies comments not be included in the output

<esi:environment>

Allows variable access from an HTTP response

<esi:include>

Includes an HTML fragment

<esi:inline>

Marks a fragment as a separately cacheable fragment, embedded in the HTTP response of another object

<esi:invalidate>

Specifies an invalidation request within the response of a browser page

<esi:remove>

Specifies non-ESI markup if ESI processing is not enabled

<esi:try>

Specifies alternate processing when a request fails because the origin server is not accessible

<esi:vars>

Permits variable substitution for environment variables

Example 2-1 shows the ESI markup language for the template page shown in Figure 2-7.

Example 2-1 ESI Markup

<HTML>
<HEAD>
<TITLE>
Company.com
</TITLE>
</HEAD>
<BODY>
...
<!-- The following <esi:comment> tags are removed if this page is processed by 
an ESI processor. -->

<!--esi

 <esi:comment text="This is the HTML source when ESI is enabled." />

 <esi:comment text="Start: The quick link section. You cannot use the standard 
HTML comments because the end of that comment tag would disrupt
the HTML comment tag with 'esi' following the two '-'." />

 <esi:comment text="The URI query string parameter 'sessionID' is used to carry 
session identifiers, The session ID is encoded in all links." />

 <esi:comment text="'Profile' refers to environment variables stored in 
GetProfile.jsp. GetProfile.jsp enables access to 'PersonalInterest.' 'zipcode,' 
'tickers,' and 'address' environment variables." />

 <esi:environment src="/GetProfile.jsp?sessionID=$(QUERY_STRING{sessionID})"
name="Profile" />

<esi:vars>
   <A HREF="/shopping.jsp?sessionID=$(QUERY_STRING{sessionID})">
     <IMG SRC="/img/shopping.gif">
   </A>
   <A HREF="/news.jsp?sessionID=$(QUERY_STRING{sessionID})">
     <IMG SRC="/img/news.gif">
   </A>
   <A HREF="/sports.jsp?sessionID=$(QUERY_STRING{sessionID})">
     <IMG SRC="/img/sports.gif">
   </A>
   <A HREF="/fun.jsp?sessionID=$(QUERY_STRING{sessionID})">
     <img src="/img/fun.gif">
  </A>
  <A HREF="/about.jsp?sessionID=$(QUERY_STRING{sessionID})">
     <iMG SRC="/img/about.gif">
   </A>
 </esi:vars>

 <esi:comment text="End: The quick link section" />
...
 <H3>Local Weather</H3>
 <esi:include src="/weather.jsp?sessionID=$(QUERY_
STRING{sessionID})&zipcode=$(Profile{zipcode})" />
...

 <H3>Stock Quotes</H3>
 <esi:try>
   <esi:attempt>
     <esi:include src="/CompanyStock.jsp?sessionID=$(QUERY_ 
STRING{sessionID})&tickers=$(Profiles{tickers})" />
   </esi:attempt>
   <esi:except>
     The company stock quote is temporarily unavailable.
   </esi:except>
 </esi:try>
...
 <H3>What's New at Company</H3>
 <!-- This section is a static file that does not carry session information -->
 <esi:include src="/whatisnew.html" />

...

 <H3>Today's News</h3>
 <esi:choose>

   <esi:when test="$(Profile{PersonalInterests}) == 'Sports'">
     <H4>Sport News</H4>
     <esi:include src="/SportNews.jsp?sessionID=$(QUERY_STRING{sessionID})" />
   </esi:when>

   <esi:when test="$(Profile{PersonalInterests}) == 'Career'">
     <H4>Financial News</H4>
     <esi:include src="/FinancialNews.jsp?sessionID=$(QUERY_STRING{sessionID})" 
/>
   </esi:when>

   <esi:otherwise>
     <H4>General News</H4>
     <esi:include src="/DefaultNews.jsp?sessionID=$(QUERY_STRING{sessionID})" />
   </esi:otherwise>

 </esi:choose>

...

-->

<!-- This is the HTML source when ESI is disabled. -->
<esi:remove>
Alternative HTML source that does not use ESI goes here. This tag enables you   
to disable ESI on the fly without redeveloping or redeploying a different 
version of the page. 
</esi:remove>
...
</BODY>
</HTML>

Example 2-2 shows the XML response of GetProfile.jsp, which provides access to profile environment variables.

Example 2-2 GetProfile.jsp XML Response

<?xml version=1.0?>
<esi:environment esiversion="ORAESI/9.0.2">
  <PersonalInterests>Sports</PersonalInterests>
  <zipcode>94065</zipcode>
  <tickers>ORCL,YHOO</tickers>
  <address>500 Oracle Parkway, Redwood Shores, CA 94065</address>
</esi:environment>

Fragmentation with the Inline and Include Tags

The <esi:inline> and <esi:include> tags enable applications to adopt ESI page fragmentation and assembly. The following sections describe the tags and explain when the tags are appropriate to use.

Using Inline for Non-Fetchable Fragmentation

Most existing applications are only designed to output an entire Web page to HTTP requests. These fragments and templates are non-fetchable, meaning they are not to be fetched independently from the origin server. If a cache needs any of these fragments or templates, the corresponding full Web page must be requested. To use ESI page assembly for non-fetchable fragments, an application can output the full page response just as it does normally, with the exception that at the beginning and the end of each fragment, an <esi:inline> tag is inserted with a fragment name to demarcate the fragment. OracleAS Web Cache stores the enclosed portions as separate fragments and the original page as a page template without the enclosed fragments. Fragments are shared among templates if their names are identical and they are from the same site.

Example 2-3 shows a simple <esi:inline> example. The HTML table enclosed by the <esi:inline> tag is the fragment content. The area preceding <esi:inline name="/news101"> and the area following </esi:inline> form the page template. If another page contains an <esi:inline> tag with the same name "/news101", the two fragments logically share the same content.

Example 2-3 Inline Non-Fetchable Example

<HTML>
...
<esi:inline name="/news101">
<TABLE>
...
</TABLE>
</esi:inline>
...
</HTML>

When an application uses non-fetchable <esi:inline> fragments, the full page must be requested for every cache miss. At first, it can appear that there is no apparent cache benefit for cache misses. However, non-fetchable <esi:inline> fragments improves overall caching by:

To invalidate non-fetchable fragments, you must invalidate both the template document and the non-fetchable fragments to ensure the fragments are invalidated.

See Also:

Chapter 11 for details about sending invalidation requests

Using Inline for Fetchable Fragmentation

<esi:inline> fragments are by default non-fetchable. If an application supports independently fetchable fragments, it is possible to use the <esi:inline> for fetchable fragments by setting the fetchable attribute to yes.

Example 2-4 shows an <esi:inline> example with a fetchable fragment named /news101. A request for the page returns the template page and the fetchable fragment.

Example 2-4 Inline Fetchable Example

<HTML>
...
<esi:inline name="/news101" fetchable="yes">
<TABLE>
...
</TABLE>
</esi:inline>
...
</HTML>

See Also:

"ESI inline Tag" for further information about the fetchable attribute

Using Include for Fragmentation

The <esi:include> tag is another way to define fragments and templates in an HTTP output for dynamic content caching and assembly. It is in many ways similar to the <esi:inline> tag. It defines a name for the defined fragment. The page including an <esi:include> tag is a template that references the defined fragment. However, it also has some key differences which make its applicable scenarios very different from those of <esi:inline>:

There are at least two scenarios where using <esi:include> tags is beneficial:

Example 2-1 shows ESI markup with <esi:include> tags.

Referer Request-Header Field

When OracleAS Web Cache receives a browser request for a template page with a Referer request-header field, it forwards the request with the Referer request header to the origin server. In turn, the origin server returns fragments to OracleAS Web Cache with the URL of the template as the value for the Referer header. This functionality associates the fragment request with the template request.

Cookie Management for Template Pages and Fragments

Session cookie establishment for ESI templates and fragments works much the same way as typical OracleAS Web Cache documents with the following additional features:

ESI Features

ESI can be used with HTML, XML, JSP, ASP, and any Web programming technology. The ESI language includes the following features:

ESI for Java (JESI)

OC4J provides the JESI tag library as a convenient interface to ESI tags and functionality. Developers have the option of using ESI tags directly in any Web application, but JESI tags provide additional convenience in a JSP environment.

Because ESI and JESI are open standards, you can use the JESI tag library in any standard JSP environment as long as an ESI processor, such as OracleAS Web Cache, is available.

Even though JSP developers can always use ESI, JESI provides an even easier way for JSP developers to express the modularity of pages and the cacheability of those modules, without requiring developers to learn a new syntax.

See Also:

Request and Response-Header Fields

OracleAS Web Cache provides support for the following HTTP request and response-header fields:

Oracle-ECID Request-Header Field

The Oracle-ECID request header is used to track requests as they move through the Oracle Application Server architecture. This information is especially useful for diagnostic purposes. Because OracleAS Web Cache is the initial receiver of browser requests, it sets the request header before forwarding a cache miss to an origin server. The Oracle-ECID request header takes the following format: 

Oracle-ECID: request_id, sequence_number

In the format, request_id is a 64-bit unique integer for the request, and sequence_number is the hop number of the request as it passes through Oracle Application Server. OracleAS Web Cache always assigns an initial sequence number of 0 to a request. As a request passes from OracleAS Web Cache to other Oracle Application Server components, the request ID remains constant, but the sequence number increments with each hop.

You can configure OracleAS Web Cache to log the request ID and sequence number from the Oracle-ECID request header in the event and access logs. To display the Oracle-ECID request header in the logs, you enable Include Request Details for the event log, and select the x-ecid field for the access logs. The x-ecid field is provided by the Web Cache Log Format (WCLF). Additionally, you can configure Oracle HTTP Server to log the Oracle-ECID request header information, enabling you to correlate events at different Oracle Application Server stops for the same request.

See Also:

Chapter 12 for further information about displaying the Oracle-ECID request header information in the event and access logs

Surrogate-Capability Request-Header Field

For each requested document from the cache, OracleAS Web Cache appends a Surrogate-Capability request-header field to a document's HTTP request message. The Surrogate-Capability request-header serves the following purposes:

The Surrogate-Capability request-header enables OracleAS Web Cache to identify the operations it is capable of performing to origin servers acting as caches. The Surrogate-Capability request-header field supports the following syntax: 

Surrogate-Capability: orcl="operation_value operation_value ..."

where "operation_value" is one or more of the following:

The values "ORAESI/9.0.2", "ESI/1.0", and "ESI-Inline/1.0" are subsets of "ORAESI/9.0.4". In this release, you specify only "ORAESI/9.0.4" for ESI assembly, "ESI-INV/1.0" for inline invalidation, or "webcache/1.0" for personalized attributes.

See Also:

Table 15-1 for further information about the ESI tags supported for each "operation_value"

Server Response-Header Field

For documents sent to browsers, OracleAS Web Cache adds diagnostic information to the Server response-header field of the HTTP response message: 

Server: OracleAS/version Server_header_from_origin_server 
OracleAS-Web-Cache/version (diagnostic_information)

The Server response-header field specifies name/value pairs for Oracle HTTP Server and OracleAS Web Cache. The information for OracleAS Web Cache includes version and diagnostic information.

diagnostic_information has the following format: 

{ESI_processing_type}{cache_request_type}[;max-age=expiration_time[+removal_
time];age=document_age]

Table 2-4 describes the diagnostic fields.

Table 2-4  Control Directives for Server
Control Directive Description

ESI_processing_type

ESI_processing_type can be one of the following:

  • T specifies that the document is an ESI template

  • F specifies that the document is an ESI fragment

  • empty specifies that the response does not require ESI processing

cache_request_type

cache_request_type can be one of the following:

  • H specifies a cache hit

  • S specifies a cache hit of a stale document

  • U specifies a cache update of a stale document

  • G specifies a cache update of a document that was marked for removal but still physically resides in the cache

  • M specifies a cache miss

  • N specifies a non-cacheable cache miss

max-age="expiration_time[+removal_time]

Specifies the time, in seconds, to expire the document, and optionally, the time, in seconds, to remove the document from the cache after the expiration time. max_age does not appear if the cache_request_type is N.

age=document_age

Shows how long, in seconds, the document has been in the cache

age does not appear if the document is non-cacheable.

Using the Server response header information, you can determine whether a request was served from the cache or the application Web server. In the following example, the Server field specifies that the document was a cache hit: 

Server: OracleAS/9.0.4 Oracle HTTP Server Powered by Apache/1.3.12 (Unix)
mod_plsql/3.0.9.8.3b ApacheJServ/1.1 mod_perl/1.24
OracleAS-Web-Cache/9.0.4.0.0 (TH;max-age=60+30;age=55)

(TH;max-age=60+30;age=55) is the diagnostic information.

To display the Server response header in the access logs, you select the sc(Server) field. You must configure the sc(Server) field as a user-defined access log format.

See Also:

Surrogate-Control Response-Header Field

The Surrogate-Control response-header field enables application developers to specify caching attributes of an object. This response-header field enables the application Web server to override the caching rules configured through the OracleAS Web Cache Manager interface.

See Also:

"Cache Population" for a description of how OracleAS Web Cache determines when to use caching attributes from the Surrogate-Control and OracleAS Web Cache Manager

The Surrogate-Control response-header field supports the following syntax: 

Surrogate-Control:[content=content_type, content_type,..]
[no-store][no-store-remote][max-age=expiration_time[+removal_
time]][vary=headers(header header...)][coookie(cookie_name cookie_
name...)][compress=yes|no]

Table 2-5 describes the supported control directives.

Table 2-5  Control Directives for Surrogate-Control
Control Directive Description

content

Specify what kind of processing is required:

  • "ORAESI/9.0.4" to process ESI tags with Oracle-proprietary additions for content assembly and partial page caching. "ORAESI/9.0.4" supports all the ESI tags provided by OracleAS Web Cache in release 9.0.4.

  • "ORAESI/9.0.2" to process ESI tags with Oracle proprietary additions for content assembly and partial page caching. "ORAESI/9.0.2" supports all the ESI tags provided by OracleAS Web Cache through release 9.0.2.

  • "ESI/1.0" to process standard ESI tags for content assembly and partial page caching

  • "ESI-Inline/1.0" to process <esi:inline> tags

  • "ESI-INV/1.0" to process <esi:invalidate> tags

  • "webcache/1.0" to process the <!-- WEBCACHETAG--> and
    <!-- WEBCACHEEND--> tags for personalized attributes

"ORAESI/9.0.2", "ESI/1.0", and "ESI-Inline/1.0" are subsets of "ORAESI/9.0.4". In this release, you specify only "ORAESI/9.0.4" for ESI assembly, "ESI-INV/1.0" for inline invalidation, or "webcache/1.0" for personalized attributes.

See Also: Table 15-1 for further information about the ESI tags supported for each processing version

no-store

Specify that OracleAS Web Cache not cache the document.

no-store-remote

Specify to not allow other ESI-compliant caches, such as a third-party Content Delivery Network (CDN), to cache the document.

The no-store-remote directive has similar semantics to the no-store directive, except that it is only be honored by remote caches. Generally, this means those caches that are more than one or two hops from the application Web server, such as caches in a CDN.

This directive is especially useful if you want to cache changing content locally, where invalidation propagation is immediate, but not in a distributed network of upstream ESI processors, where invalidation may take several minutes.

vary

Specify the HTTP request headers or cookies from which OracleAS Web Cache will use to cache and identify multiple-version documents. Use the following format:

vary=[headers(header[/f] *);] [cookies(cookie_name[/f] *)]

Specify /f to instruct OracleAS Web Cache to only cache versions of the document based on the existence of the HTTP request headers or cookies. Exclude /f to instruct OracleAS Web Cache to cache versions of the document, regardless of whether the HTTP request headers or cookies exist.

Usage notes:

  • Specify at least one HTTP header or cookie

  • If you specify both HTTP request headers and cookies, specify the HTTP request header before the cookies

  • Use zero or more spaces between the parentheses and semicolons

  • When specifying multiple HTTP request headers or cookies, use one or more spaces between the HTTP request headers and cookie names

compress

Specify yes for OracleAS Web Cache to serve compressed cacheable and non-cacheable documents to all browser types; specify no for OracleAS Web Cache to not serve compressed cacheable and non-cacheable documents to browsers.

This control directive does not enable you to specify browser types. If you specify yes and need to limit the browser types, specify a compression caching rule in OracleAS Web Cache Manager, as described in Step 12 of "Task 1: Create Caching Rules".

Notes: Oracle Corporation recommends not compressing images, such as GIFs, JPEGs, BMPs, SWFs, and PNGs. By default, OracleAS Web Cache does not compress these files. Oracle Corporation also recommends not compressing executables and files that are already zipped with utilities like WinZip and GZIP. Compressing these files incurs additional overhead without the benefits of compression.

Even if compression enabled, OracleAS Web Cache does not compress documents containing the following:

  • A Content-Encoding response-header field, which is typically used to denote compression

  • A Content-Disposition response-header field, which is typically used for attachments

max-age

Specify that OracleAS Web Cache cache the document.

Specify the time, in seconds, to expire the document after it enters the cache. Optionally, specify the time, in seconds, to remove the document from the cache after the expiration time. Use the following format:

max-age=expiration_time[+removal_time]

Usage notes:

  • The default removal time is 0 seconds

  • max-age=infinity specifies that the document never expires

Usage Notes
Example Usage

In the following example, the Surrogate-Control response-header field specifies that the document is to expire 30 seconds after it enters the cache and be removed 60 seconds after expiration. It also specifies that the document contains ESI tags that require processing: 

Surrogate-Control: max-age=30+60, content="ORAESI/9.0.4"

In the following example, the Surrogate-Control response-header field specifies that the document 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 document, regardless of whether the request contains the HTTP Accept request header. 

Surrogate-Control: content="ORAESI/9.0.4", vary=headers(Accept)

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 document only if the request contains the Accept and MyCustomHeader headers and news and sports cookies. 

Surrogate-Control: content="ORAESI/9.0.4", vary=headers(Accept/f);cookies(news/f 
sports/f)

Surrogate-Key Response-Header Field

The Surrogate-Key response-header field enables application developers to identify search key strings for a given response object. Search keys are strings that may not appear in the URL, cookies, or HTTP request headers of objects. The intent of the search keys is to provide another criteria for invalidation. In addition to the URL of objects, OracleAS Web Cache administrators can base invalidation on one or more search keys used in the Surrogate-Key response-header field of objects in the cache.

The Surrogate-Key response-header field supports the following syntax: 

Surrogate-Key: search-key=("key" "key" "key" ...)
Usage Notes
Example Usage

The following examples show valid Surrogate-Key fields. The first example shows one search key of template_id=33,31345, and the second example shows search keys of template_id=33,31345 and category. 

Surrogate-Key: search-key=( "template_id=33,31345"  )

Surrogate-Key: search-key=("template_id=33,31345" "category")

The following examples show invalid Surrogate-Key fields. The first example shows one search key of 348 without an ending quote ("), and the second example shows search-key without any search key values. 

Surrogate-Key: search-key=( "template_id=33,31345 )

Surrogate-Key: search-key=( )

See Also:

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

Go to previous page Go to next page
Oracle
Copyright © 2002, 2003 Oracle Corporation.
All Rights Reserved.
Go To Documentation Library
Home		 Go To Product List
Solution Area		 Go To Table Of Contents
Contents		 Go To Index
Index