Exceptions and Errors Introduction to ESI for Partial Page Caching

11-16 Oracle Fusion Middleware Administrators Guide for Oracle Web Cache It does not enclose an embedded fragment directly in the template. As a result, a template with esi:include tags can be applied to multiple users. In contrast, a template with embedded esi:inline tags must be unique to each user. ■ A fragment referenced by an esi:include tag must always be independently fetchable by HTTP or HTTPS. The requested URL equals the fragment name. In contrast, an esi:inline tags name only identifies the uniqueness of the fragment and is not used to fetch the actual content. The attribute defining the fragment name in esi:include fragment is src instead of name. There are at least two scenarios where using esi:include tags is beneficial: ■ Some applications, such as a Web portal, naturally assemble content from external sources. The application only provides a template that is used to fetch various fragments from third-party sources. In this case, the esi:include tags fetch and assemble directly, reducing one layer of redundancy. ■ Some applications offer faster responses for template-only requests than full-page requests that use esi:inline tags. If esi:include is used for page fragmentation and assembly, Oracle Web Cache can miss only on the templates when most or all fragments are already cached, saving effective cache miss cost. In many cases, it is also valuable to cache the personalized templates because these seldom change. Example 11–1 on page 11-3 shows ESI markup with esi:include tags.

11.1.8.4 Selecting the Fragmentation Mechanism for Your Application

Although both esi:include and esi:inline enable Oracle Web Cache to fetch fragments for the client browser, esi:include is more robust for performing this task and provides an easy way in which to manage fragments. Because esi:include affects the application flow, it is best to incorporate esi:include early in the design phase of an application. For an existing application, esi:inline is better mechanism because it requires minimal change to your application.

11.1.9 Referer Request-Header Field

When Oracle Web Cache receives a client 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 Oracle 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.

11.1.10 Cookie Management for Template Pages and Fragments

Session cookie establishment for ESI templates and fragments works much the same way as typical Oracle Web Cache objects with the following additional features: ■ Cookie request-header field inheritance When a client requests an ESI template page that includes fragments, requests for fragment pages are generated in Oracle Web Cache. A fragment request inherits the Cookie request-header field from the template request if the value of the Host request-header field matches the value of Host request-header field in the template request. ■ Set-Cookie response-header field accumulation Caching Dynamic Content with ESI Language Tags 11-17 When assembly of fragments is complete, Oracle Web Cache includes a Set-Cookie response-header field in the response with the cookie information from the template. For those fragments with a Host request-header field that matches the Host request-header field in the template, Oracle Web Cache also accumulates the Set-Cookie response-header fields with that of the template. For those fragments with a Host request-header field that does not match the Host request-header field in the template, Oracle Web Cache does not accumulate the Set-Cookie response-header field with that of the template and other matching fragments. See Section 11.1.6 for a description of how you can use the HTTP_COOKIE variable in ESI markup.

11.2 Enabling Dynamic Assembly of Content and Partial Page Caching

For an overview of partial page caching, see Section 11.1 . This section describes how to enable dynamic assembly of Web pages with fragments and how to create rules for the cacheable and non-cacheable page fragments. It contains the following topics: ■ Section 11.2.1, Enabling Partial Page Caching ■ Section 11.2.2, Using ESI for Simple Personalization ■ Section 11.2.3, Examples of ESI Usage

11.2.1 Enabling Partial Page Caching

To enable partial page caching:

1. Configure the template page as follows:

a. Use ESI markup tags in the template to fetch and include the fragments.

b. In the template page, configure the HTTP response with the

Surrogate-Control response-header field. For example: Surrogate-Control: max-age=30+60, content=ORAESI9.0.4

c. If the Surrogate-Control response-header field does not include all the

caching attributes required for the template page, create a caching rule for the page.

2. Configure the fetchable fragments:

■ Use a Surrogate-Control response-header field in the HTTP response message. ■ If the Surrogate-Control response-header field does not include all the caching attributes required for the fragment, create a caching rule for the fragment. For more information, see: Important: ESI tags cannot be used on a page that contains -- WEBCACHETAG-- and -- WEBCACHEEND-- tags. If you require simple personalization and are using ESI, see Section 11.2.2, Using ESI for Simple Personalization .