D Caching with Third-Party Application Web Servers

This appendix discusses how to configure OracleAS Web Cache with third-party application Web servers.

This appendix contains these topics:

Overview of Third-Party Application Servers
BEA WebLogic Server 9.0
IBM WebSphere Application Server, Version 6.0
Apache Tomcat, Version 4.1

Notes:

While this appendix describes how OracleAS Web Cache works with four specific kinds of servers, OracleAS Web Cache works with any HTTP-compliant application Web server.
The application examples used in the discussions of these third-party servers are relatively simple. Running with production applications will require more extensive configuration of OracleAS Web Cache. Refer to the third-party application Web server documentation for information about designing applications.

Overview of Third-Party Application Servers

Because OracleAS Web Cache is transparent to the application Web server, the application Web server treats HTTP requests from OracleAS Web Cache as any other HTTP request coming directly from the browser. In turn, the application Web server generates the response and sends it back to OracleAS Web Cache as an HTTP message.

Because OracleAS Web Cache fully supports HTTP, it can work with any HTTP-compliant application Web server. How the application Web servers choose to generate HTTP responses is irrelevant to OracleAS Web Cache.

The type of application Web server that a site uses depends mainly on the types of applications that site is running. For example, if customers want to run Active Server Pages (ASP), then they may prefer to use Microsoft Internet Information Server (IIS) as the application Web server.

This section contains these topics:

Web Site Configuration
Caching Rules and Expiration Rules

Web Site Configuration

You configure OracleAS Web Cache to communicate with a third-party application Web server the same way you do with Oracle HTTP Server, by providing the host name and the listening port number. Table D-1 shows the default values for the listening ports for the products discussed in this appendix.

Table D-1 Third-Party Application Web Server Default Listening Ports

Application Web Server	Port
BEA WebLogic Server 9.0	7001
IBM WebSphere Application Server, Version 6.0	80
Apache Tomcat, Version 4.1	8080
Microsoft IIS 6.0	80

To configure OracleAS Web Cache to communicate with a third-party application Web server, perform the following tasks:

"Task 6: Configure OracleAS Web Cache with Listening Ports for Client Requests" to change OracleAS Web Cache port settings
"Task 9: Configure Origin Server, Load Balancing, and Failover Settings" to configure application Web server settings
"Task 10: Configure Web Site Settings" to configure Web site settings

Caching Rules and Expiration Rules

You assign caching rules and expiration rules when using third-party application Web servers in the same way as when using Oracle HTTP Server. You can choose to cache or not to cache content for the following:

Static objects
Multiple-version objects for the same URL
Pages supporting a session cookie or embedded URL parameter
Pages containing simple personalization
Dynamic assembly of Edge Side Includes (ESI) fragments

You can also assign an expiration time limit to objects or invalidate objects at any time.

BEA WebLogic Server 9.0

The WebLogic Server installation includes a number of Java Server Pages (JSP), Java servlets, and Enterprise JavaBeans (EJB) examples. This section explains how to configure OracleAS Web Cache to cache the JSP - Simple Tag application.

WebLogic SimpleTag JSP

You can use SimpleTag.jsp to demonstrate how OracleAS Web Cache caches full-page dynamic content.

To cache SimpleTag.jsp:

Ensure that OracleAS Web Cache has been configured to communicate with the WebLogic Application Server, as described in "Web Site Configuration".
Start the WebLogic Server, and then access the sample applications page with the following URL:
```
http://hostname:7001/examplesWebApp/index.jsp
```
Run the JSP - Simple Tags sample application. Access the following URL:
```
http://hostname:7001/jsp_simpleTag/SimpleTag.jsp
```
The sample JSP application displays in the browser window with the BEA icon and a table fetched from the database.
Create a caching rule for the JSP - Simple Tag output, as described in "Configuring Caching Rules and Rule Association".

When creating the caching rule, configure the following in the Edit/Add Caching, Personalization, and Compression Rule dialog box:
1. In the URL Expression field, enter /jsp_simpleTag/SimpleTag.jsp.
2. In the HTTP Method(s) section, click GET.
3. In the Caching Policy section, click Cache.
4. Leave all other defaults in the Edit/Add Caching, Personalization, and Compression Rule dialog box as is.

Point the browser to OracleAS Web Cache with following URL:

http://web_cache_hostname:7777/jsp_simpleTag/SimpleTag.jsp

The output is the same as it was when you accessed SimpleTag.jsp directly from the WebLogic Server. This time, OracleAS Web Cache caches the SimpleTag.jsp output and serves the request to the browser.

Note:

Port 7777 is the default listening port for OracleAS Web Cache. If you changed the default listening port, use that port number. Check the Ports page of Application Server Control Console (Web Cache Home page > Administration tab > Properties > Web Cache > Ports) or the Listen Ports page in OracleAS Web Cache Manager (Ports > Listen Ports) to determine the correct port for your configuration.

View the contents of the cache, as described in "Listing Popular Requests and Cache Contents", to ensure that SimpleTag.jsp is cached.

From this point on, anytime a browser accesses SimpleTag.jsp, the response will be served from OracleAS Web Cache.

SimpleTag.jsp provides a simple example of an HTTP servlet that uses the HttpSession class to track the number of times that a browser has visited the JSP. Use it to demonstrate how OracleAS Web Cache caches pages with session-encoded URLs.

To cache SimpleTag.jsp for session-encoded URLs:

Configure the browser not to accept cookies.

This is required in order to use session-encoded URLs in this example.
Start the WebLogic Server, and then access the sample applications page with the following URL:
```
http://hostname:7001/examplesWebApp/index.jsp
```
Run the JSP - Simple Tags sample application. Access the following URL:
```
http://hostname:7001/jsp_simpleTag/SimpleTag.jsp
```
The sample JSP application displays in the browser window with the BEA icon and a table fetched from the database.
Create an expiration rule, as described in "Configuring Expiration Policies".

In the Create Expiration Policy dialog box, perform the following steps:
1. In the Expire section, specify that the output expire 60 seconds after cache entry.
2. In the After Expiration section, select Remove immediately.
Create a session-caching policy, as described in "Configuring Session or Personalized Attribute Caching Policies".

When configuring a session-caching policy for SimpleTag.jsp, perform the following steps:
1. In the Edit/Add Session Definition dialog box:
  - In the Session Name field, enter BEASession.
  - In the Cookie Name field, enter JSESSIONID.
    
    JSESSIONID is the default cookie name used by the WebLogic Server.
  - In the URL or POST body parameter field, enter jsessionid.
2. In the Add Session Caching Policy dialog box:
  - From the Please select a session list, select BEASession.
  - Select YES for prompt 1.
  - Select YES for prompt 2.
  - Select NO for prompt 3.
3. Modify the caching rule for SimpleTag.jsp.
  
  In Session Caching Policies section of the Edit/Add Caching, Personalization, and Compression Rule dialog box, select BEASession, Cache with session, and Cache without session.
Point the browser to OracleAS Web Cache with the following URL:
```
http://web_cache_hostname:7777/jsp_simpleTag/SimpleTag.jsp
```
When the page is refreshed or reloaded, OracleAS Web Cache serves the content, and the request never goes to the WebLogic Server.
View the contents of the cache, as described in "Listing Popular Requests and Cache Contents", to ensure that SimpleTag.jsp is cached.

IBM WebSphere Application Server, Version 6.0

When OracleAS Web Cache fetches static content from IBM Websphere Application server, the IBM Websphere Application Server sends a content="ESI/1.0+" directive in the Surrogate-Control response header in the response to the OracleAS Web Cache Surrogate-Capability: orcl="ESI/1.0" request. If OracleAS Web Cache is deployed as a caching solution, this difference in the control directive value may result in undefined Web application behavior.

To resolve this problem:

In the WebSphere Application Server administrative console, navigate to Servers > Application servers.

The Application servers page appears.
In the Application servers page appears, select the server1 application server.

server1 is the server name when IBM Websphere Application Server is installed with default options. If you specified a different name, select that name instead.
In the Server Infrastructure section of the Configuration tab, select Java and Process Management, and then Process Definition.
In the Additional Properties section, select Java Virtual Machine, and then Custom Properties.
Click New to create a new entry.
In the Name field, enter com.ibm.servlet.file.esi.control.
In the Value field, enter max-age=300, cacheid="URL", content="ESI/1.0".
Click Apply, then save and restart WebSphere Application Server.

The WebSphere Application Server installation includes a number of JSP, Java servlets, and EJB examples. This section explains how to configure OracleAS Web Cache to cache the following content:

WebSphere Snoop Servlet
WebSphere Calendar Creator JSP

WebSphere Snoop Servlet

The snoop servlet shows getting and using request information, headers, and parameters sent by the browser. Use it to demonstrate how OracleAS Web Cache caches full-page dynamic content.

To cache the snoop servlet:

Ensure that OracleAS Web Cache has been configured to communicate with the WebSphere Application Server, as described in "Web Site Configuration".
Start the WebSphere Application Server, and then access the following URL:
```
http://hostname/snoop
```
Notice that request information, headers, and parameters sent by your browser display.
Create a caching rule for the snoop output, as described in "Configuring Caching Rules and Rule Association".

When creating the caching rule for the snoop output, configure the following in the Edit/Add Caching, Personalization, and Compression Rule dialog box:
1. In the URL Expression field, enter /snoop.
2. In the HTTP Method(s) section, click GET.
3. In the Caching Policy section, click Cache.
4. Leave all other defaults in the Edit/Add Caching, Personalization, and Compression Rule dialog box as is.

Point the browser to OracleAS Web Cache with following URL:

http://web_cache_hostname:7777/snoop

The output is the same as it was when you accessed snoop directly from the WebSphere Application Server. This time, OracleAS Web Cache caches the snoop output and serves the response to the browser.

Note:

View the contents of the cache, as described in "Listing Popular Requests and Cache Contents", to ensure that snoop is cached.

When you reload the page, you should notice that the cached response appears faster than when you access the WebSphere Application Server directly.

WebSphere Calendar Creator JSP

The Calendar JSP generates a calendar based on user input. The example is not a pre-deployed WebSphere example like the snoop servlet. To find this example, you need to install Technology Samples, as mentioned in the documentation under IBM WebSphere Application Server samples gallery. Use this JSP to demonstrate how OracleAS Web Cache caches pages with session cookies.

To cache SimpleTag.jsp for session-encoded URLs:

Start the WebSphere Application Server, set the browser to accept cookies, and then access the following URL:
```
http://hostname/TechnologySamples/Calendar
```
Notice that the page displays a form asking for inputs on month, year, and other preferences to create a calendar. To use the application:
1. Enter some values, and then click Continue.
2. Enter some values in the Day and Memo fields, and then click Add Memo.
3. Click Generate Calendar.
Create an expiration rule, as described in "Configuring Expiration Policies".

In the Create Expiration Policy dialog box, perform the following steps:
1. In the Expire section, specify that the output expire 60 seconds after cache entry.
2. In the After Expiration section, select Remove immediately.
Create a session-caching policy, as described in "Configuring Session or Personalized Attribute Caching Policies".

When configuring a session-caching policy, perform the following steps:
1. In the Edit/Add Session Definition dialog box:
  - In the Session Name field, enter IBMSession.
  - In the Cookie Name field, enter JSESSIONID.
    
    JSESSIONID is the default cookie name used by the WebSphere Application Server.
  - In the URL or Post body parameter field, enter jsessionid.
2. In the Add Session Caching Policy dialog box:
  - From the Please select a session list, select IBMSession.
  - Select YES for prompt 1.
  - Select YES for prompt 2.
  - Select NO for prompt 3.
3. Create a new caching rule for Calendar, as described in "Configuring Caching Rules and Rule Association".
  
  When creating the caching rule for the Calendar output, configure the following in the Edit/Add Caching, Personalization, and Compression Rule dialog box:
  - In the URL Expression field, enter /TechnologySamples/Calendar.
  - In the HTTP Method(s) section, click GET.
  - In the Caching Policy section, click Cache.
  - From the Expiration Policy list, select Expire: 60 seconds in cache. After: remove immediately.
  - In the Session Caching Policies section, select IBMSession, Cache with session, and Cache without session.
  - Leave all other defaults in the Edit/Add Caching, Personalization, and Compression Rule dialog box as is.

Point the browser to OracleAS Web Cache with the following URL:

http://web_cache_hostname:7777/TechnologySamples/Calendar

The output is the same as when you access Calendar directly from WebSphere Application Server. This time, OracleAS Web Cache caches the Calendar output.

Note:

View the contents of the cache, as described in "Listing Popular Requests and Cache Contents", to ensure that Calendar is cached.

When you reload the page, notice that the cached response appears faster than when you access the WebSphere server directly.

Because the expiration rule for this URL is set to 60 seconds, OracleAS Web Cache expires the cached content after 60 seconds and reflects the content the next time the user requests the page.

After deploying OracleAS Web Cache, if the browser displays a HTTP 404 Page not found error, perform the following steps:

In the WebSphere Server WAS_home/config/cells/plugin-cfg.xml file, add <VirtualHost Name="*:7777"/>.
In the WebSphere Application Server administrative console, navigate to Environment > Virtual Hosts.

Follow the prompts to add a new virtual host 7777.

Note:

Apache Tomcat, Version 4.1

Apache Tomcat, Version 4.1 is a servlet container. It is included with the Apache Jakarta Project. The Apache Tomcat installation includes a number of JSP and Java servlet examples. This section explains how to configure OracleAS Web Cache to cache the following content:

Apache Tomcat Snoop JSP
Apache Tomcat Session Servlet

Follow the instructions enclosed within the Apache Tomcat binary for installation. Apache Tomcat requires the Java Development Kit (JDK).

Apache Tomcat Snoop JSP

snoop.jsp shows getting and using request information, headers, and parameters sent by the browser. Use it to demonstrate how OracleAS Web Cache caches full-page dynamic content.

To start, perform the following steps:

Ensure that OracleAS Web Cache has been configured to communicate with the Apache Tomcat server, as described in "Web Site Configuration".
Start the Apache Tomcat server, and then access the following URL:
```
http://hostname/examples/jsp/snp/snoop.jsp
```
Notice that request information, headers, and parameters sent by your browser display.

To cache this content:

Create a caching rule for the snoop output, as described in "Configuring Caching Rules and Rule Association".

When creating the caching rule for the snoop output, configure the following in the Edit/Add Caching, Personalization, and Compression Rule dialog box:
1. In the URL Expression field, enter /examples/jsp/snp/snoop.jsp.
2. In the HTTP Method(s) section, click GET.
3. In the Caching Policy section, click Cache.
4. Leave all other defaults in the Edit/Add Caching, Personalization, and Compression Rule dialog box as is.

Point the browser to the OracleAS Web Cache with following URL:

http://web_cache_hostname:7777/examples/jsp/snp/snoop.jsp

The output is the same as it was when you accessed snoop directly from Apache Tomcat. This time, OracleAS Web Cache caches the snoop output and serves the response to the browser.

Note:

View the contents of the cache, as described in "Listing Popular Requests and Cache Contents", to ensure that snoop is cached.

When you reload the page, you should notice that the cached response appears faster than when you access Apache Tomcat directly.

Apache Tomcat Session Servlet

The SessionServlet provides a simple example of an HTTP servlet that uses the HttpSession class to track the number of times that a browser has visited the servlet. Use it to demonstrate how OracleAS Web Cache caches pages with session-encoded URLs.

This servlet may not be included in the Apache Tomcat binary. You can find this example on the Web, or you can use code for the servlet from Example D-1.

Example D-1 Apache Tomcat Binary

/*
 * @(#)SessionServlet.java     1.5 1.5
 * 
 * Copyright (c) 1996-1998 Sun Microsystems, Inc. All Rights Reserved.
 * 
 * This software is the confidential and proprietary information of Sun
 * Microsystems, Inc. ("Confidential Information").  You shall not
 * disclose such Confidential Information and shall use it only in
 * accordance with the terms of the license agreement you entered into
 * with Sun.
 * 
 * SUN MAKES NO REPRESENTATIONS OR WARRANTIES ABOUT THE SUITABILITY OF THE
 * SOFTWARE, EITHER EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE
 * IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR
 * PURPOSE, OR NON-INFRINGEMENT. SUN SHALL NOT BE LIABLE FOR ANY DAMAGES
 * SUFFERED BY LICENSEE AS A RESULT OF USING, MODIFYING OR DISTRIBUTING
 * THIS SOFTWARE OR ITS DERIVATIVES.
 * 
 * CopyrightVersion 1.0
 */

package sunexamples;

import java.io.*;
import java.util.Enumeration;

import javax.servlet.*;
import javax.servlet.http.*;


/**
 * This is a simple example of an HTTP Servlet that uses the HttpSession
 * class
 *
 * Note that in order to guarantee that session response headers are
 * set correctly, the session must be retrieved before any output is
 * sent to the client.
 */
public class SessionServlet extends HttpServlet { 

    public void doGet (HttpServletRequest req, HttpServletResponse res)
      throws ServletException, IOException
      {
        
       //Get the session object
       HttpSession session = req.getSession(true);
       
       //Get the output stream
       ServletOutputStream out = res.getOutputStream();
       
       res.setContentType("text/html");
       
       out.println("<HEAD><TITLE> SessionServlet Output " +
                "</TITLE></HEAD><BODY>");
       out.println("<h1> SessionServlet Output </h1>");

       //Here's the meat
       Integer ival = (Integer) session.getValue("sessiontest.counter");
       if (ival==null) ival = new Integer(1);
       else ival = new Integer(ival.intValue() + 1);
       session.putValue("sessiontest.counter", ival);

       out.println("You have hit this page <b>" + ival + "</b> times.<p>");

       // encodeURL Encodes the specified URL by including the session ID in it 
       // if cookies are not turned on or not supported by the browser
       out.println("Click <a href=" + res.encodeURL("/session.html") + 
                ">here</a>");
       out.println(" to ensure that session tracking is working even if" +
                " cookies aren't supported.<br>");
       out.println(" Note that by default URL rewriting is not enabled due" +
                " to it's expensive overhead.");
       out.println("<p>");
       
       out.println("<h3>Request and Session Data:</h3>");
       out.println("Session ID in Request: " + req.getRequestedSessionId());
       out.println("<br>Session ID in Request from Cookie: " + 
                         req.isRequestedSessionIdFromCookie());
       out.println("<br>Session ID in Request from URL: " + 
                         req.isRequestedSessionIdFromURL());
       out.println("<br>Valid Session ID: " + 
                         req.isRequestedSessionIdValid());
       out.println("<h3>Session Data:</h3>");
       out.println("New Session: " + session.isNew());
       out.println("<br>Session ID: " + session.getId());
       out.println("<br>Creation Time: " + session.getCreationTime());
       out.println("<br>Last Accessed Time: " + 
                              session.getLastAccessedTime());
       out.println("<br><a href=\"/examples/simple_servlets\">Up</a>");
       out.println("</BODY>");
       out.close();
      }
    
    public String getServletInfo() {
        return "A simple session servlet";
    }
}

To start, perform the following steps:

Compile the SessionServlet.java file in the Apache Tomcat environment.
Copy the SessionServlet.class to the /examples/servlets/ directory where other servlet examples may reside.
Ensure that OracleAS Web Cache has been configured to communicate with the Apache Tomcat, as described in "Web Site Configuration".
Configure the browser not to accept cookies.

This is required in order to use session-encoded URLs in this example.
Start Apache Tomcat and access the following URL:
```
http://hostname/examples/servlets/SessionServlet
```
Notice that the page displays how many times a browser has visited it. When you click the link labeled here, notice that the session ID is encoded in the URL. Every time you refresh or reload the page, the counter increases by one.

To cache the content:

Create an expiration rule, as described in "Configuring Expiration Policies".

In the Create Expiration Policy dialog box, perform the following steps:
1. In the Expire section, specify that the output expire 60 seconds after cache entry.
2. In the After Expiration section, select Remove immediately.
Create a session-caching policy, as described in "Configuring Session or Personalized Attribute Caching Policies".

When configuring a session-caching policy for the Session servlet, perform the following steps:
1. In the Edit/Add Session Definition dialog box:
  - In the Session Name field, enter ApacheSession.
  - In the Cookie Name field, enter JSESSION.
  - In the URL or Post body parameter field, enter jsessionid.
2. In the Add Session Caching Policy dialog box:
  - From the Please select a session list, select ApacheSession.
  - Select YES for prompt 1.
  - Select YES for prompt 2.
  - Select NO for prompt 3.
3. Create a new caching rule for SessionServlet, as described in "Configuring Caching Rules and Rule Association".
  
  When creating the caching rule for the Session servlet output, configure the following in the Edit/Add Caching, Personalization, and Compression Rule dialog box:
  - In the URL Expression field, enter /examples/servlets/SessionServlet.
  - In the HTTP Method(s) section, click GET.
  - In the Caching Policy section, click Cache.
  - From the Expiration Policy list, select Expire: 60 seconds in cache. After: remove immediately.
  - In the Session Caching Policies section, select ApacheSession, Cache with session, and Cache without session.
  - Leave all other defaults in the Edit/Add Caching, Personalization, and Compression Rule dialog box as is.

Point the browser to OracleAS Web Cache with the following URL:

http://web_cache_hostname:7777/examples/servlets/SessionServlet

The output is the same as it was when you accessed Session servlet directly from Apache Tomcat. This time OracleAS Web Cache caches the Session servlet output. When the page is refreshed or reloaded, notice that the counter does not increment by one. This is because OracleAS Web Cache serves the content, and the request never goes to the Apache Tomcat.

Note:

View the contents of the cache, as described in "Listing Popular Requests and Cache Contents" to ensure that Session servlet is cached.

When you reload the page, notice that the cached response appears faster than when you access the Apache Tomcat server directly.

Because the expiration rule for this URL is set to 60 seconds, OracleAS Web Cache expires the cached content after 60 seconds and reflects the content the next time the user requests the page.

Microsoft IIS 5.0

Note:

If you are using Microsoft ASP.NET and you feel the content is cacheable, use the following recommendations when configuring OracleAS Web Cache:

Create a caching rule to cache all .aspx objects.
Select an expiration policy based on the HTTP Expires header.
If a session-caching policy is required, use session ID ASP.NET_SessionId.

The Microsoft IIS installation includes a number of ASP examples. This section explains how to configure OracleAS Web Cache to cache the following content:

ServerVariables_Jscript ASP
Cookie_Jscript ASP

ServerVariables_Jscript ASP

ServerVariables_JScript.asp demonstrates techniques you can use to access server variable information from an ASP script. Use it to demonstrate how OracleAS Web Cache caches full-page dynamic content.

To start, perform the following steps:

Ensure that OracleAS Web Cache has been configured to communicate with IIS, as described "Web Site Configuration".
Start IIS, and then access the following URL:
```
http://hostname/IISSamples/sdk/asp/interaction/ServerVariables_JScript.asp
```
Notice that request information, headers, and parameters sent by the browser display.

To cache this content:

Create a caching rule for the ServerVariables_JScript.asp, as described in "Configuring Caching Rules and Rule Association", using the following information:
1. In the URL Expression field, enter the following:
```
/IISSamples/sdk/asp/interaction/ServerVariables_JScript.asp.
```
2. In the HTTP Method(s) section, click GET.
3. In the Caching Policy section, click Cache.
4. Leave all other defaults in the Edit/Add Caching, Personalization, and Compression Rule dialog box as is.
Point the browser to OracleAS Web Cache with following URL:
```
http://web_cache_hostname:7777/IISSamples/sdk/asp/interaction/ServerVariables_JScript.asp
```
The output is the same as it was when you accessed ServerVariables_JScript.asp directly from IIS. This time, OracleAS Web Cache caches the ServerVariables_JScript.asp output and serves the request to the browser.

Note:
Port 7777 is the default listening port for OracleAS Web Cache. If you changed the default listening port, use that port number.
View the contents of the cache, as described in "Listing Popular Requests and Cache Contents", to ensure that ServerVariables_JScript.asp is cached.

When you reload the page, you should notice that the cached response appears faster than when you access IIS directly.

Cookie_Jscript ASP

Cookie_JScript.asp illustrates how your script can set and read cookies by using the Response.Cookies collection. Use it to demonstrate how OracleAS Web Cache caches pages with session cookies.

To start, perform the following steps:

Ensure that OracleAS Web Cache has been configured to communicate with IIS, as described in "Web Site Configuration".
Start IIS, verify that your browser is set to accept cookies, and then access the following URL:
```
http://hostname/IISSamples/sdk/asp/interaction/Cookie_JScript.asp
```
When you access the URL, notice that the page displays the date and time you last visited this page. When you click "Revisit this page," the date and time is updated.

To cache this content:

Create an expiration rule, as described in "Configuring Expiration Policies".

In the Create Expiration Policy dialog box, perform the following steps:
1. In the Expire section, specify that the output expire 60 seconds after cache entry.
2. In the After Expiration section, select Remove immediately.
Create a session-caching policy for Cookie_Jscript.asp, as described in "Configuring Session or Personalized Attribute Caching Policies".

When configuring a session caching policy, perform the following steps:
1. In the Session Name field, enter MSSession.
2. In the Cookie Name field, enter CookieJSCript.
3. In the Add Session Caching Policy dialog box:
  - From the Please select a session list, select MSSession.
  - Select YES for prompt 1.
  - Select YES for prompt 2.
  - Select NO for prompt 3.
4. Create a new caching rule for Cookie_JScript.asp, as described in "Configuring Caching Rules and Rule Association".
5. When creating the caching rule for the Cookie_JScript.asp output, configure the following in the Edit/Add Caching, Personalization, and Compression dialog box:
  - In the URL Expression field, enter /IISSamples/sdk/asp/interaction/Cookie_JScript.asp.
  - In the HTTP Method(s) section, click GET.
  - In the Caching Policy section, click Cache.
  - From the Expiration Policy list, select Expire: 60 seconds in cache. After: remove immediately.
  - In the Session Caching Policies section, select MSSession, Cache with session, and Cache without session.
  - Leave all other defaults in the Edit/Add Caching, Personalization, and Compression Rule dialog box as is.
Point the browser to OracleAS Web Cache with the following URL:
```
http://web_cache_hostname:7777/IISSamples/sdk/asp/interaction/Cookie_JScript.asp
```
The output is the same as it was when you accessed Cookie_JScript.asp directly from IIS. This time, OracleAS Web Cache caches the Cookie_JScript.asp output. To verify that the cache serves the content, click "Revisit this page." Notice that the date and time are not updated. This is because OracleAS Web Cache serves the cached content, and the request never goes to IIS.

Note:
Port 7777 is the default listening port for OracleAS Web Cache. If you changed the default listening port, use that port number.
View the contents of the cache, as described in "Listing Popular Requests and Cache Contents", to ensure that Cookie_JScript.asp is cached.

When you reload the page, notice that the cached response appears faster than when you access IIS server directly.

Because the expiration rule for this URL is set to 60 seconds, OracleAS Web Cache expires the cached content after 60 seconds and reflects the content the next time the user requests the page.