Skip Headers

Oracle9iAS Web Cache Administration and Deployment Guide
Release 2 (9.0.2)

Part Number A95404-02
Go To Documentation Library
Home
Go To Product List
Solution Area
Go To Table Of Contents
Contents
Go To Index
Index

Go to previous page Go to next page

7
Creating Caching Rules

This chapter explains how to configure caching rules.

This chapter contains these topics:

Caching Rules Overview

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:

Rule Creation

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:

  1. ^/cec/cstage\?ecaction=ecpassthru2, GET and GET with query string, Don't Cache

  2. ^/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.


Note:

Site-specific caching rules are given a higher priority than the global rules.


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.

  1. ^/cec/cstage\?ecaction=ecpassthru2, GET and GET with query string, Don't Cache

  2. ^/cec/cstage\?ecaction=ecpassthru.*, GET and GET with query string, Cache

  3. ^/cec/cstage\?ecaction=ecpassthru.*, POST, action=search, Cache


    Note:

    If no caching rules are specified, then Oracle9iAS 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.


Rule Syntax

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:

Table 7-1 shows examples of content to cache and how to enter regular expression syntax for corresponding caching rules for that content.

Table 7-1  Regular Expression Examples
Content to Cache Regular Expression Syntax

URL beginning with /machine/doc and ending in *.gif

^/machine/doc/.*\.gif$

All Graphics Interchange Format (GIF) images

\.gif$

/robots.txt file

^/robots.txt$

All procedures in the new_employee package

^/pls/enroll_db/new_employee

Default Caching Rules

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.

Figure 7-1 Default Site-Specific Caching Rules

Text description of cache4.gif follows.

Text description of the illustration cache4.gif

Table 7-2 describes the default site-specific caching rules.

Table 7-2  Default Site-Specific Caching Rules
Priority URL Expression HTTP Method(s) Cache/Don't Cache Description

1

discoverer5.(qv=[0-9]+)

Get, Get with query string

Don't Cache

Instructs Oracle9iAS Web Cache to not cache any page that has been generated by the re-run query button

2

discoverer5.(_?in=swblwbr=[0-9]+)

Get, Get with query string

Don't Cache

Instructs Oracle9iAS Web Cache to not cache the Scheduled Workbooks page or workbooks derived from it

3

discoverer5.release=true

Get, Get with query string

Don't Cache

Allows consistent execution of Discoverer Plus

4

discoverer5

Get, Get with query string

Cache

Instructs Oracle9iAS Web Cache to cache documents under the URL http://host:port/discoverer
/discoverer5

5

/ptg/rm

Get, Get with query string

Cache

Instructs Oracle9iAS Web Cache cache the default Oracle9iAS Wireless servlet. This rule is necessary for Wireless to use Oracle9iAS Web Cache to cache transformations. If you change your Wireless servlet mount-point to something other than /ptg/rm, update this rule for this to take effect.

Figure 7-2 displays the default global caching rules.

Figure 7-2 Default Global Caching Rules

Text description of cacheb.gif follows.

Text description of the illustration cacheb.gif

Table 7-3 describes the default global caching rules.

Table 7-3  Default Global Caching Rules
Priority URL Expression HTTP Method(s) Cache/Don't Cache Description

6

\.pdf$

Get, Get with query string

Don't Cache

Instructs Oracle9iAS Web Cache to not cache documents ending in .pdf

7

\.html?$

Get, Get with query string

Cache

Instructs Oracle9iAS Web Cache to cache all .htm and .html files

8

\.(gif|jpe?g)$

Get, Get with query string

Cache

Instructs Oracle9iAS Web Cache to cache all .gif, .jpg, and .jpeg files

9

\.(bmp|png)$

Get, Get with query string

Cache

Instructs Oracle9iAS Web Cache to cache all .bmp and .png files

10

\.js$

Get, Get with query string

Cache

Instructs Oracle9iAS Web Cache to cache .js (JavaScript) files

Configuring Caching Rules

To configure caching rules:

  1. Start Oracle9iAS Web Cache Manager.

    See Also:

    "Starting Oracle9iAS Web Cache Manager"

  2. In the navigator pane, select General Configuration > Cacheability Rules.

    The Cacheability Rules page appears.

  3. From the For Site list, select the Web site for which to view or create site-specific caching rules.

  4. In the Cacheability Rules page, choose Create Site Specific Rule or Create Global Rule if no rules exist. If rules already exist, select a rule, and then choose Insert Above or Insert Below.

    The Create Cacheability Rule or Edit/Create Cacheability Rule dialog box appears.

  5. In the URL Expression field, enter regular expression syntax, matching the URLs to which you want the caching rule to apply.

    Remember to use "^" to denote the start of the URL and "$" to denote the end of the URL.

  6. In the Method section, select to cache documents that use GET, GET with query string, or POST HTTP request methods.

    You can select more than one request method.


    Note:

    If your Web site's GET with query string or POST methods are used for forms that make changes to the origin server or database, then do not select Get with query string or POST. These options should only be selected if the forms are used in search forms.


  7. If you selected POST in Step 6, specify the HTTP POST body of the documents in the POST Body Expression field.

    To apply this rule to any POST request body, enter ".*" in the field.

  8. Select Cache or Don't Cache for the documents contained within the URL.

  9. Optionally, to help track the meaning of rules, enter a comment for the caching rule in the Comment field.

    In ESI Output Permission, select either Yes or No. The default is Yes.

  10. Select options for the rows that apply, and then choose Submit:

    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:

    • Compress for all browsers to serve compressed documents to all browser types

    • Compress for non-Netscape browsers only to serve compressed documents for all browsers other than Netscape

    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:

    • Oracle Corporation recommends not compressing images, such as GIFs and JPEGs, as well as executables and files that are already zipped with utilities like WinZip and GZIP. Compressing these files incurs additional overhead without the benefits of compression.

    • Even if compression is turned on, Oracle9iAS Web Cache does not compress documents containing the following:

      - A Content-Encoding response-header field, which is typically used to denote compression

      - A Content-Disposition response-header field, which is typically used for attachments

      - Session-encoded URLs, the <!--WEBCACHETAG--> and
      <!-- WEBCACHEEND--> tags, and ESI tags

    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:

    Accept: Specifies which media types are acceptable for the response

    Accept-Charset: Specifies which character sets are acceptable for the response

    Accept-Encoding: Restricts the content-encodings that are acceptable in the response

    Accept-Language: Specifies the set of languages that are preferred as a response

    User-Agent: Contains information about the Web browser that initiated the request

    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:

    • Oracle9iAS Web Cache does not interpret the values of these HTTP request headers. If the values for two pages are different, Oracle9iAS 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, Oracle9iAS Web Cache serves two pages.

    • You can specify other HTTP request-header fields with the Surrogate-Control response-header field, as described in "Configuring Caching Attributes in Response Headers".

    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 <!-- WEBCACHETAG--> and the <!-- WEBCACHEEND--> HTML tags

    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"

  11. Repeat Steps 3 through 11 for each caching rule.


    Tip:

    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.


Once the caching rules are configured, prioritize them.

To assign priority to rules:

  1. In the Cacheability Rules page, select a caching rule, and then choose Move Up or Move Down to order the rules.

    Higher priority rules are processed first.

  2. Apply changes and restart Oracle9iAS Web Cache:

    1. In the Oracle9iAS Web Cache Manager main window, choose Apply Changes.

    2. In the navigator pane, select Administration > Operations.

      The Operations page appears.

    3. In the Operations page, choose Restart to restart Oracle9iAS Web Cache.

Caching Rules Example

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.

Table 7-4  Oracle iStore Caching Rules Example
Priority URL Expression HTTP Method(s) Cache/Don't Cache Description

1

/html/ibeCCkdHdr.*\.jsp.*

Get, Get with query string, POST

Don't Cache

Instructs Oracle9iAS Web Cache to not cache billing details

2

/html/ibeCCkpOrdReview\.jsp.*

Get, Get with query string, POST

Don't Cache

Instructs Oracle9iAS Web Cache to not cache review order page

3

/html/ibeCA.*\.jsp.*

Get, Get with query string, POST

Don't Cache

Instructs Oracle9iAS Web Cache to not cache the account page

4

/html/beCPmdPmtBook.\.jsp.*

Get, Get with query string, POST

Don't Cache

Instructs Oracle9iAS Web Cache to not cache the payment book

5

/html/ibeCXpd.*\.jsp.*

Get, Get with query string, POST

Don't Cache

Instructs Oracle9iAS Web Cache to not cache order confirmation

6

/html/ibeCSl.*\.jsp.*

Get, Get with query string, POST

Don't Cache

Instructs Oracle9iAS Web Cache to not cache shopping lists

7

/html/ibeCSc.*\.jsp.*

Get, Get with query string, POST

Don't Cache

Instructs Oracle9iAS Web Cache to not cache shopping cart details

8

/html/ibeCOtdOrdSumMain\.jsp.*

Get, Get with query string, POST

Don't Cache

Instructs Oracle9iAS Web Cache to not cache the order status in account pages

9

/html/ibeCCtpBuyRoute\.jsp.*

Get, Get with query string

Cache

Instructs Oracle9iAS Web Cache to cache the buy routing page

10

/html/ibeCZzpHome.*\.jsp$

Get, Get with query string

Cache

Instructs Oracle9iAS Web Cache to cache the home page

11

/html/ibeCCtpSctDspRte.jsp

Get, Get with query string

Cache

Instructs Oracle9iAS Web Cache to cache the section routing page

12

/html/ibeCCtpItmDspRte.jsp

Get, Get with query string

Cache

Instructs Oracle9iAS Web Cache to cache the item routing page

13

/html/ibeCSrdSrchResults.*\.jsp

Get, Get with query string

Cache

Instructs Oracle9iAS Web Cache to cache the search results page

14

/OA_MEDIA/.*

Get, Get with query string

Cache

Instructs Oracle9iAS Web Cache to cache all images and multimedia

15

/html/jtfucss.*\.css

Get, Get with query string

Cache

Instructs Oracle9iAS Web Cache to cache the default style sheet


Note:

Implementations of Oracle iStore can be customized. Therefore, these caching rules will not apply to all Oracle iStore deployments. See the Oracle iStore documentation for the most current information on implementing caching rules for Oracle iStore deployments.


Configuring Expiration Rules

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:

  1. Start Oracle9iAS Web Cache Manager.

    See Also:

    "Starting Oracle9iAS Web Cache Manager"

  2. In the navigator pane, select General Configuration > Cacheability Rules > Expiration Rules.

    The Expiration Rules page appears.

  3. In the Expiration Rules page, choose Create.

    The Create Expiration Rule dialog box appears.

  4. In the Expire section, specify when to expire documents by selecting one of the following options:

    Expire <time> after cache entry

    Select this option to base expiration on when the documents entered the cache. Enter the number of seconds to expire the documents.

    Expire <time> after document creation

    Select this option to base expiration on when the documents were created. Enter the number of seconds to expire the documents.

    Expires as per HTTP Expires header

    Select this option to respect the HTTP Expires response-header field. This is the default. In order to utilize this option, documents must be programmed to use the HTTP Expires response-header field.

    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.

  5. In the After Expiration section, specify how you want Oracle9iAS Web Cache to process documents once they have expired:

    Remove immediately

    Select this option to have Oracle9iAS Web Cache mark documents as invalid and then remove them immediately. A document is refreshed from the application Web server when the cache receives the next request for it.

    Refresh on demand as application Web server capacity permits AND no later than <time> after expiration

    Select this option to have Oracle9iAS Web Cache mark documents as invalid and then refresh them based on application Web server capacity. Enter the maximum time in which the documents can reside in the cache.


    Note:

    Performance assurance heuristics apply when you configure documents to be refreshed based on when the application Web servers can refresh them; performance assurance heuristics do not apply to documents immediately removed.


  6. Choose Submit.

  7. Repeat Steps 3 through 6 for each expiration rule.

  8. In the Expiration Rules page, select the newly-created rule, and then choose Change Selector Association.

    The Change Policy-Selector Association dialog box appears.

  9. Select a selector from the right list, and then choose the Make Association button.

    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.

  10. Apply changes and restart Oracle9iAS Web Cache:

    1. In the Oracle9iAS Web Cache Manager main window, choose Apply Changes.

    2. In the navigator pane, select Administration > Operations.

      The Operations page appears.

    3. In the Operations page, choose Restart to restart Oracle9iAS Web Cache.

Configuring Rules for Multiple-Version Documents Containing Cookies

See Also:

"Multiple Versions of the Same Document" for an overview and an example scenario

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:

  1. Start Oracle9iAS Web Cache Manager.

    See Also:

    "Starting Oracle9iAS Web Cache Manager"

  2. In the navigator pane, select General Configuration > Cacheability Rules > Multiple Documents with the Same Selector by Cookies.

    The Multiple Documents with the Same Selector by Cookies page appears.

  3. In the Multiple Documents with the Same Selector by Cookies page, choose Create or Add.

    The Edit/Create Multiple Documents with the Same Selector by Cookies Rule dialog box appears.

  4. In the Enter cookie name field, enter the name of the cookie.

  5. For the prompt Also cache documents whose requests do not contain this cookie?, select either Yes or No.

    • Select Yes to cache versions of the document that do not contain this cookie. This option enables Oracle9iAS Web Cache to serve documents from the cache for browser requests that do not contain this cookie

    • Select No to not cache versions of documents that do not contain this cookie.

  6. In the Edit/Create Multiple Documents with the Same Selector by Cookies Rule dialog box, choose Submit.

  7. In the Multiple Documents with the Same Selector by Cookies page, select the newly-created rule, and then choose Change Selector Association.

    The Change Policy-Selector Association dialog box appears.

  8. Select a selector from the right list, and then choose the Make Association button.

    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.

  9. Repeat Steps 3 through 9 for each rule.

  10. Apply changes and restart Oracle9iAS Web Cache:

    1. In the Oracle9iAS Web Cache Manager main window, choose Apply Changes.

    2. In the navigator pane, select Administration > Operations.

      The Operations page appears.

    3. In the Operations page, choose Restart to restart Oracle9iAS Web Cache.

Configuring Rules for Multiple-Version Documents Containing HTTP Request Headers

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.

See Also:

"Configuring Caching Rules"

Configuring Session Definitions to Exclude the Value of URL Parameters

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:

  1. Start Oracle9iAS Web Cache Manager.

    See Also:

    "Starting Oracle9iAS Web Cache Manager"

  2. Create session definitions for those pages that support embedded URL parameters:

    1. In the navigator pane, select General Configuration > Session Management > Session/Personalized Attribute Definitions.

      The Session/Personalized Attribute Definitions page appears.

    2. From the For Site list, select the Web site for which to create site-specific session definitions.

    3. Choose Add or Create.

      The Create Session/Personalized Attribute Definition dialog box appears.

    4. Select either This Site Only or For All Sites.

    5. In the Session/Attribute field, enter an easy-to-remember unique name for the session.

    6. Enter the embedded URL parameter in the URL Parameter field.

    7. In the Default Value (Optional) field, enter a default string that Oracle9iAS Web Cache will use for the cookie or embedded URL parameter value.

      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.

    8. In the Comment field, enter a description for the definition.

    9. Choose Submit.

  3. If you want to require that the request obtain the embedded URL parameter settings from the origin server, perform these additional steps:

    1. Create a session-related caching rule for the page to track the session, as described in "Configuring Session-Related or Personalized Attributed-Related Caching Rules".

    2. In Step 6a of the procedure, select YES as the response.

    3. In Step 6b of the procedure, select NO as the response.

  4. Apply changes and restart Oracle9iAS Web Cache:

    1. In the Oracle9iAS Web Cache Manager main window, choose Apply Changes.

    2. In the navigator pane, select Administration > Operations.

      The Operations page appears.

    3. In the Operations page, choose Restart to restart Oracle9iAS Web Cache.

Configuring Session Definitions and Rules for Session-Encoded URLs

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.

  1. Start Oracle9iAS Web Cache Manager.

    See Also:

    "Starting Oracle9iAS Web Cache Manager"

  2. As necessary, create session definitions for those pages with session-encoded URLs:

    1. In the navigator pane, select General Configuration > Session Management > Session/Personalized Attribute Definitions.

      The Session/Personalized Attribute Definitions page appears.

    2. From the For Site list, select the Web site for which to create site-specific session definitions.

    3. Choose Add or Create.

      The Create Session/Personalized Attribute Definition dialog box appears.

    4. Select either This Site Only or For All Sites.

    5. In the Session/Attribute field, enter an easy-to-remember unique name for the session. You can use the same session definition used for ignoring a URL parameter.

    6. Enter the cookie name in the Cookie Name field and the embedded URL parameter in the URL Parameter field.

      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.


      Note:

      Ensure that the size of cookies is not greater than 3 KB.


    7. In the Default Value (Optional) field, enter a default string that Oracle9iAS Web Cache will use for the cookie or embedded URL parameter value.

      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.

    8. In the Comment field, enter a description for the definition.

    9. Choose Submit.

  3. Create a caching rule for the documents that use the session, as described in "Configuring Caching Rules".

    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.

  4. If you want to require that the request get the cookie or embedded URL parameter settings from the origin server, perform these additional steps:

    1. Create a session-related caching rule for the page to track the session, as described in "Configuring Session-Related or Personalized Attributed-Related Caching Rules".

    2. In Step 6a of the procedure, select YES as the response.

    3. In Step 6b of the procedure, select NO as the response.

  5. Apply changes and restart Oracle9iAS Web Cache:

    1. In the Oracle9iAS Web Cache Manager main window, choose Apply Changes.

    2. In the navigator pane, select Administration > Operations.

      The Operations page appears.

    3. In the Operations page, choose Restart to restart Oracle9iAS Web Cache.

Configuring Personalized Attribute Definitions and Rules for Personalized Attributes

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:

  1. Start Oracle9iAS Web Cache Manager.

    See Also:

    "Starting Oracle9iAS Web Cache Manager"

  2. As necessary, create attribute definitions for those pages with personalized attributes:

    1. In the navigator pane, select General Configuration > Session Management > Session/Personalized Attribute Definitions.

      The Session/Personalized Attribute Definitions page appears.

    2. From the For Site list, select the Web site for which to create site-specific personalized attribute definitions.

    3. Choose Add or Create.

      The Create Session/Personalized Attribute Definition dialog box appears.

    4. Select either This Site Only or For All Sites.

    5. In the Session/Attribute field, enter an easy-to-remember unique name for the attribute.

      For example, if the attribute is for a personalized greeting that uses the first name, you could enter first_name01 for the session name.

    6. Enter the cookie name in the Cookie Name field and the embedded URL parameter in the URL Parameter field.

      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.


      Notes:

      • Ensure that the size of cookies is not greater than 3 KB.

      • You can also substitute session values between the <!-- WEBCACHETAG--> and <!-- WEBCACHEEND--> tags. To substitute session values, enter the session cookie in the Cookie Name field or the session parameter in the URL Parameter field.


    7. In the Default Value (Optional) field, enter a default string that Oracle9iAS Web Cache will use for the cookie or embedded URL parameter value.

      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.

    8. In the Comment field, enter a description for the definition.

    9. Choose Submit.

  3. Create a caching rule for the personalized pages, as described in "Configuring Caching Rules".

    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.

  4. If you want to require that the request get the personalized attribute cookie or embedded URL parameter settings from the origin server, perform these additional steps:

    1. Create a session-related caching rule for the page to track the session, as described in "Configuring Session-Related or Personalized Attributed-Related Caching Rules".

    2. In Step 6a of the procedure, select YES as the response.

    3. In Step 6b of the procedure, select NO as the response.

  5. Apply changes and restart Oracle9iAS Web Cache:

    1. In the Oracle9iAS Web Cache Manager main window, choose Apply Changes.

    2. In the navigator pane, select Administration > Operations.

      The Operations page appears.

    3. In the Operations page, choose Restart to restart Oracle9iAS Web Cache.

  6. Configure the pages that use personalized attributes with the tags <!-- WEBCACHETAG--> and<!-- WEBCACHEEND--> as follows:

     <!-- WEBCACHETAG="personalized_attribute"-->
    personalized attribute HTML segment
    <!-- WEBCACHEEND-->
    
    

    Ensure that both tags have a space after <!--.


    Important:

    The <!-- WEBCACHETAG--> and <!-- WEBCACHEEND--> tags cannot be used on a page that contains ESI tags for content assembly and partial page caching. If you require simple personalization and are using ESI, see "Using ESI for Simple Personalization".



    Note:

    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.

    See Also: "Example of Simple Personalization with Variable Expressions"


Example: Personalized Page Configuration

To understand how to cache personalized content, consider the HTML page monthly.htm in Figure 7-3.

Figure 7-3 monthly.htm

Text description of personal.gif follows.

Text description of the illustration personal.gif

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.

  1. A personalized attribute of TestMonth was mapped to the embedded URL parameter Month in the Edit/Create Session/Personalized Attribute Definition dialog box.

    Figure 7-4 Edit/Create Session/Personalized Attribute Definition Dialog Box

    Text description of cachea.gif follows
    Text description of the illustration cachea.gif

  2. A session-related caching rule was created that uses the embedded URL parameter Month in the Add Session/Personalized Attribute Related Caching Rule dialog box.

    Figure 7-5 Add Session/Personalized Attribute Related Caching Rule Dialog Box

    Text description of personaa.gif follows.

    Text description of the illustration personaa.gif

    See Also:

    "Configuring Session-Related or Personalized Attributed-Related Caching Rules" for more information about creating personalized attribute caching rules

  3. The <!-- WEBCACHETAG--> and <!-- WEBCACHEEND--> HTML tags were added to monthly.htm.

    Current Month is:
    <!-- WEBCACHETAG="TestMonth"-->October<!-- WEBCACHEEND-->
    
    
  4. A caching rule was created for monthly.htm in the Create Cacheability Rules dialog box:

    1. In the Session/Personalized Attribute Related Caching Rules row, the personalized attribute caching rule for the embedded URL Month was chosen.

    2. In the Simple Personalization row, Yes was chosen to cache substitution instructions for personalized attributes.

    Figure 7-6 Create Cacheability Rule Dialog Box

    Text description of cache6.gif follows
    Text description of the illustration cache6.gif

  5. The configuration changes are applied:

    1. In the Oracle9iAS Web Cache Manager main window, Apply Changes is chosen.

    2. In the Operations page, Oracle9iAS Web Cache is restarted.

To verify that Oracle9iAS Web Cache was caching monthly.htm:

  1. An initial request for 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.

  2. A subsequent request for monthly.htm was sent to URL monthly.htm?Month=January.

    Oracle9iAS Web Cache substituted October with the value of January.

Figure 7-7 monthly.htm When Cached

Text description of personab.gif follows.

Text description of the illustration personab.gif

Configuring Session-Related or Personalized Attributed-Related Caching Rules

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:

  1. Start Oracle9iAS Web Cache Manager.

    See Also:

    "Starting Oracle9iAS Web Cache Manager"

  2. In the navigator pane, select General Configuration > Cacheability Rules or Session Management > Session/Personalized Attribute Related Caching Rules.

    The Session/Personalized Attribute Related Caching Rules page appears.

  3. In the Session/Personalized Attribute Related Caching Rules page, choose Create or Add.

    The Add Session/Personalized Attribute Related Caching Rules dialog box appears.

  4. From the Please select a session/attribute list, select a session or personalized attribute, and then proceed to Step 6.


    Note:

    By default, Oracle9iAS Web Cache provides definitions of the following session identifiers that are commonly used by components of Oracle9i Application Server. The predefined site-specific session identifiers are:

    • JSESSIONID: Used for servlet session tracking. It conforms to the Java 2 Platform, Enterprise Edition (J2EE) standard. The cookie name is JSESSIONID; the embedded URL parameter is jsessionid.

    • PAsid, PAconnxn, PAuserid: PAsid is used for the Oracle9iAS Wireless session ID, PAconnxn is used for the Oracle9iAS Wireless connection ID, and PAuserid is used for the Oracle9iAS Wireless user ID. The embedded URL parameters are PAsid, PAconnxn, and PAuserid, respectively. No cookie names are used.

    The predefined global session identifier is:

    • FoundationPersistentSessionID: Used by Oracle9iAS Foundation Classes for persistent session tracking. The cookie name is ESFSID. There is no embedded URL parameter.


    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.

  5. Create a session or personalized attribute definition:

    1. In the navigator pane, select General Configuration > Session Management > Session/Personalized Definitions.

      The Session/Personalized Attribute Definitions page appears.

    2. From the For Site list, select the Web site for which to create site-specific definitions.

    3. Choose Add or Create.

      The Create Session/Personalized Attribute Definitions dialog box appears.

    4. Select either This Site Only or For All Sites.

    5. In the Session/Attribute field, enter an easy-to-remember unique name for the session or personalized attribute.

    6. Enter the cookie name in the Cookie Name field or the embedded URL parameter in the URL Parameter field.

      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.


      Note:

      When a cookie expires, the browser removes the cookie and subsequent requests for the document are directed to the origin server. To avoid pages from being served past the browser session expiration time, ensure that the session cookie expires before the application Web server expires the browser session.


    7. In the Default Value (Optional) field, enter a default string that Oracle9iAS Web Cache will use for the cookie or embedded URL parameter value.

      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.

    8. Optionally, in the Comment field, enter a description of the definition.

    9. Choose Submit.

    10. Repeats Steps 2 through 4.

  6. Select YES or NO to the prompts:


    Note:

    With an embedded URL parameter, Oracle9iAS Web Cache ignores the existence of an embedded URL parameter in the request. In other words, Oracle9iAS Web Cache will cache the response, even if the embedded parameter in the request does not match the embedded parameter in the response. To force the existence of the embedded URL parameter in the browser request, answer YES to the first prompt and NO to the second prompt.


    1. For the prompt 1. Cache documents whose requests contain this session? in the Add Session/Personalized Attribute Related Caching Rule dialog box, select either YES or NO:

      • Select YES to cache versions of documents that use the session cookie or embedded URL parameter.

      • Select NO to not cache versions of documents that use the session cookie or embedded URL parameter.

    2. For the prompt 2. Cache documents whose requests do not contain this session?, select either YES or NO:

      • Select YES to cache versions of documents that do not use the cookie or embedded URL parameter. This selection enables Oracle9iAS Web Cache to serve documents from the cache for Web browser requests without the session or personalized attribute information.

      • Select NO to not cache versions of documents that do not use the cookie or embedded URL parameter.

    3. If you answered YES to the prompts described in Steps 6a and 6b, for the prompt 3. Can the document whose request doesn't contain this attribute be derived from the document whose request does contain this attribute by using the default value of the attribute?, select either YES or NO:

      • Select YES to cache one version of the document. For those requests without a cookie or embedded URL parameter, a default value is used.

      • Select NO to cache two different versions of the document. Oracle9iAS Web Cache serves one version to those requests that support the cookie or the embedded parameter and serves the other version to those requests that do not support the cookie or embedded parameter.

  7. In the Add Session/Personalized Attribute Related Caching Rule dialog box, choose Submit.

  8. Associate the rule with URLs:

    1. In the Session/Personalized Attribute Related Caching Rules page, select the newly-created rule, and then choose Change Selector Association.

      The Change Policy-Selector Association dialog box appears.

    2. Select a selector from the right list, and then choose the Make Association button.

      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.

  9. Repeat Steps 3 through 8 for each rule.

  10. Apply changes and restart Oracle9iAS Web Cache:

    1. In the Oracle9iAS Web Cache Manager main window, choose Apply Changes.

    2. In the navigator pane, select Administration > Operations.

      The Operations page appears.

    3. In the Operations page, choose Restart to restart Oracle9iAS Web Cache.

Configuring Caching Rules for Popular Pages with Session Establishment

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:

  1. Create a blank page for the entry URL, such as "/", that redirects to the real entry page.

  2. Configure the origin server to create a session when the blank page is requested without a session cookie.

  3. Create a caching rule for the real entry page and the blank page, as described in "Configuring Caching 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.

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:

  1. Create a JavaScript that sets a session cookie when one does not exist.

  2. Add the JavaScript to each of the pages that require the session.

  3. Create caching rules for the JavaScript and the session pages, as described in "Configuring Caching Rules".


    Note:

    Using the JavaScript solution, it is not necessary to create a Session/Personalized Attribute Related Caching Rule for the pages requiring sessions.


Configuring Pages for Content Assembly and Partial Page Caching

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:

Enabling Partial Page Caching

To enable partial page caching:

  1. Configure the template page as follows:

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

    2. In the template page, use a Surrogate-Control response-header field in the HTTP response message. For example:

      Surrogate-Control: max-age=30+60, content="ORAESI/9.0.2"
      
      
    3. If the Surrogate-Control response-header field does not include all the caching attributes required for the template page, then create a caching rule for the page.

  2. Configure the fetchable fragments:

Using ESI for Simple Personalization

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 Personalized Attribute Definitions and Rules for Personalized Attributes".

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.

See Also:

Examples of ESI Usage

This section provides examples of ESI usage in the following topics:

Example Portal Site Implementation

Figure 7-8 shows a portal site response page, http://www.company.com/servlet/oportal?username=Mark, for a registered user named Mark.

Figure 7-8 Portal Site Page

Text description of cache7.gif follows
Text description of the illustration cache7.gif

This page is assembled by Oracle9iAS Web Cache. A template page configured with ESI markup tags for a personalized greeting, weather, stocks, promotion advertisement, news, and sports fragments is assembled based on Mark's preferences. For example, since 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, Oracle9iAS 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:

Portal Example Using inline Tags

This section describes how <esi:inline> tag fragmentation and assembly can drastically increase the value of dynamic content caching for pages with 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 <esi:inline> for fetchable fragments by setting the fetchable attribute to yes. See "ESI inline Tag" for further information about the fetchable attribute.


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.

Figure 7-9 shows portal.esi with <esi:inline> tags.

Figure 7-9 portal.esi with 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: 63F
    </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>
   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
  Bannon in call for calm as Gorgie faithfull gather to grill Robinson
  scotsman.com
  </TR>
</TABLE>
</esi:inline>


<esi:inline name="/Common_Fragment_5" >
...
</esi:inline>

Figure 7-10 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.

Figure 7-10 portal.esi Example with inline Tags: Personalized Greeting

<esi:inline name="/Common_Fragment_1" >
<!-- First common fragment -->
<HTML>
...
<!-- Personalized Greeting With ESI variable -->
  Welcome, $(QUERY_STRING{username})!
</esi:inline>

Figure 7-11 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.

Figure 7-11 portal.esi Example with inline Tags: Weather Forecast

<esi:inline name="/Weathers_San_Francisco" >
<!-- Personalized Weather Forecast -->
Weather Forecast for San Francisco
<TABLE>
  <TR>
    <TD> 
      Currently: 63F
    </TD>
  </TR>
</TABLE>
</esi:inline>

Figure 7-12 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.

Figure 7-12 portal.esi Example: My Stocks Fragment

<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>

Figure 7-13 shows the markup for referencing an advertisement in the Promotion section. promotionID is the based on the user's identification.

Figure 7-13 portal.esi Example with inline Tags: Promotion

<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 <esi:include> tag for real-time advertisements

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. Figure 7-14 shows the markup.

Figure 7-14 portal.esi Example with inline Tags: Latest News and Latest Sports News

<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
  Bannon in call for calm as Gorgie faithfull gather to grill Robinson
  scotsman.com
  </TR>
</TABLE>
</esi:inline>
Portal Example Using Include Tags

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.

Figure 7-15 shows portal.esi with <esi:include> tags.

Figure 7-15 portal.esi with 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>

Figure 7-16 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:

Figure 7-16 portal.esi Example: Custom Profile Environment Variable Setting

<!-- 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"/>

Figure 7-17 shows GetProfile, which provides access to the city, state, news, and sports environment variables.

Figure 7-17 portal.esi Example: GetProfile File with Environment Variables

<?xml version=1.0?>
<esi-environment esiversion="ORAESI/9.0.2">
  <city>San_Francisco</city>
  <state>CA</state>
  <news>finance</news>
  <sports>soccer</sports>
</esi-environment>

Figure 7-18 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. username is the registered user's name. This markup enables the personalized greeting to be included in the cacheable template page.

Figure 7-18 portal.esi Example with vars tag: Personalized Greeting

<esi:vars>Welcome, $(QUERY_STRING{username})!</esi:vars>

Figure 7-19 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.

Figure 7-19 portal.esi Example with include Tags: Weather Forecast

<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 Figure 7-20. 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.

Figure 7-20 portal.esi Example with include Tags: My Stocks Fragment

<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 Figure 7-21. It includes fragments for five stock quotes: IBM, ORCL, YHOO, SUNW, and PRSF.

Figure 7-21 portal.esi Example: PersonalizedStockSelection Fragment for Mark

<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 Figure 7-22. 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.

Figure 7-22 portal.esi Example: PersonalizedStockSelection Fragment for Scott

<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>

Figure 7-23 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, Oracle9iAS Web Cache is able to cache the template and integrate the dynamic advertisement into the template.

Figure 7-23 portal.esi Example with include Tags: Promotion

<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 Figure 7-24, the response to the included image fragment for the banner is not cacheable. When a user requests this page, Oracle9iAS 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.

Figure 7-24 portal.esi Example: Rotating Banner Output

<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 Figure 7-25, the next time the user reloads the page, Advert generates another banner for the request.

Figure 7-25 portal.esi Example: Rotating Banner Reload

<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, then a link to www.oracle.com appears in the banner's place.

Figure 7-26 shows the markup for Latest News and Latest Sports News:

Figure 7-26 portal.esi Example with include Tags: Latest News and Sports Sections

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 of Simple Personalization with Variable Expressions

As described in Step 6 of "Configuring Personalized Attribute Definitions and Rules for Personalized Attributes", 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 7-27. Its HTML code uses PL/SQL for an HTML form with a text box in it.

Figure 7-27 PL/SQL Code without Personalization

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 7-28 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.

Figure 7-28 PL/SQL Code with Personalization through ESI

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>'); 

Configuring Caching Attributes in Response Headers

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. This feature enables the application Web server to override the settings configured through the Oracle9iAS Web Cache Manager interface, as well as allowing other third-party caches to use Oracle9iAS Web Cache caching attributes. All except the following attributes described in "Configuring Caching Rules" 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,...

Table 7-5 describes the supported control directives.

Table 7-5  Control Directives for Surrogate-Control
Control Directive Description

content

Specify what kind of processing is required:

  • "ORAESI/9.0.2" to process ESI tags with Oracle proprietary additions for content assembly and partial page caching. "ORAESI/9.0.2" supports all the ESI tags provided by Oracle9iAS Web Cache in release 9.0.2.

  • "ESI/1.0" to process standard ESI tags for content assembly and partial page caching

  • "ESI-Inline/1.0" to process <esi:inline> tags

  • "webcache/1.0" to process the <!-- WEBCACHETAG--> and<!-- WEBCACHEEND--> tags for personalized attributes and session-encoded URLs

"ESI/1.0" and "ESI-Inline/1.0" are subsets of "ORAESI/9.0.2". In this release, you need to specify only "ORAESI/9.0.2" for ESI assembly or "webcache/1.0" for personalized attributes.

max-age

Specify to enable Oracle9iAS Web Cache to cache the document.

Specify the time, in seconds, to expire the document after it enters the cache. Optionally, specify the time, in seconds, to remove the document from the cache after the expiration time. Use the following format:

max-age=expiration_time [+ removal_time]

Usage notes:

  • The default removal time is 0 seconds

  • max-age=infinity specifies that the document never expires

no-store

Specify Oracle9iAS Web Cache not to cache the document.

no-store-remote

Specify to now allow other ESI-compliant caches, such as Akamaii EdgeSuite, to cache the document.

Specify to not allow other ESI-compliant caches, such as a third-party Content Delivery Network (CDN), to cache the document.

The no-store-remote directive has similar semantics to the no-store directive, except that it is only be honored by remote caches. Generally, this means those caches that are more than one or two hops from the application Web server, such as caches in a CDN.

This directive is especially useful if you want to cache changing content locally, where invalidation propagation is immediate, but not in a distributed network of upstream ESI processors, where invalidation may take several minutes.

vary

Specify the HTTP request headers or category cookies from which Oracle9iAS Web Cache will use to cache and identify multiple-version documents. Use the following format:

vary=headers(header header ...); cookies(cookie_name cookie_name ...)

Usage notes:

  • vary accepts any valid HTTP request header

  • Use one or more spaces between the header and cookie names, and use zero or more spaces between the parenthesis and semicolons

  • Specify headers before cookies

Usage Notes

Example Usage

In the following example, the Surrogate-Control response-header field specifies that the document is to expire 30 seconds after it enters the cache 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="ORAESI/9.0.2"

In the following example, the Surrogate-Control response-header field specifies that the document is not to be cached:

Surrogate-Control: no-store

In the following example, the Surrogate-Control response-header field specifies ESI processing. It also specifies that the document is a multiple-version document that uses HTTP request headers of Accept and MyCustomHeader and cookies of news and sports.

Surrogate-Control: content="ORAESI/9.0.2", vary=headers(Accept 
MyCustomHeader);cookies(news sports)

Go to previous page Go to next page
Oracle
Copyright © 2002 Oracle Corporation.

All Rights Reserved.
Go To Documentation Library
Home
Go To Product List
Solution Area
Go To Table Of Contents
Contents
Go To Index
Index