10g (9.0.4)
Part Number B10401-01
 Home |
 Solution Area |
 Contents |
 Index |
| Oracle Application Server Web Cache Administrator's Guide 10g (9.0.4) Part Number B10401-01 |
|
This chapter explains how to configure caching rules.
This chapter contains these topics:
Using OracleAS Web Cache to specify caching rules, you can choose to cache or not to cache content for static documents, multiple-version documents, personalized pages, pages that support a session cookie, embedded URL parameter, or POST body parameter, and dynamic pages.
|
Note:
If no caching rules or |
|
See Also:
"Cache Population" for a description of how OracleAS Web Cache uses caching attributes from the |
To create a caching rule, you specify the following:
When OracleAS Web Cache receives a browser request, it uses selectors to filter through the caching rules to locate the appropriate rule for the request. During caching rule creation, you specify the following selectors:
The expression type is one of the following:
Specify the URL based on the expression type.
Specify the GET, GET with query string, or POST HTTP request methods of the objects.
POST body parameters
Specify any embedded URL parameters or embedded POST body parameters.
POST body expression
If the POST HTTP request method is selected, specify the HTTP POST body in regular expression syntax.
A file extension specifies a shared file extension type, such as gif. To specify a file extension, you simply enter the extension. Because OracleAS Web Cache internally starts the file extension with a period (.), it is not necessary to enter it. For example, both gif and .gif are valid entries.
A path prefix traverses the directory structure to locate the objects. Because OracleAS Web Cache internally starts the path with http://host_name:port/ or "/", it is not necessary to enter this information.
The prefix is interpreted literally, including reserved regular expression characters. These characters include periods (.), question marks (?), asterisks (*), brackets ([]), curly braces ({}), carets (^), dollar signs ($), and backslashes (\).
For example, a path prefix of http://www.company.com/contacts or /contacts matches objects under the contacts directory for the defined site www.company.com.
OracleAS Web Cache supports regular expression syntax based on the POSIX 1003 extended regular expressions for URLs, as supported by Netscape Proxy Server 2.5.
When using POSIX regular expression, keep the following syntax rules in mind:
^) to denote the beginning and a dollar sign ($) to denote the end of the URL.
If these characters are not used, POSIX assumes a substring match. For example, ^/a/b/.*\.gif$ will match GIF files under /a/b or any of its subdirectories. /a/b/.*\.gif, on the other hand, could match /x/y/a/b/c/d.gift.
.) to match any one character.
?) to match zero or one occurrence of the character that it follows.
*) to match zero or more occurrences of the pattern that it follows.
\) to escape any special characters, such as periods (\.), question marks (\?), or asterisks (\*).
See Also::
http://www.cs.utah.edu/dept/old/texinfo/regex/regex_toc.html for regular expression syntax
Table 9-1 shows examples of content to cache and how to enter regular expression syntax for corresponding caching rules for that content.
A caching policy specifies whether an object should be cached or not cached. A caching policy of Cache instructs OracleAS Web Cache to serve requests from objects in its cache; a caching policy of Don't Cache instructs OracleAS Web Cache to forward requests to the origin server and to not cache the content.
Examples of content that administrators typically declare non-cacheable include updating transactions, shopping cart views, and personal account views. One of the easiest ways to set up caching rules in OracleAS Web Cache is either to first specify the non-cacheable content, and then use a broad "catch-all" rule for the cacheable content, or to first specify the cacheable content followed by a non-cacheable catch-all rule. In practice, cacheable and non-cacheable rules can be interspersed.
A cache-key policy enables OracleAS Web Cache to map requests to the appropriate objects in the cache. After OracleAS Web Cache uses the selectors and caching policy to filter requests, it uses the cache-key policy to locate the correct object in the cache.
OracleAS Web Cache composes a cache-key with the following attributes that you specify:
Together, these attributes create a unique ID for a cached object, which OracleAS Web Cache then uses for request lookups.
You order the priority of caching rules. Higher priority rules are matched first.
When ordering caching rules for cacheable and non-cacheable documents, give the non-cacheable documents a higher priority than the cacheable documents. For example, if you want all URLs containing /cec/cstage?ecaction=ecpassthru to be cached except for /cec/cstage?ecaction=ecpassthru2, you would enter the rules with either regular expression or path prefix syntax, in the order shown in Table 9-2.
If the order were reversed, all documents starting with /cec/cstage?ecaction=ecpassthru would be cached, including /cec/cstage?ecaction=ecpassthru2.
In the rules shown in Table 9-3, Rule 2 caches documents of the URL that use the GET and GET with query string methods, and Rule 3 caches documents of the URL that use the POST method and a POST body matching action=search.
When OracleAS Web Cache is installed, site-specific and global caching rules are established for the configured default site.
Figure 9-1 displays part of the Caching, Personalization, and Compression Rules page of OracleAS Web Cache Manager, which shows the default caching rules.
Table 9-4 describes the default caching rules. Rule 1 is intended for Oracle Application Server Wireless. If you are not using this Oracle Application Server component, you can delete the rule.
|
See Also:
Oracle Application Server Wireless Administrator's Guidefor further information about Oracle Application Server Wireless |
This section describes how to configure caching rules and associate the rules with multiple URLs. It contains the following topics:
To configure caching rules:
The Caching, Personalization, and Compression Rules page appears.
The Edit/Add Caching, Personalization, and Compression Rule dialog box appears.
.gif
.), it is not necessary to enter it.
http://host_name:port/ or "/", it is not necessary to enter this information.
The prefix is interpreted literally, including reserved regular expression characters. These characters include periods (.), question marks (?), asterisks (*), brackets ([]), curly braces ({}), carets (^), dollar signs ($), and backslashes (\).
The prefix is interpreted literally, including reserved regular expression characters. These characters include periods (.), question marks (?), asterisks (*), brackets ([]), curly braces ({}), carets (^), dollar signs ($), and backslashes (\).
^" to denote the start of the URL and "$" to denote the end of the URL.
See Also: "Selectors" for caching rule syntax
GET, GET with query string, or POST HTTP request methods.
You can select more than one request method.
POST body parameters and their values in the corresponding Name and optional Value fields. Then click Add.
For the Regular Expression expression type, you must alphabetically sort and enter the embedded URL parameters in the URL Expression field.
The request URL that browsers send to OracleAS Web Cache and the internal URL expression that OracleAS Web Cache uses for that request are different. When OracleAS Web Cache serves a page request, it alphabetically sorts any embedded URL parameters of the URL. However, the caching rules are matched against only the internal representation of the URL in which any embedded URL parameters are sorted. To ensure caching rules are matched correctly, you either use the URL and POST Body Parameters section or manually enter the embedded URL parameters alphabetically in regular expression syntax. When you use the URL and POST Body Parameters section, the embedded URL parameters are automatically sorted.
For example, consider the following URL:
http://my.oracle.com/servlet/page?_pageid=53&_dad=moc&_schema=MOC
If you enter the regular expression without manually sorting the embedded URL parameters in the URL Expression field, ^/servlet/page\?_pageid=53&_dad=moc&_schema=MOC$, then the caching rule will not match the internal representation of the URL used by OracleAS Web Cache. To ensure matching, you must enter the regular expression in the URL Expression field as:
^/servlet/page\?_dad=moc&_pageid=53&_schema=MOC$
POST body parameters in the URL and POST Body Parameters section, specify the HTTP POST body in the POST Body Expression field.
To apply this rule to any POST request body, enter ".*" in the field.
See Also:
Table 9-5 Options for Rules with a Cache Policy of Cache
| Option | Explanation |
|---|---|
|
Expiration Policy |
From the list, select an expiration policy to apply to the objects. If you do not see an expiration policy suitable for the documents, in the navigator frame, select Rules for Caching, Personalization, and Compression > Expiration Policy Definitions in to create a new policy. See Also:
|
|
Multiple Documents with the Same Selector by Cookies |
To cache multiple-version documents that rely on category cookie values, select the required cookies. If you do not see a cookie that can be applied to these objects, in the navigator frame, select Rules for Caching, Personalization, and Compression > Cookie Definitions to create a new cookie definition. See Also:
|
|
Multiple Documents with the Same Selector by Other Headers |
Select the HTTP request headers whose values OracleAS Web Cache will use to cache and identify multiple-version documents. You can select one or more of the following:
An example of a request made with a Netscape 4.6 browser with HTTP request headers follows: User-Agent: Mozilla/4.61 [en] (WinNT; U) Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, image/png,*/*s Accept-Encoding: gzip Accept-Language: en Accept-Charset: iso-8859-1,*,utf-8
Note: 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 See Also: "Multiple Versions of the Same Document" for an overview |
|
Session Caching Policies |
To cache or serve documents based on session or personalized attribute information contained within a cookie, embedded URL parameter, or See Also:
|
|
Session-Encoded URL |
Select No to not substitute session values used in session-encoded URLs or personalized attribute values enclosed within
Select Yes to substitute session or personalized attribute values. OracleAS Web Cache will replace the value information based on the value of the cookie, embedded URL parameter, or See Also:
|
|
HTTP Error Caching |
Enter the HTTP error codes you want OracleAS Web Cache to cache and serve for this rule. If you enter multiple codes, use a comma to separate them.
If there is a problem on the origin server that does not result in a OracleAS Web Cache caches the error pages according to the expiration policy of the rule. After the problem is resolved, invalidate the HTTP errors. |
In addition to, or as an alternative to, creating caching rules with OracleAS Web Cache Manager, application developers can choose to store the many of the caching attributes in the header of an HTTP response message. See "Configuring Expiration Policies" for details.
Tip:
After the caching rules are configured, prioritize them.
To assign priority to rules:
Higher priority rules are processed first.
You can associate a group of rules with the following cache policy features:
To associate multiple rules with a cache policy feature:
The Association page for the cache policy feature appears.
The Change Association dialog box for the cache policy feature appears.
If the caching rule you require does not exist, create a caching rule, as described in "Configuring Caching Rules and Rule Association".
This section contains the following topics about configuring cache policy features:
You can create policies that specify when to expire documents in the cache. In addition, you can specify how long documents can reside in the cache after they have expired. When a document expires, it is either immediately removed or removed based on when the origin servers can refresh them.
To create expiration policies:
The Expiration Policy Definitions page appears.
The Create Expiration Policy dialog box appears.
Expires response-header field. This is the default. To use this option, documents must use the HTTP Expires or Cache-Control response-header fields.
While the first two options enable you to set expiration for OracleAS Web Cache-specific rules, the third option recognizes the expiration policy established for the documents already programmed with an HTTP Expires or Cache-Control response-header field.
The Expiration Policy Association page appears.
The Change Expiration Association dialog box appears.
The caching rule moves to the left list and the dialog box closes.
If the caching rule you require does not exist, create a caching rule, as described in "Configuring Caching Rules and Rule Association". In Step 13 of the procedure, select an expiration rule in the Expiration Policy row of the Edit/Add Caching, Personalization, and Compression Rule dialog box.
|
See Also:
"Multiple Versions of the Same Document" for an overview and an example scenario |
You can specify which category cookies whose values OracleAS Web Cache will use to cache and identify multiple-version documents.
To specify cookie values for multiple-version URLs:
The Cookie Definitions page appears.
The Edit/Add Cookie Definition dialog box appears.
The Cookie Association page appears.
The Change Cookie Association dialog box appears.
The caching rule moves to the left list and the dialog box closes.
If the caching rule you require does not exist, create a caching rule, as described in "Configuring Caching Rules and Rule Association". In Step 13 of the procedure, select a cookie in the Multiple Documents with the Same Selector by Cookies field of the Edit/Add Caching, Personalization, and Compression Rule dialog box.
By default, OracleAS Web Cache does not interpret the values of the HTTP request headers. When the Multiple Documents with the Same Selector by Other Headers for the User-Agent request-header field is selected in OracleAS Web Cache Manager and the value of the User-Agent request header of the same URL differ, then OracleAS Web Cache caches both pages separately. For example, if one request sends an HTTP request header of User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 4.0) and another request sends an HTTP request header of User-Agent: Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt) for different versions of Internet Explorer, OracleAS Web Cache caches two separate pages.
You can override this default behavior by configuring OracleAS Web Cache with a User-Agent pattern string for a particular browser. For the affected multiple-version documents, OracleAS Web Cache adds an x-Oracle-Mapped-User request-header field, and uses the value of the string rather than the entire User-Agent value:
x-Oracle-Mapped-User: MAPPEDUSERAGENT_String
|
See Also:
"Multiple Versions of the Same Document" for an overview and an example scenario |
To configure OracleAS Web Cache to cache and serve the same page for each browser type:
User-Agent request header, as described in "Configuring Caching Rules and Rule Association". In Step 13 of the procedure, select User-Agent in the Multiple Documents with the Same Selector by Other Headers section of the Edit/Add Caching, Personalization, and Compression Rule dialog box.
webcache.xml file.
GLOBALCACHINGRULES element.
<USERAGENTREMAPRULE MATCHSTRING="browser" MAPPEDUSERAGENT="x-Oracle-Mapped-User-Agent_value" MAPTYPE="USERAGENT"/>
If you enter multiple entries, order them according to how you want OracleAS Web Cache to match. The order of these rules work in the same fashion as priority works for caching rules.
Table 9-6 describes how to enter values for the subelements.
The following webcache.xml fragment shows the User-Agent remapping:
<USERAGENTREMAPRULE MATCHSTRING="MSIE *" MAPPEDUSERAGENT="MSIE" MAPTYPE="USERAGENT"/> <USERAGENTREMAPRULE MATCHSTRING="Mozilla*" MAPPEDUSERAGENT="MOZ" MAPTYPE="USERAGENT"/>
If an incoming request does not match any of the rules, OracleAS Web Cache appends a default mapping to the request. The default value of the x-Oracle-Mapped-User-Agent header is "DEFAULT_USER_AGENT."
These mapping rules are executed for every incoming request. If you create several mapping rules, you may experience a performance degradation.
<MULTIVERSIONHEADERSRULE> subelement of CACHEABILITYRULE for the caching rule created in Step 1.
<MULTIVERSIONHEADERSRULE> <HTTPHEADER NAME="User-Agent"/> </MULTIVERSIONHEADERSRULE>
MAPPEDUSERAGENT string rather than the entire User-Agent value, change the "User-Agent" header to "x-Oracle-Mapped-User-Agent" in the HTTPHEADER attribute of the rule:
<MULTIVERSIONHEADERSRULE> <HTTPHEADER NAME="x-Oracle-Mapped-User-Agent"/> </MULTIVERSIONHEADERSRULE>
opmnctl restartproc ias-component=WebCache
You can specify how OracleAS Web Cache serves requests with the existence or nonexistence of session or personalized attribute cookies, embedded URL parameters, or POST parameters.
|
See Also:
|
To create caching policies for pages that support session cookies or personalized attributes:
The Session Caching Policy Association page appears.
The Add Session Caching Policy dialog box appears.
If the sessions or personalized attributes listed do not contain the definition you require, then click Cancel to exit the Add Session Caching Policy dialog box. Continue to Step 5.
The Session Definitions page appears.
The Edit/Add Session Definition dialog box appears.
POST parameter in the URL or POST body parameter field.
If you enter both a cookie name and parameter, keep in mind that both must be used to support the same session or personalized attribute. If they support different sessions or personalized attributes, create separate definitions. You can specify up to 20 definitions for each page.
See Also:
The Change Session Association dialog box appears.
The selector moves to the left list and the dialog box closes.
If the selector you require does not exist, create a caching rule for the pages the support session or personalized attributed cookie or embedded URL parameter, as described in "Configuring Caching Rules and Rule Association". In Step 13 of the procedure, select a policy in the Session Caching Policies row of the Edit/Add Caching, Personalization, and Compression Rule dialog box.
You can specify caching rules for personalized pages that use session-encoded URLs. Session-encoded URLs enable Web sites to keep track of user sessions through session information contained within <A HREF=...> HTML tags. 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.
|
See Also:
"Substituting Session Information in Session-Encoded URLs" for an overview and an example scenario |
To cache instructions for substituting session information in session-encoded URLs, take the following steps:
The Session Definitions page appears.
The Edit/Add Session Definition dialog box appears.
POST body parameter in the URL or POST body parameter field.
If you enter both a cookie name and parameter, keep in mind that both must support the same session substitution. If they support different substitutions, create separate session definitions. You can specify up to 20 definitions for each page.
OracleAS Web Cache uses the default string for those requests without the value for an embedded URL parameter. For these requests, OracleAS Web Cache substitutes the value with a default string. The string defaults to default. For example, the following <A HREF=...> contains a session_ID parameter without a value:
<A HREF="https://oraclestore.oracle.com/OA_ HTML/ibeCCtpSctDspRte.jsp?section=11886&session_ID=">Master Index</A>
If the string is set to default, OracleAS Web Cache substitutes the value with default.
<A HREF="https://oraclestore.oracle.com/OA_ HTML/ibeCCtpSctDspRte.jsp?section=11886&session_ID=">Master Index</A>
If you want to instead require that the request get the cookie or parameter settings from the origin server, perform Step 4.
In Step 13 of the procedure, select Yes in the Session-Encoded URL field of the Edit/Add Caching, Personalization, and Compression Rule dialog box to substitute session information in session-encoded URLs.
POST body parameter value from the origin server, perform these additional steps:
You can specify caching rules for personalized pages that use personalized attributes. Personalized attributes are often in the form of a personalized greeting like "Hello, Name." Personalized attributes can come in other forms, such as icons, addresses, or shopping cart snippets. You can configure OracleAS Web Cache to substitute personalized attributes within <!-- WEBCACHETAG--> and <!-- WEBCACHEEND--> tags with the values obtained from a cookie, embedded URL parameter, or POST parameter.
|
See Also:
"Personalized Attributes" for an overview and an example scenario |
To create rules for personalized pages:
The Session Definitions page appears.
The Edit/Add Session Definition dialog box appears.
For example, if the attribute is for a personalized greeting that uses the first name, you could enter first_name01.
POST body parameter in the URL or POST body parameter field.
If you enter both a cookie name and parameter, keep in mind that both must support the same personalized attribute substitution. If they support different substitutions, create separate personalized definitions. You can specify up to 20 definitions for each page.
POST body parameter.
OracleAS Web Cache uses the default string for those requests without the value for the personalized attribute for pages containing the <!-- WEBCACHETAG--> and <!-- WEBCACHEEND--> tags. For these requests, OracleAS Web Cache uses the value of the default string. The string defaults to default. For example:
<B><!-- WEBCACHETAG="first_name01"-->default<!-- WEBCACHEEND--></B>
If you want to instead require that the request get the cookie or parameter settings from the origin server, perform Step 4.
Surrogate-Control response-header field, as described in "Surrogate-Control Response-Header Field":
Surrogate-Control: content="webcache/1.0"
POST body parameter value from the origin server, perform these additional steps:
<!-- WEBCACHETAG--> and<!-- WEBCACHEEND--> as follows:
<!-- WEBCACHETAG="personalized_attribute"-->personalized attribute HTML segment<!-- WEBCACHEEND-->
Ensure that both tags have a space after <!--.
|
Important:
The |
The <!-- WEBCACHETAG--> and<!-- WEBCACHEEND--> tags can appear anywhere the <!-- ...--> comment tags are permitted in HTML. For example, you can use the <!-- WEBCACHETAG--> and<!-- WEBCACHEEND--> tags between other HTML tag pairs, but you cannot use them within an HTML tag.
In the following example, the placement of <!-- WEBCACHETAG="p_name"--> within the <input> tag is an invalid use of the <!-- WEBCACHETAG-->:
htp.p('<FORM ACTION="test" METHOD="GET">'); htp.p('<TABLE BORDER="0" > <TR> <TD><INPUT TYPE="text" NAME="p_name" SIZE="8" VALUE="<!-- WEBCACHETAG="p_name"-->'||p_name||'<!-- WEBCACHEEND-->"></td> </TR> <TR> <TD><input type="submit" value="Search"></TD> </TR> </TABLE>');
To achieve personalization within an HTML tag, use ESI.
To understand how to cache personalized content, consider the HTML page monthly.htm in Figure 9-2.
October is personalized content that can be substituted with other values.
The page has a URL of monthly.htm?Month=month, where Month is an embedded URL parameter.
To cache monthly.htm and its personalized content, take the following steps:
TestMonth to the embedded URL parameter Month in the Edit/Add Session Definition dialog box, as shown in the following figure:
Month, as shown in the following figure:
"Configuring Session or Personalized Attribute Caching Policies" for more information about creating personalized attribute caching rules
See Also:
<!-- WEBCACHETAG--> and <!-- WEBCACHEEND--> HTML tags to monthly.htm.
Current Month is: <!-- WEBCACHETAG="TestMonth"-->October<!-- WEBCACHEEND-->
monthly.htm in the Edit/Add Caching, Personalization, and Compression Rule dialog box:
To verify that OracleAS Web Cache is caching monthly.htm:
monthly.htm at the URL monthly.htm?Month=October. Because the initial request was forwarded by OracleAS Web Cache to the application Web server, the value October is set for the Month parameter. This initial request is inserted monthly.htm into the cache.
monthly.htm to the URL monthly.htm?Month=January.
OracleAS Web Cache substitutes October with the value of January, as shown in Figure 9-3.
You can configure OracleAS Web Cache to ignore the value of embedded URL or POST body parameters so that one version of a page can be served to multiple users.
|
See Also:
"Excluding the Value of Embedded URL or POST Body Parameters" for an overview and an example scenario |
To ignore the value of URL parameters:
The Session Definitions page appears.
The Edit/Add Session Definition dialog box appears.
POST body parameter in the URL or POST body parameter field.
OracleAS Web Cache does not use the default string for this feature.
If you want to require that the request obtain the parameter settings from the origin server, perform Step 5.
Some Web sites require users to have sessions while surfing most pages. If you want to preserve the session requirement, create a Session/Personalized Attribute Related Caching Rule for those pages. This way, a request without a session will always be served by the origin server.
For some popular site entry pages, such as "/", that typically require session establishment, session establishment effectively makes the page non-cacheable to all new users without a session. To cache these pages while preserving session establishment, make the following minor modifications to your application:
/", that redirects to the real entry page.
In Step 13 of the procedure, select a session caching policy with a value of Cache with session and Cache without session in the Session Caching Policies row of the Edit/Add Caching, Personalization, and Compression Rule dialog box.
With this configuration, all initial user requests to the entry URL first go to the blank page, which requires minimal resources to generate. The browsers receive the response and session establishment from the application Web server. Subsequent redirected requests to the entry page carry the session, enabling the entry page to be served out of the cache.
Another solution to this issue is to use a JavaScript that sets a session cookie for the pages requiring sessions:
In addition to, or as an alternative to, creating caching rules with OracleAS Web Cache Manager, application developers can choose to store many of the caching attributes in the header of an HTTP response message. This feature enables the application Web server to override the settings configured through the OracleAS Web Cache Manager interface, as well as allowing other third-party caches to use OracleAS Web Cache caching attributes. All except the following attributes described in "Configuring Caching Rules and Rule Association" are supported:
To enable this feature, configure the HTTP response with the Surrogate-Control response-header field as follows:
Surrogate-Control:control_directive,control_directive,...
|
See Also:
|
|
See Also:
"Content Assembly and Partial Page Caching" for an overview of partial page caching |
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:
To enable partial page caching:
ESI tags cannot be used on a page that contains
Important:
<!-- WEBCACHETAG--> and<!-- WEBCACHEEND--> tags. If you require simple personalization and are using ESI, see "Using ESI for Simple Personalization".
Surrogate-Control response-header field. For example:
Surrogate-Control: max-age=30+60, content="ORAESI/9.0.4"
Surrogate-Control response-header field does not include all the caching attributes required for the template page, create a caching rule for the page.
Surrogate-Control response-header field in the HTTP response message.
Surrogate-Control response-header field does not include all the caching attributes required for the fragment, create a caching rule for the fragment.
See Also:
Surrogate-Control response-header field
You can use variable expressions to achieve the same substitution as personalized attributes and session-encoded URLs. Oracle Corporation recommends using ESI for simple personalization when you are utilizing other ESI features, otherwise continue to use the methods described in "Configuring Rules for Popular Pages with Session Establishment".
For example, the following HTML excerpt uses the <!-- WEBCACHETAG--> and<!-- WEBCACHEEND--> tags to substitute a user's name based on the value the browser passes with UserName cookie. In addition, the session information contained within the sessionID cookie is used to replace session information for one user with another user.
Welcome <!-- WEBCACHETAG="UserName"-->John<!-- WEBCACHEEND -->! Here is a <A HREF="/jsp/myPage.jsp?sessionID=13001">link</A>.
The same effect is achieved with the following ESI markup:
<esi:vars> Welcome $(HTTP_COOKIE{'username'})! Here is a <A HREF="/jsp/myPage.jsp?sessionID=$(QUERY_ STRING{'sessionid'})">link</A>. </esi:vars>
The <esi:vars> tag enables you to use an ESI environment variable outside of an ESI tag. Variables can also be used with other ESI tags.
This section provides examples of ESI usage in the following topics:
Figure 9-4 shows a portal site response page, http://www.company.com/servlet/oportal?username=Mark, for a registered user named Mark.
This page is assembled by OracleAS Web Cache. A template page configured with ESI markup tags for a personalized greeting, weather, stocks, promotional advertisement, news, and sports fragments is assembled based on Mark's preferences. For example, because Mark chose San Francisco weather, the application looks up San Francisco weather information and puts it into the final full HTML page output. Because of its dynamic content, this page would not be cacheable. On the other hand, with ESI markup tags, OracleAS Web Cache assembles and caches most of the content.
The following sections describe how the template page and its fragments are implemented using <esi:inline> and <esi:include> tags:
This section describes how <esi:inline> tag fragmentation and assembly can drastically increase the value of dynamic content caching for pages that do not contain real-time elements. It shows how to apply the <esi:inline> tag for an existing application that supports non-fetchable fragments. The <esi:inline> tag helps reduce space consumption and improves cache hit ratios by isolating the dynamic content.
|
Note:
If an application supports independently fetchable fragments, it is possible to use the |
To utilize the <esi:inline> tag, the logical fragments in portal.esi are marked with the <esi:inline> tags. The personalized greeting, Weather Forecast, My Stocks, Promotion campaign, Latest News, and Latest Sports News naturally become fragments because they have individual caching properties and can be shared. The My Stock fragment is further broken down into five sub-fragments, one for each stock quote. In addition, to achieve the maximum fragment sharing, the common HTML code sections between each two personalized fragments are also enclosed as ESI fragments and are given constant names, so that the varying template contains as little common data as possible.
Example 9-1 shows portal.esi with <esi:inline> tags.
<esi:inline name="/Common_Fragment_1" > <!-- First common fragment --> <HTML> ... <!-- Personalized Greeting With ESI variable --> Welcome, $(QUERY_STRING{username})! </esi:inline> <esi:inline name="/Weathers_San_Francisco" > ...<!-- Personalized Weather Forecast -->Weather Forecast for San Francisco<TABLE><TR><TD>Currently: 50F</TD></TR></TABLE></esi:inline><esi:inline name="/Common_Fragment_2" ><!-- Second common fragment -->...</esi:inline><esi:inline name="/Stocks_$(QUERY_STRING{username})" ><!-- Personalized Stock Quote Selections --> <TABLE> <TR> <TD> <esi:inline name="/ticker_IBM"> IBM 108.53 10/25/2001 1:33PM -0.04 </esi:inline> <BR> <esi:inline name="/ticker_ORCL"> ORCL 13.379 10/25/2001 1:38PM -1.281 </esi:inline> <BR> <esi:inline name="/ticker_YHOO"> YHOO 11.41 10/25/2001 1:37PM -0.54 </esi:inline> <BR> <esi:inline name="/ticker_SUNW"> SUNW 9.20 10/25/2001 1:38PM +0.01 </esi:inline> <BR> <esi:inline name="/ticker_PRSF"> PRSF 1.98 10/25/2001 1:37PM +0.08 </esi:inline> <TD> </TR> </TABLE> </esi:inline> <esi:inline name="/Common_Fragment_3"> <!-- Third common fragment -->...</esi:inline> <esi:inline name="/ExternalAdvertisement"> <!-- External Advertisement --> <TABLE> <TR> <TD> <a href="http://www.companyad.com/advert?promotionID=126532"> <img src="http://www.companyad.com/advert_img?promotionID=126532"> </a> </TD> </TR> </TABLE> </esi:inline> <esi:inline name="/Common_Fragment_4"> <!-- Fourth common fragment --> ... </esi:inline> <esi:inline name="/Top_News_Finance"> <!-- Personalized Top News --> Latest News for finance <TABLE> <TR> Crash Inflicts Heavy Blow on Prospects of American MO Stocks End Mixed as Fears of Terrorism Abates New York Times Blue-Chip Stocks Cut Losses; Nasdaq Up MO Stocks Fall at Opening After Plane Crash New York Times French rig factory with explosives New York Times </TR> </TABLE> </esi:inline> <esi:inline name="/Sports_News_Soccer" > <!-- Personalized Sports News --> Latest Sports News for Soccer <TABLE> <TR> Blues may ditch Bruce MO Quartet in international action Footy Mad Youth Cup game on a Sunday Footy Mad Wimbledon fans to hold Fans United Day Footy Mad Unibond Premier Review Nov11th Fooy Mad </TR> </TABLE> </esi:inline> <esi:inline name="/Common_Fragment_5" > ... </esi:inline>
Example 9-2 shows the markup for the personalized greeting. The fragment is common to all personalized pages belonging to different users. Because the <esi:inline> tag assigns this fragment a constant name, a different user, such as John, would have the same fragment in his template with the same fragment name. Two fragments are shared if and only if their names are identical. This way, the same shared fragment in all templates only need a single update when it expires or is invalidated. $(QUERY_STRING{username}) is an ESI environment variable that provide access to value of the username. This variable is used here because this application uses the username query string parameter to pass along the user's name. By using this variable, the first fragment becomes common to all users.
<esi:inline name="/Common_Fragment_1" > <!-- First common fragment --> <HTML> ... <!-- Personalized Greeting With ESI variable --> Welcome, $(QUERY_STRING{username})! </esi:inline>
Example 9-3 shows the markup for Weather Forecast. The fragment is unique to each city. Every template selecting the same city would share this fragment with Mark's page due to the fragment naming.
<esi:inline name="/Weathers_San_Francisco" ><!-- Personalized Weather Forecast -->Weather Forecast for San Francisco<TABLE><TR><TD>Currently: 63F</TD></TR></TABLE></esi:inline>
Example 9-4 shows the markup for My Stocks. The stock quotes fragment encloses all stock picks in Mark's page. It is further divided into five sub-fragments, one for each stock pick, using nested <esi:inline> tags. Thus, Mark's ESI template references his stock selection fragment, which in turn references five particular stock pick fragments. While the stock picks are shared by many user's stock selection fragment, the stock selection fragment itself is also a template uniquely owned by Mark. This separates the unique information from shared information, maximizing the reduction of cache updates and space consumption of personal stock selection.
<esi:inline name="/Stocks_$(QUERY_STRING{username})" >
<!-- Personalized Stock Quote Selections -->
<TABLE>
<TR>
<TD>
<esi:inline name="/ticker_IBM">
IBM 108.53 10/25/2001 1:33PM -0.04
</esi:inline>
<BR>
<esi:inline name="/ticker_ORCL">
ORCL 13.379 10/25/2001 1:38PM -1.281
</esi:inline>
<BR>
<esi:inline name="/ticker_YHOO">
YHOO 11.41 10/25/2001 1:37PM -0.54
</esi:inline>
<BR>
<esi:inline name="/ticker_SUNW">
SUNW 9.20 10/25/2001 1:38PM +0.01
</esi:inline>
<BR>
<esi:inline name="/ticker_PRSF">
PRSF 1.98 10/25/2001 1:37PM +0.08
</esi:inline>
<TD>
</TR>
</TABLE>
</esi:inline>
Example 9-5 shows the markup for referencing an advertisement in the Promotion section. promotionID is the based on the user's identification.
<esi:inline name="/ExternalAdvertisement"> <!-- External Advertisement --> <TABLE> <TR> <TD> <a href="http://www.companyad.com/advert?promotionID=126532"> <img src="http://www.companyad.com/advert_img?promotionID=126532"> </a> </TD> </TR> </TABLE> </esi:inline>
Rotating advertisements that change in every response is an example of real- time content that renders little value in non-fetchable ESI <esi:inline> caching. Even the smallest portion of real-time content embedded as a non-fetchable ESI inline fragment would require the entire response to be regenerated and fetched, effectively creating cache misses all the time. To utilize ESI and dynamic content caching for these real-time fragments, use the <esi:include> tag.
|
See Also:
"Portal Example Using Include Tags" for an example of using |
The Latest News and Latest Sports News fragments are similar to the weather fragment. All the common areas are also defined as fragments. Although it is possible to leave them as part of the template, that would consume unnecessary storage space. Example 9-6 shows the markup.
<esi:inline name="/Top_News_Finance"> <!-- Personalized Top News --> Latest News for finance <TABLE> <TR> Blue-Chip Stocks Cut Losses; Nasdaq Up MO Stocks Fall at Opening After Plane Crash New York Times French rig factory with explosives New York Times Volkswagen faces Brazil strike CNN Europe Airbuss reliability record BBC </TR> </TABLE> </esi:inline> <esi:inline name="/Sports_News_Soccer" > <!-- Personalized Sports News --> Latest Sports News for Soccer <TABLE> <TR> Hearts chief told to resign MO Owen and Gerrard fit for Blackburn game Ananova Hearts in positive AGM pledge Ananova Time for McIntosh to decide scotsman.com </TR> </TABLE> </esi:inline>
This section shows how the <esi:include> tag can be used for fragmentation and assembly of fetchable fragments whose content are not embedded in the template.
Example 9-7 shows portal.esi with <esi:include> tags.
<HTML>
...
<!-- Personal Profile -->
<esi:comment text="Profile refers to environment variables stored in
/servlet/GetProfile. GetProfile servlet enables access to a set of environment
variables with personal profile information."/>
<esi:environment src="/servlet/GetProfile?username=$(QUERY_STRING{username})"
name="Profile"/>
...
<!-- Personalized Greeting With ESI variable -->
<esi:vars>Welcome, $(QUERY_STRING{username})!</esi:vars>
...
<!-- Personalized Weather Forecast -->
<TABLE>
<TR>
<TD>
<esi:include
src="/servlet/Weather?city=$(Profile{city})&state=$(Profile{state})"/>
</TD>
</TR>
</TABLE>
...
<!-- Personalized Stock Quote Selections -->
<TABLE>
<TR>
<TD>
<esi:include src="/servlet/PersonalizedStockSelection?username=$(QUERY_
STRING{username})"/>
</TD>
</TR>
</TABLE>
...
<!-- External Advertisement -->
<TABLE>
<TR>
<TD>
<esi:try>
<esi:attempt>
<esi:comment text="Include an ad"/>
<esi:include src="/servlet/Advert"/>
</esi:attempt>
<esi:except>
<esi:comment text="Just write an HTML link instead"/>
<A HREF="http://www.oracle.com">http://www.oracle.com</a>
</esi:except>
</esi:try>
</TD>
</TR>
</TABLE>
...
<!-- Personalized Top News -->
Latest News for <esi:vars>$(Profile{news})</esi:vars>
<TABLE>
<TR>
<TD>
<esi:choose>
<esi:when test="$(Profile{news}) == `internet'">
<esi:include src="/servlet/News?type=Top&topic=internet"/>
</esi:when>
<esi:when test="$(Profile{news}) == `finance'">
<esi:include src="/servlet/News?type=Top&topic=business"/>
</esi:when>
<esi:otherwise>
<esi:include src="/servlet/News?type=Top&topic=technology"/>
</esi:otherwise>
</esi:choose>
</TD>
</TR>
</TABLE>
...
<!-- Personalized Sports News -->
Latest Sports News for <esi:vars>$(Profile{sport})</esi:vars>
<TABLE>
<TR>
<TD>
<esi:choose>
<esi:when test="$(Profile{sport}) == `golf'">
<esi:include src="/servlet/News?type=Sports&topic=golf"/>
</esi:when>
<esi:when test="$(Profile{sport}) == `soccer'">
<esi:include src="/servlet/News?type=Sports&topic=soccer"/>
</esi:when>
<esi:when test="$(Profile{sport}) == `basketball'">
<esi:include src="/servlet/News?type=Sports&topic=basketball"/>
</esi:when>
<esi:when test="$(Profile{sport}) == `baseball'">
<esi:include src="/servlet/News?type=Sports&topic=baseball"/>
</esi:when>
<esi:otherwise>
<esi:include src="/servlet/News?type=Sports&topic=soccer"/>
</esi:otherwise>
</esi:choose>
</TD>
</TR>
</TABLE>
Example 9-8 specifies Profile to refer to the environment variables stored in GetProfile. GetProfile enables access to user profile variables, which are used as parameters in the included fragments:
<!-- Personal Profile --> <esi:comment text="Profile refers to environment variables stored in /servlet/GetProfile. GetProfile servlet enables access to a set of environment variables with personal profile information."/> <esi:environment src="/servlet/GetProfile?username=$(QUERY_STRING{username})" name="Profile"/>
Example 9-9 shows GetProfile, which provides access to the city, state, news, and sports environment variables.
<?xml version="1.0"?> <esi-environment esiversion="ORAESI/9.0.4"> <city>San_Francisco</city> <state>CA</state> <news>finance</news> <sports>soccer</sports> </esi-environment>
Example 9-10 shows the markup for the personalized greeting Welcome, Mark!. The personalized greeting is achieved by the <esi:vars> tag, which bases the greeting on the username parameter embedded in the URL. The parameter username is the registered user's name. This markup enables the personalized greeting to be included in the cacheable template page.
<esi:vars>Welcome, $(QUERY_STRING{username})!</esi:vars>
Example 9-11 shows the markup for Weather Forecast. Weather Forecast includes a servlet fragment name Weather, which uses the value of the user's city and state environment variables in GetProfile to display the correct weather forecast for the user. Because GetProfile has a value of San Francisco for the city environment variable and California for the state environment variable, the weather forecast is for San Francisco, California.
<TABLE> <TR> <TD> <esi:include src="/servlet/Weather?city=$(Profile{city})&state=$(Profile{state})"/> </TD> </TR> </TABLE>
The markup for My Stocks is depicted in Example 9-12. My Stocks includes a servlet fragment named PersonalizedStockSelection. The displayed stocks are based on the userID parameter encoded in the URL. userID is the registered user's unique ID.
<TABLE> <TR> <TD> <esi:include src="/servlet/PersonalizedStockSelection?username=$(QUERY_ STRING{username})"/> </TD> </TR> </TABLE>
The markup for the included fragment PersonalizedStockSelection is depicted in Example 9-13. It includes fragments for five stock quotes: IBM, ORCL, YHOO, SUNW, and PRSF.
<TABLE> <TR> <TD> <BR> <esi:include src="Quote?symbol=IBM"/> <BR> <esi:include src="Quote?symbol=ORCL"/> <BR> <esi:include src="Quote?symbol=YHOO"/> <BR> <esi:include src="Quote?symbol=SUNW"/> <BR> <esi:include src="Quote?symbol=PRSF"/> <BR> </TD> </TR> </TABLE>
Because the output is different for each user, the PersonalizedStockSelection fragment is not cacheable. However, the response to each of the included quotes is cacheable, enabling stock quotes to be shared by multiple users. Even when many users share quotes, only one browser reload is needed when the quotes are updated. For example, the PersonalizedStockSelection fragment for another user named Scott is depicted in Example 9-14. It includes fragments for three stock quotes: IBM, ORCL, and SCO. As already described, IBM and ORCL are also shared by Mark. If Mark reloads the page first and caches the quotes, then the IBM and ORCL quotes for Scott are automatically refreshed.
<TABLE> <TR> <TD> <BR> <esi:include src="Quote?symbol=IBM"/> <BR> <esi:include src="Quote?symbol=ORCL"/> <BR> <esi:include src="Quote?symbol=SCO"/> <BR> </TD> </TR> </TABLE>
Example 9-15 shows the markup for rotating advertisements in the Promotion section. The advertisements rotates in the sense that the advertisement changes for each response. By separating the generation of the included image fragment response from the template page, OracleAS Web Cache is able to cache the template and integrate the dynamic advertisement into the template.
<TABLE> <TR> <TD> <esi:try> <esi:attempt> <esi:comment text="Include an ad"/> <esi:include src="/servlet/Advert"/> </esi:attempt> <esi:except> <esi:comment text="Just write an HTML link instead"/> <A HREF="www.oracle.com">www.oracle.com</a> </esi:except> </esi:try> </TD> </TR> </TABLE>
As shown in Example 9-16, the response to the included image fragment for the banner is not cacheable. When a user requests this page, OracleAS Web Cache sends the request to the application Web server to generate the banner. From the application Web server, Advert generates the banner for the request.
<TABLE> <TR> <TD> <A HREF="http://www.companyad.com/redirect?refID=11934502"> <IMG src="http://www.companyad.com/advert_img?refID=11934502"></A> </TD> </TR> </TABLE>
As shown in Example 9-17, the next time the user reloads the page, Advert generates another banner for the request.
<TABLE> <TR> <TD> <A HREF="http://www.companyad.com/redirect?refID=123456602"> <IMG src="http://www.companyad.com/advert_img?refID=123456602"></A> </TD> </TR> </TABLE>
The banner relies on alternate processing with the <esi:try> tag. If the servlet cannot run Advert, a link to www.oracle.com appears in the banner's place.
Example 9-18 shows the markup for Latest News and Latest Sports News:
news category, internet, finance, or technology, by using conditional processing with the <esi:choose> tag. Because GetProfile has a value of finance for the news environment variable, the headlines displayed relate to finance, /servlet/News?type=Top&topic=business.
sports category, golf, soccer, basketball, baseball, or soccer, by using conditional processing. Because GetProfile has a value of soccer for the sports environment variable, the output includes headlines relating to soccer, /servlet/News?type=Sports&topic=soccer.
Latest News for <esi:vars>$(Profile{news})</esi:vars> <TABLE> <TR> <TD> <esi:choose> <esi:when test="$(Profile{news}) == `internet'"> <esi:include src="/servlet/News?type=Top&topic=internet"/> </esi:when> <esi:when test="$(Profile{news}) == `finance'"> <esi:include src="/servlet/News?type=Top&topic=business"/> </esi:when> <esi:otherwise> <esi:include src="/servlet/News?type=Top&topic=technology"/> </esi:otherwise> </esi:choose> </TD> </TR> </TABLE> ... <!-- Personalized Sports News --> Latest Sports News for <esi:vars>$(Profile{sport})</esi:vars> <TABLE> <TR> <TD> <esi:choose> <esi:when test="$(Profile{sport}) == `golf'"> <esi:include src="/servlet/News?type=Sports&topic=golf"/> </esi:when> <esi:when test="$(Profile{sport}) == `soccer'"> <esi:include src="/servlet/News?type=Sports&topic=soccer"/> </esi:when> <esi:when test="$(Profile{sport}) == `basketball'"> <esi:include src="/servlet/News?type=Sports&topic=basketball"/> </esi:when> <esi:when test="$(Profile{sport}) == `baseball'"> <esi:include src="/servlet/News?type=Sports&topic=baseball"/> </esi:when> <esi:otherwise> <esi:include src="/servlet/News?type=Sports&topic=soccer"/> </esi:otherwise> </esi:choose> </TD> </TR> </TABLE>
As described in Step 6 of "Configuring Rules for Popular Pages with Session Establishment", the <!-- WEBCACHETAG--> and <!-- WEBCACHEEND--> tags can be used between other HTML tag pairs, but not within an HTML tag. However, ESI variables can be used within an HTML tag.
For example, consider Example 9-19. Its HTML code uses PL/SQL for an HTML form with a text box in it.
htp.p('<form action="test" method="GET">'); htp.p('<table border="0" > <tr> <td><input type="text" name="p_name" size="8" value="'||p_name||'"></td> </tr> <tr> <td><input type="submit" value="Search"></td> </tr> </table>');
Example 9-20 shows how the $HTTP_COOKIE variable is used with the <esi:vars> tag to replace the value of p_name with the user's name.
htp.p('<form action="test" method="GET">'); htp.p('<table border="0" ><tr><esi:vars> <td><input type="text" name="p_name" size="8" value="$(HTTP_COOKIE{'p_name'}"></td> </tr></esi:vars> <tr> <td><input type="submit" value="Search"></td> </tr> </table>');
|
 Copyright © 2002, 2003 Oracle Corporation. All Rights Reserved. |
|