| Oracle9iAS Web Cache Administration and Deployment Guide Release 2 (9.0.2) Part Number A95404-02 |
|
This chapter explains how to configure caching rules.
This chapter contains these topics:
Using Oracle9iAS Web Cache to specify caching rules, you can select to cache or not to cache content for static documents, multiple-version documents, personalized pages, pages that support a session cookie or embedded URL parameter, and dynamic pages.
This section discusses the following topics:
When you create caching rules, you create site-specific caching rules that apply to a particular site and global rules that apply to all sites.
Generally, when you assign caching 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 caching 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
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 caching rules in Oracle9iAS 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 caching 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 caching 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 7-1 shows examples of content to cache and how to enter regular expression syntax for corresponding caching rules for that content.
When Oracle9iAS Web Cache is installed, site-specific and global caching rules are established for the configured default site.
Figure 7-1 displays the default site-specific caching rules.
Table 7-2 describes the default site-specific caching rules.
Figure 7-2 displays the default global caching rules.
Table 7-3 describes the default global caching rules.
To configure caching rules:
The Cacheability Rules page appears.
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 can 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.
In ESI Output Permission, select either Yes or No. The default is Yes.
|
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:
The default is Yes and Compress for all browsers. 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:
See Also: "Compression" for an overview |
|
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:
|
|
Multiple Documents with the Same Selector by Cookies |
Select None to not have Oracle9iAS 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 General Configuration > Cacheability > Multiple Documents with the Same Selector to create a new rule. See Also:
|
|
Multiple Documents with the Same Selector by Other Headers |
Select the HTTP request headers whose values Oracle9iAS Web Cache will use to cache and identify multiple-version documents. Oracle9iAS Web Cache Manager enables you to 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,*/* Accept-Encoding: gzip Accept-Language: en Accept-Charset: iso-8859-1,*,utf-8 Notes:
See Also:
|
|
Session/Personalized Attribute Related Caching Rules |
Select None to not have Oracle9iAS Web Cache cache or serve documents based on session or personalized attribute information contained within a cookie or embedded in a URL as a parameter. Select Apply the following to specify how Oracle9iAS Web Cache caches and serves documents with session or personalized attribute cookies or embedded URL parameters. If you do not see the session rules these documents require, then choose General Configuration > Cacheability > Session/Personalized Caching Rules to create a new rule. See Also:
|
|
Simple Personalization |
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. Oracle9iAS Web Cache will replace the value information based on the value of the cookie or the embedded URL parameter. Oracle9iAS Web Cache then serves these pages for Web browser requests that contain the cookie or the embedded URL parameter. See Also:
|
|
HTTP Error Caching |
Enter the HTTP error codes you want Oracle9iAS Web Cache to cache. If you enter multiple codes, use a comma to separate them. If there is a problem on the origin server 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" |
In addition to or as an alternative to creating caching rules with Oracle9iAS 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 Caching Attributes in Response Headers" for details.
Tip:
Once the caching rules are configured, prioritize them.
To assign priority to rules:
Higher priority rules are processed first.
Table 7-4 illustrates how an administrator might set up caching rules for a catalog built on Oracle iStore 11i technology, which enables e-merchants to design, build, and publish their stores on the World Wide Web.
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.
The Create Expiration Rule dialog box appears.
While the first two options enable you to set expiration for Oracle9iAS Web Cache-specific rules, the third option recognizes the expiration policy established for the documents already programmed with an HTTP Expires response-header field.
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 caching rule, as described in "Configuring Caching Rules". In Step 10 of the procedure, select an expiration rule in the Expiration Rule row of the Create Cacheability Rule dialog box.
You can specify which category cookies whose values Oracle9iAS 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.
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 caching rule, as described in "Configuring Caching 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.
|
See Also:
"Multiple Versions of the Same Document" for an overview and an example scenario |
You can specify which HTTP request headers whose values Oracle9iAS 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 Oracle9iAS 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 configure Oracle9iAS Web Cache to ignore the value of embedded URL parameters so that one version of a page can served to multiple users.
|
See Also:
"Ignoring the Value of Embedded URL Parameters" for an overview and an example scenario |
To ignore the value of URL parameters:
The Session/Personalized Attribute Definitions page appears.
The Create Session/Personalized Attribute Definition dialog box appears.
Oracle9iAS Web Cache uses the default string for those requests without the parameter information. For these requests, Oracle9iAS Web Cache substitutes the session information with the default string. The string defaults to default. If you want to instead require that the request obtain the embedded URL parameter settings from the origin server, perform Step 3.
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 Oracle9iAS Web Cache to substitute session information for one user with another based on the session information contained within a cookie or an embedded URL 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.
The Session/Personalized Attribute Definitions page appears.
The Create Session/Personalized Attribute Definition dialog box appears.
If you enter both a cookie name and an embedded URL 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.
Oracle9iAS Web Cache uses the default string for those requests without the cookie or parameter information. For these requests, Oracle9iAS Web Cache substitutes the session information with the default string. The string defaults to default. If you want to instead require that the request get the cookie or embedded URL parameter settings from the origin server, perform Step 4.
In Step 10 of the procedure, select Yes in the Simple Personalization row of the Edit/Create Cacheability Rule dialog box to substitute session information in session-encoded URLs.
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 Oracle9iAS Web Cache to substitute the value of personalized attributes contained within <!-- WEBCACHETAG--> and <!-- WEBCACHEEND--> tags based on the information contained within a cookie or an embedded URL parameter.
|
See Also:
"Personalized Attributes" for an overview and an example scenario |
To create rules for personalized pages:
The Session/Personalized Attribute Definitions page appears.
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 substitution. If they support different substitutions, create separate personalized definitions. You can specify up to 20 definitions for each page.
Oracle9iAS Web Cache uses the default string for those requests without the cookie or parameter information. For these requests, Oracle9iAS Web Cache substitutes the personalized attribute with the default string. The string defaults to default. If you want to instead require that the request get the cookie or embedded URL parameter settings from the origin server, perform Step 4.
In Step 10 of the procedure, select Yes in the Simple Personalization row of the Edit/Create Cacheability Rule dialog box to substitute information in personalized attributes.
<!-- 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" |
To understand how to cache personalized content, consider the HTML page monthly.htm in Figure 7-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 Session-Related or Personalized Attributed-Related Caching Rules" 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 Oracle9iAS Web Cache was caching monthly.htm:
monthly.htm at URL monthly.htm?Month=October was requested. Because the initial request was forwarded by Oracle9iAS 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.
Oracle9iAS Web Cache substituted October with the value of January.
You can specify how Oracle9iAS Web Cache serves requests with the existence or nonexistence of session or personalized attribute cookies or embedded URL parameters.
|
See Also:
|
To create caching rules for pages that support session cookies or personalized attributes:
The Session/Personalized Attribute Related Caching Rules page appears.
The Add Session/Personalized Attribute Related Caching Rules dialog box appears.
If the sessions or personalized attributes listed do not contain the definition you require, then choose Cancel to exit the Add Session/Personalized Attribute Related Caching Rules dialog box. Continue to Step 5.
The Session/Personalized Attribute Definitions page appears.
The Create Session/Personalized Attribute Definitions dialog box appears.
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 or personalized attribute. If they support different sessions or personalized attributes, create separate definitions. You can specify up to 20 definitions for each page.
Oracle9iAS Web Cache uses the default string for those requests without the cookie or parameter information. For these requests, Oracle9iAS Web Cache substitutes the session ID or personalized attribute information with the default string. The string defaults to default.
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 caching rule for the pages the support session or personalized attributed cookie or embedded URL parameter, as described in "Configuring Caching 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.
Some Web sites require users to have sessions while surfing most pages. If you want to preserve the session requirement, then 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 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.
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 will 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:
|
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 of fragments and create rules for the cacheable and non-cacheable page fragments. It contains the following topics: