Release 2.0.0
Part Number A90372-04
 Library |
 Services |
 Contents |
 Index |
| Oracle9iAS Web Cache Administration and Deployment Guide Release 2.0.0 Part Number A90372-04 |
|
This chapter explains how to configure cacheability rules.
This chapter contains these topics:
Using Oracle Web Cache to specify cacheability rules, you can select to cache or not to cache content for static documents, multiple-version documents, personalized pages, pages that support session tracking, and HTTP error messages.
This section discusses the following topics:
Generally, when you assign cacheability rules, you specify the regular expression matching the URL and whether you want the documents contained within the URL cached or not cached. You then order the cacheability rules in order of priority. Higher priority rules are matched first.
For cacheable regular expressions that contain a document or a subset of documents that are not cacheable, 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 in the following order:
^/cec/cstage\?ecaction=ecpassthru2, GET and GET with query string, Don't Cache
^/cec/cstage\?ecaction=ecpassthru.*, GET and GET with query string, Cache
Note that GET and GET with query string are the HTTP request methods used by the documents.
If the order were reversed, all documents starting with /cec/cstage?ecaction=ecpassthru would be cached, including /cec/cstage?ecaction=ecpassthru2.
Examples of content that administrators would typically declare non-cacheable include updating transactions, shopping cart views, personal account views, and so on. One of the easiest ways to set up cacheability rules in Oracle 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.
In addition to the URL, you can specify optional selectors for more fine-grained cacheability rules. These additional selectors include the HTTP request method (GET, GET with query string, or POST) and, if POST is selected, the HTTP POST body of the documents. In the following rule list, 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.
^/cec/cstage\?ecaction=ecpassthru2, GET and GET with query string, Don't Cache
^/cec/cstage\?ecaction=ecpassthru.*, GET and GET with query string, Cache
^/cec/cstage\?ecaction=ecpassthru.*, POST, action=search, Cache
Note that cacheability rules use regular expression syntax, which is 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 6-1 shows examples of content to cache and how to enter regular expression syntax for corresponding cacheability rules for that content.
Table 6-1 Regular Expression Examples
Figure 6-1 displays the default cacheability rules established when Oracle Web Cache is installed.
Table 6-2 describes the default cacheability rules.
Table 6-2 Default Cacheability Rules
To configure cacheability rules:
The Cacheability Rules page appears in the right pane.
The Create Cacheability Rule or Edit/Create Cacheability Rule dialog box appears.
Remember to use "^" to denote the start of the URL and "$" to denote the end of the URL.
GET, GET with query string, or POST HTTP request methods.
You select more than one request method.
POST body of the documents in the POST Body Expression field.
To apply this rule to any POST request body, enter ".*" in the field.
|
Compression |
Select No to not serve compressed cacheable and non-cacheable documents for browsers. Select Yes to serve compressed cacheable and non-cacheable documents for browsers, and then select one of the following options:
Important: Netscape browsers are unable to uncompress included files, which may result in Netscape failures. If a document will be included in other files, such as a JavaScript file, then select Compress for non-Netscape browsers only. Notes:
|
|
Expiration Rule |
From the list, select an expiration rule to apply to the documents. If you do not see an expiration rule suitable for the documents, then choose Create A New Rule to create a new rule. See Also: Step 4 in "Configuring Expiration Rules" |
|
Multiple Documents with the Same Selector by Cookies |
Select None to not have Oracle Web Cache cache multiple-version documents that use cookies. Select Apply the following to cache multiple-version documents that rely on category cookie values, and then select the required cookie rules. If you do not see a cookie rule that can be applied to these documents, then choose Create A New Rule to create a new policy or modify an existing policy. See Also: Step 4 in "Configuring Rules for Multiple-Version Documents Containing Cookies" |
|
Multiple Documents with the Same Selector by Other Headers |
Select the HTTP request headers whose values Oracle Web Cache will use to cache and identify multiple-version documents.
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,*/* Accept-Encoding: gzip Accept-Language: en Accept-Charset: iso-8859-1,*,utf-8
Note: Oracle Web Cache does not interpret the values of these HTTP request headers. If the values for two pages are different, Oracle Web Cache caches both pages separately. For example, if one request sends an HTTP request header of |
|
Session/Personalized Attribute Related Caching Rules |
Select None to not have Oracle Web Cache cache documents that use session information contained within a session cookie or embedded in a URL as a parameter. Select Apply the following to cache documents with session information, and then select the required session rules. If you do not see the session these documents require, then choose Create A New Rule to create a new rule. See Also: "Configuring Rules for Pages with Session Tracking" for further information about creating session-related caching rules |
|
Simple Personalization |
Select No to cache documents with personalized attributes or session-encoded URLs. Select Yes to cache documents with personalized content, and then select one of the following options:
Important: To use the personalized attribute feature, enclose the personalized attribute information with the See Also: "Configuring Rules for Pages with Simple Personalization" for further information about creating rules for personalized pages |
|
HTTP Error Caching |
Enter the HTTP error codes you want Oracle Web Cache to cache. If you enter multiple codes, use a comma to separate them. If there is a problem on the application Web servers that will remain unresolved, then cache the error until the problem is resolved. Once the problem is resolved, you should invalidate the cached HTTP errors. See Also: "Invalidating Documents in the Cache" |
Once the cacheability rules are configured, prioritize them.
To assign priority to rules:
Higher priority rules are processed first.
Figure 6-2 illustrates how an administrator might set up cacheability rules for a catalog built on Oracle iStore 3i technology, which enables e-merchants to design, build, and publish their stores on the World Wide Web. Note that rules for Oracle iStore 11i will differ.
The rules are described in Table 6-3.
Table 6-3 Regular Expression Examples
You can create rules for when to expire documents in the cache. In addition, you can specify how long documents can reside in the cache once they have expired. When a document expires, it is either immediately invalidated or invalidated based on when the application Web servers can refresh them.
To create expiration rules:
The Expiration Rules page appears in the right pane.
The Create Expiration Rule dialog box appears.
While the first two options enable you to set expiration for Oracle Web Cache-specific rules, the third option recognizes the expiration policy established for the documents already programmed with an HTTP Expires header.
The Change Policy-Selector Association dialog box appears.
The selector moves to the left list and the dialog box closes.
If the selector you require does not exist, then create a cacheability rule, as described in "Configuring Cacheability Rules". In Step 10 of the procedure, select an expiration rule in the Expiration Rule row of the Edit/Create Cacheability Rule dialog box.
You can specify which category cookies whose values Oracle Web Cache will use to cache and identify multiple-version documents.
To specify cookie values for multiple-version URLs:
The Multiple Documents with the Same Selector by Cookies page appears in the right pane.
The Edit/Create Multiple Documents with the Same Selector by Cookies Rule dialog box appears.
The Change Policy-Selector Association dialog box appears.
The selector moves to the left list and the dialog box closes.
If the selector you require does not exist, then create a cacheability rule, as described in "Configuring Cacheability Rules". In Step 10 of the procedure, select Apply the following and a rule in the Multiple Documents with the Same Selector by Cookies row of the Edit/Create Cacheability Rule dialog box.
You can specify which HTTP request headers whose values Oracle Web Cache will use to cache and identify multiple-version URLs. If a browser request passes a URL with one of the headers defined, then Oracle Web Cache serves the document from its cache.
To specify HTTP request headers for multiple-version documents, select one of the headers in the Multiple Documents with the Same Selector by Other Headers column of the Edit/Create Cacheability Rule dialog box.
You can specify cacheability rules for personalized pages that use personalized attributes or session-encoded URLs.
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 Oracle Web Cache to cache the instructions for substituting values for personalized attributes based on the information contained within a cookie or the embedded URL parameter.
Session-encoded URLs enable Web sites to keep track of user sessions through session information contained within <A HREF=...> HTML tags. Oracle Web Cache can cache the instructions for replacing session information for one user with another based on the personal information contained within a cookie or as an embedded URL parameter.
|
See Also:
|
To create rules for personalized pages:
The Session/Personalized Attribute Definitions page appears in the right pane.
The Create Session/Personalized Attribute Definition dialog box appears.
For example, if the attribute is for a personalized greeting that uses the first name, you could enter first_name01 for the session name.
If you enter both a cookie name and an embedded URL parameter, keep in mind that both must support the same personalized attribute or session substitution. If they support different substitutions, create separate personalized definitions. You can specify up to 20 definitions for each page.
default.
If you want to instead require that the request get the cookie or embedded URL parameter settings from the application Web server, perform these steps:
1. Create a session-related caching rule for the page to track the session, as described in "Configuring Rules for Pages with Session Tracking".
2. In Step 6 of the procedure, select YES as the response.
3. In Step 7 of the procedure, select NO as the response.
Note:
<!-- WEBCACHETAG--> and<!-- WEBCACHEEND--> as follows:
<!-- WEBCACHETAG="personalized_attribute"-->
personalized attribute HTML segment
<!-- WEBCACHEEND-->
Ensure that both tags have a space after <!--.
|
Important:
The |
|
Note:
The
In the following example, the placement of 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. See Also: "Example of Simple Personalization with Variable Expressions" |
In Step 10 of the procedure, select Yes in the Simple Personalization row of the Edit/Create Cacheability Rule dialog box, and then select one of the following options:
To understand how to cache personalized content, consider the HTML page monthly.htm in Figure 6-3.
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.
The following steps were performed to cache monthly.htm and its personalized content.
TestMonth was mapped to the embedded URL parameter Month in the Edit/Create Session/Personalized Attribute Definition dialog box.
Month in the Add Session/Personalized Attribute Related Caching Rule dialog box.
|
See Also:
"Configuring Rules for Pages with Session Tracking" for more information about creating personalized attribute caching rules |
<!-- WEBCACHETAG--> and <!-- WEBCACHEEND--> HTML tags were added to monthly.htm.
Current Month is: <!-- WEBCACHETAG="TestMonth"-->October<!-- WEBCACHEEND-->
monthly.htm in the Create Cacheability Rules dialog box
Month was chosen.
To verify that Oracle Web Cache was caching monthly.htm:
monthly.htm at URL monthly.htm?Month=October was requested. Because the initial request was forwarded by Oracle Web Cache to the application Web server, the value October was required for the Month parameter. This initial request inserted monthly.htm into the cache.
monthly.htm was sent to URL monthly.htm?Month=January.
Oracle Web Cache substituted October with the value of January.
You can configure cacheability rules for pages that use session ID information, enabling Oracle Web Cache to serve the same page for multiple user sessions.
Here's how caching of session tracking pages works: When a user first accesses a Web site that uses session IDs, the application Web server assigns a unique session ID to the user. Session IDs are contained within a cookie or embedded in the URL as a parameter. If you configure Oracle Web Cache to cache the pages that use a session ID, subsequent requests that pass the cookie or embedded URL parameter are served from the cache.
To create caching rules for pages that support session tracking:
The Session/Personalized Related Caching Rules page appears in the right pane.
The Add Session/Personalized Attribute Related Caching Rules dialog box appears.
If the sessions listed do not contain the definition you require, then choose Create Session/Personalized Attribute to create a new session definition. The Edit/Create Session/Personalized Attribute Definition dialog box appears. Continue to Step 5.
If you enter both a cookie name and an embedded URL parameter, keep in mind that both must be used to support the same session. If they support different sessions, create separate session definitions. You can specify up to 20 definitions for each page.
default.
The Change Policy-Selector Association dialog box appears.
The selector moves to the left list and the dialog box closes. Proceed to Step 11.
If the selector you require does not exist, then create a cacheability rule for the pages the support session tracking, as described in "Configuring Cacheability Rules". In Step 10 of the procedure, select Apply the following and a rule in the Session/Personalized Attribute Related Caching row of the Edit/Create Cacheability Rule dialog box.
The Oracle Web Cache Operations page appears in the right pane.
Some Web sites require users to have sessions while surfing most pages. If you want to preserve the session requirement, then you need to create a session-related caching rule for those pages. This way, a request without a session will always be served by the application Web server.
For some popular site entry pages, such as "
1. Create a blank page for the entry URL, such as "
2. Make the application Web server create a session when the blank page is requested without session.
3. Create a cacheability rule for the real entry page and the blank page, as described in "Configuring Cacheability Rules".
In Step 10 of the procedure, select Apply the following and then select a session-related caching rule with a value of cache with session, no cache w/o session in the Session/Personalized Attribute Related Caching Rules row of the Edit/Create Cacheability Rule dialog box.
In this way all initial user requests to the entry URL will first hit the blank page, which requires minimal resources to generate, and receive the response and session establishment from the application Web server. Subsequent redirected requests to the more expensive entry page will carry the session, enabling it to be served out of the cache.
Tip:
/", 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.
This section describes how to enable dynamic assembly of Web pages of HTML fragments and 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: content="ESI/1.0" header in the HTTP response message:
Surrogate-Control: max-age=30+60, content="ESI/1.0"
In Step 9 of the procedure, select Yes or No to enable or disable other client caches to process ESI tags.
Surrogate-Control: content="ESI/1.0" header in the HTTP response message.
Specify rules that cache the static HTML fragments and do not cache the truly dynamic fragments that require application Web server and database server generation.
You can use variable expressions to achieve the same substitution as personalized attribute 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 Pages with Simple Personalization".
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 6-8 shows a portal site page, http://www.company.com/servlets/esi?username=jesse&userID=004&zipcode=94108&SportsSelection=golf, for a registered user named Jesse.
An esi Java servlet reads in the portal.esi file, which is a template page comprised of ESI markup tags, and processes the ESI tags to display the correct stock, news, and weather output for user Jesse. The servlet also sets the Surrogate-Control: content="ESI/1.0" header to enable ESI processing.
Without ESI, the servlet output would have been a pure HTML file. Because of its dynamic content, including a rotating banner ad, a personalized greeting, stock quotes, regional weather, and news content, this page would not be cacheable. For example, the src attribute of the <img> tag for the banner ad changes for each request, making it uncacheable:
<img src="http://www.companyad.com/adbanner/item11934502">
On the other hand, with ESI markup tags, Oracle Web Cache is able to assemble and cache most of the content. The rest of this section examines the ESI markup used in portal.esi and shows how ESI increases overall cacheability. Note that much of the HTML formatting has been removed for the sake of clarity.
Figure 6-9 shows the markup for the rotating ad banner and the personalized greeting Welcome, jesse!. The banner relies on alternate processing with the <esi:try> tag. If the servlet cannot run AdBanner, then a link to www.oracle.com appears in the banner's place. The personalized greeting is achieved by the <esi:vars> tag, which bases the greeting on the username parameter embedded in the URL. username is the registered user's name. This markup enables the banner and personalized greeting to be included in the cacheable template page.
<table width="100%" cellpadding="2" cellspacing="0" border="0" align="Center" height="98"> <tbody> .... <!-- Rotating Ad Banner --> <esi:try> <esi:attempt> <esi:comment text="Include an ad banner <img> html tag"/> <esi:include src="/servlets/AdBanner"/> </esi:attempt> <esi:except> <esi:comment text="Just write some HTML instead"/> <a href=www.oracle.com>www.oracle.com</a> </esi:except> </esi:try> .... <!-- Personalized Greeting --> <p> <esi:vars>Welcome, $(QUERY_STRING{username})!</esi:vars> </p> .... </tbody> </table> <br> ....
As shown in Figure 6-10, the response to the included image fragment for the banner is not cacheable. The first time a user requests this page, Oracle Web Cache sends the request to the application Web server to generate the banner. On the application Web server, AdBanner generates the banner for the request.
<table width="100%" cellpadding="2" cellspacing="0" border="0" align="Center" height="98"> <tbody> .... <!-- Rotating Ad Banner --> <a href="www.companyad.com/redirect?item=11934502"> <img src="http://www.companyad.com/adbanner/item11934502"></a> .... <!-- Personalized Greeting --> <p> Welcome, jesse! </p> </tbody> </table> <br> ....
As shown in Figure 6-11, the next time the user reloads the page, AdBanner generates another banner for the request.
<table width="100%" cellpadding="2" cellspacing="0" border="0" align="Center" height="98"> <tbody> .... <!-- Rotating Ad Banner --> <a href="www.companyad.com/redirect?item=123456602"> <img src="http://www.companyad.com/adbanner/item123456602"></a> .... <!-- Personalized Greeting --> <p> Welcome, jesse! </p> </tbody> </table> <br> ....
By separating the generation of the included image fragment response from the template page, Oracle Web Cache is able to cache the template and integrate the dynamic ad banner into the template.
The markup for My Stocks, World Markets, and Movers is depicted in Figure 6-12. My Stocks includes a fragment named PersonalizedStockSelection. The displayed stocks are based on the userID parameter encoded in the URL. userID is the registered user's unique ID. The World Markets and Movers sections rely on alternate processing with the <esi:try> tag. The <esi:try> tag first attempts to include data from external sites. If the content cannot be fetched, then the message Sorry, can't display indexes displays.
.... <table width="100%" cellpadding="2" cellspacing="0" border="0"> <tbody> <tr> <td> My Stocks </td> <td> World Markets </td> <td> Movers </td> </tr> <tr> <td width="26%"> <!-- Personalized Stock Content --> <esi:include src="/servlets/PersonalizedStockSelection?userID=$(QUERY_ STRING{userID})" /> </td> <td valign="Top" width="23%"> <!-- External World Market Content --> <esi:try> <esi:attempt> <esi:include src="/servlets/Proxy?url=http://www.service.com/WorldMarketIndex"> </esi:attempt> <esi:except> Sorry, can't display indexes </esi:except> </esi:try> </td> <!-- External Movers Content --> <td valign="Top" width="51%"> <esi:try> <esi:attempt> <esi:include src="/servlets/Proxy?url=http://www.service.com/Movers"> </esi:attempt> <esi:except> Sorry, can't display second set of indices </esi:except> </esi:try> </td> </tr> </tbody> </table> ....
The markup for the included fragment PersonalizedStockSelection is depicted in Figure 6-13. It includes fragments for three stock quotes: IBM, ORCL, and YHO.
<table width="160" cellspacing="0" cellpadding="0" border="0"> <tbody> <tr> <br> <esi:include src="Quote?symbol=IBM"/> <br> <esi:include src="Quote?symbol=ORCL"/> <br> <esi:include src="Quote?symbol=YHO"/> <br> </tr> </tbody> </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 Figure 6-14. It includes fragments for three stock quotes: IBM, ORCL, and SCO. As already described, IBM and ORCL are also shared by Jesse. If Jesse reloads the page first and caches the quotes, then the IBM and ORCL quotes for Scott are automatically refreshed.
<table width="160" cellspacing="0" cellpadding="0" border="0"> <tbody> <tr> <br> <esi:include src="Quote?symbol=IBM"/> <br> <esi:include src="Quote?symbol=ORCL"/> <br> <esi:include src="Quote?symbol=SCO"/> <br> </tr> </tbody> </table>
Figure 6-15 shows the markup for Latest Headlines, Weather, and Sports.
Latest Headlines displays the content based on the user's NewsSelection category, internet or finance, by using conditional processing with the <esi:choose> tag. Because the URL of the Company Portal page in Figure 6-8 did not embed the NewsSelection parameter, the output includes the top news stories, /News?type=Top&topic=TopNews.
Weather uses the <esi:vars> tag to display the current weather conditions based on the registered user's zip code. Because Jesse entered in zipcode=94108 in the URL, the output includes weather conditions for San Francisco, California.
Sports displays the sports content based on the user's SportsSelection category: golf, soccer, football, baseball, or basketball. Because the URL for user Jesse embeds SportsSelection=golf, the output includes headlines relating to golf, /News?type=Top&topic=GolfNews.
.... <!-- News, Weather, and Sports Content --> <table width="100%" cellpadding="2" cellspacing="0" border="0"> <tbody> <tr> <td> Latest Headlines </td> <td> Weather </td> <td> Sports </td> </tr> <tr> <td> <!-- News Content --> <!-- Use the esi include tag so that different portal users can share the included news HTML snippet --> <esi:choose> <esi:when test="$(QUERY_STRING{NewsSelection}) == 'internet'"> <esi:include src="/News?type=Top&topic=TopTechNews" onerror="continue"/> </esi:when> <esi:when test="$(QUERY_STRING{NewsSelection}) == 'finance'"> <esi:include src="/News?type=Top&topic=TopFinanceNews" onerror="continue"/> </esi:when> <esi:otherwise> <esi:include src="/News?type=Top&topic=TopNews" onerror="continue"/> </esi:otherwise> </esi:choose> </td> <td> <!-- Weather --> <esi:vars> <img src="http://www.SomeWeather.com/servlets/GetWeather?zipcode=$(QUERY_ STRING{zipcode})"> </esi:vars> <td> <!-- Sports --> <!-- Use the esi include tag so that different portal users can share the included sports HTML snippet --> <esi:choose> <esi:when test="$(QUERY_STRING{SportsSelection}) == 'golf'"> <esi:include src="/News?type=Top&topic=GolfNews" onerror="continue"/> </esi:when> <esi:when test="$(QUERY_STRING{SportsSelection}) == 'soccer'"> <esi:include src="/News?type=Top&topic=SoccerNews" onerror="continue"/> </esi:when> <esi:when test="$(QUERY_STRING{SportsSelection}) == 'football'"> <esi:include src="/News?type=Top&topic=FootballNews" onerror="continue"/> </esi:when> <esi:when test="$(QUERY_STRING{SportsSelection}) == 'baseball'"> <esi:include src="/News?type=Top&topic=BaseballNews" onerror="continue"/> </esi:when> <esi:when test="$(QUERY_STRING{SportsSelection}) == 'basketball'"> <esi:include src="/News?type=Top&topic=BasketballNews" onerror="continue"/> </esi:when> <esi:otherwise> <esi:include src="/News?type=Top&topic=SportsNews" onerror="continue"/> </esi:otherwise> </esi:choose> </td> </tr> </tbody> </table>
As described in Step 3 of "Configuring Rules for Pages with Simple Personalization", 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 Figure 6-16. 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>');
Figure 6-17 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>');
In addition to creating cacheability rules with Oracle Web Cache Manager interface, application developers can choose to store some of the cacheability attributes in the header of an HTTP response message. This feature enables the application Web server to override the settings configured through the Oracle Web Cache Manager interface, as well as allowing other third-party caches to use Oracle Web Cache cacheability attributes.
To enable this feature, configure the HTTP response with the Surrogate-Control response-header field as follows:
Surrogate-Control:control_directive,control_directive,...
Table 6-4 describes the supported control directives.
Table 6-4 Surrogate-Control Control Directives
no-store and no-store-remote are mutually exclusive.
content="ESI/1.0" and content="webcache/1.0" are mutually exclusive.
In the following example, the Surrogate-Control response-header field specifies that the document is to expire in 30 seconds 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="ESI/1.0"
In the following example, the Surrogate-Control response-header field specifies that the document is not to be cached:
Surrogate-Control: no-store
|
 Copyright © 2001 Oracle Corporation. All Rights Reserved. |
|