Oracle Web Cache Administration and Deployment Guide Release 1.0.2.3 Part Number A86722-03 |
|
This chapter explains how to configure cacheability rules. It 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 URLs, personalized pages, pages that support session tracking, and HTTP error messages.
Generally, when you assign cacheability rules, you specify the regular expression matching the URL and whether you want the documents contained in the URL cached or not cached. You then order the cacheability rules in order of priority. Higher priority rules are processed 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:
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 update transactions, shopping cart views, personal account views, and so forth. 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.
If no cacheability rules are specified, then Oracle Web Cache behaves just as HTTP proxy cache does, that is, it relies on HTTP header information to determine what is cacheable. Generally, HTTP proxy caches store only pages with static content.
Please 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 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
Table 6-2 shows examples of content to cache and how to enter regular expression syntax for corresponding cacheability rules for that content.
Table 6-2 Regular Expression Examples
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.
^
" to denote the start of the URL and "$
" to denote the end of the URL.
If you select Cache, continue to Step 6. If you select Don't Cache, skip to Step 7.
GET/POST Caching |
Select or deselect to cache documents that contain
Important: If your Web site's |
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, choose Create A New Rule to create a new rule. See Also: Step 4 in "Configuring Expiration Rules" |
Multiple Documents with Same URL by Cookies |
Select None to not have Oracle Web Cache cache multiple-version documents that use cookies. Select Apply the following to have Oracle Web Cache cache multiple-version documents that rely on category cookie values, and then select the required cookies. If you do not see a cookie rule that can be applied to these documents, 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 URLs Containing Cookies" |
Multiple Documents with Same URL by Other Headers |
Select the HTTP request headers whose values Oracle Web Cache will use to cache and identify multiple-version URLs.
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 a HTTP request header of |
Session-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 have Oracle Web Cache cache documents with session information, and then select the required session definitions. If you do not see the session these documents require, 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 |
Personalized Pages |
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 Personalized Pages" for further information about creating rules for personalized pages |
HTTP Error Caching |
Enter the HTTP errors 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, you can 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" |
Need Compression |
Select to compress the documents upon insertion into the cache. If a document retrieved from the application Web server already contains a |
Figure 6-1 illustrates how an administrator might set up cacheability rules for a catalog built on Oracle iStore technology, which enables e-merchants to design, build, and publish their stores on the World Wide Web.
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.
Expires
header.
The Change Policy-URL Association dialog box appears.
You can specify which category cookies whose values Oracle Web Cache will use to cache and identify multiple-version URLs.
To specify cookie values for multiple-version URLs:
The Multiversion URLs with the Same URL by Cookies page appears in the right pane.
The Edit/Create Multiple Documents with Same URL by Cookies Rule dialog box appears.
Choose No to not cache versions of documents that do not use this cookie's value.
The Change Policy-URL Association dialog box appears.
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 Same URL 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 "Hello, <Name>" or "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 Edit/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.
<!-- WEBCACHETAG>
and<!-- WEBCACHEEND-->
as follows:
<!-- WEBCACHETAG="personalized_attribute
"-->
personalized attribute HTML segment
<!-- WEBCACHEEND-->
The personalized attribute information can be any valid HTML segment with beginning (<
tag
>
) and ending (</
tag
>
) HTML tags.
Ensure both tags have a space after <!--
.
If a request comes in without the cookie or embedded URL parameter, Oracle Web Cache substitutes the personalized attribute or session ID information with an empty string. In addition, for session-encoded URLs, session establishment is delayed until there is a cache miss, as described in "Session-Encoded URLs".
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:
To understand how to cache personalized content, consider the HTML page monthly.htm
in Figure 6-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.
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 Related Caching Rule dialog box.
See Also:
"Configuring Rules for Pages with Session Tracking" for more information about creating session-related 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
, requests for monthly.htm
were sent to Oracle Web Cache:
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.
Note that Oracle Web Cache ignores the values of session cookies. The response from the application Web server is cached, even if the response session cookie value does not match the request session cookie value. If you do not want the response cached when there is a value mismatch, then modify the application to instead send a non-200 status code as the response.
To create caching rules for pages that support session tracking:
The Session Related Caching Rules page appears in the right pane.
The Add Session Related Caching Rule dialog box appears.
If the sessions listed do not contain the definition you require, choose Create Session 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.
If a request for a page that supports personalized attributes or session-encoded URLs comes in without the cookie or embedded URL parameter, Oracle Web Cache substitutes the personalized attribute or session ID information with an empty string. In addition, for session-encoded URLs, session establishment is delayed until there is a cache miss, as described in "Session-Encoded URLs".
If you want to instead require that the request get the cookie or embedded URL parameter settings from the application Web server, select YES in Step 6 and NO in Step 7.
Note:
The Change Policy-URL Association dialog box appears.
The Oracle Web Cache Operations page appears in the right pane.
For some pages like the home page, you may want the first request to be served from the cache rather than from the application Web server. You can achieve this by following these steps:
1. Create a blank page that redirects to the home page.
2. Move the session creation from the home page to the blank page.
3. Create a session-related caching rule for the blank page to track the session.
4. Create a cacheability rule for the home page, as described in "Configuring Cacheability Rules".
Tip:
|
Copyright © 1996-2001 Oracle Corporation. All Rights Reserved. |
|