10
Troubleshooting Oracle9iAS Web Cache Configuration

This chapter describes common configuration problems and debugging techniques for resolving them.

This chapter contains these topics:

• Startup Failures

• Caching Rules

• Load on Oracle9iAS Web Cache Computer

• Diagnostic Information in the Server Response-Header Field or HTML Body

• Invalidation Time-outs

• Query String Invalidations

• Application Web Server Capacity

• Content-Length Request-Header Field

• HTTP 500 Response Status Codes

• Administrator Password in the Change Administration Password Dialog Box

• Browser-Specific Issues

Startup Failures

If Oracle9iAS Web Cache does not start, it can be because of the following problems:

• Port Conflicts

• Startup Failure from Oracle Enterprise Manager

• Cache Memory

• Privileged Ports

• Greater Than One Thousand Maximum Connections

• Wallet Cannot Be Opened

Port Conflicts

During configuration, you configure a listening port from which Oracle9iAS Web Cache receives browser requests. By default, the port is 7777 for HTTP requests and 4443 for HTTPS requests.

You also configure listening ports for administration, invalidation, and statistics monitoring requests. By default, the HTTP ports are 4000, 4001, and 4002, respectively. In addition to configuring listening ports for Oracle9iAS Web Cache, you also configure the advertised port number from which an origin server can receive Oracle9iAS Web Cache requests.

When you start Oracle9iAS Web Cache, a port conflict check is performed. If there is a port conflict, Oracle9iAS Web Cache will fail to start. Port conflicts are reported to the event log file, event_log. The event_log file is located in $ORACLE_HOME/webcache/logs on UNIX and in ORACLE_HOME\webcache\logs on Windows. The following shows an excerpt of event_log with port conflict event messages:

30/Nov/2001:11:04:42 -0800 -- Error: A failure occurred ( Address already in use
) when assigning a port ( domain: <NONE>, address: 0.0.0.0, port: 7777). Change
PORT attribute of the LISTEN element in the configuration file to a suitable
unused port.
30/Nov/2001:11:04:42 -0800 -- Error: Failed to start the server.
30/Nov/2001:11:04:42 -0800 -- Error: The server could not initialize
30/Nov/2001:11:04:42 -0800 -- Information: The server is exiting
30/Nov/2001:11:04:05 -0800 -- Warning: The admin server couldn't start the cache
server, running in admin-only mode.

Note that the last message will only appear when the admin server process is started for the first time.

To resolve port conflicts:

1. Use Oracle9iAS Web Cache Manager to resolve the port conflicts.

   Typically, Oracle9iAS Web Cache and the origin server ports are in conflict. Verify the port assigned to Oracle9iAS Web Cache in Listening Ports page (Cache-Specific Configuration > Listening Ports), and verify the host names and ports assigned to the origin servers in the Application Web Servers or Proxy Servers page (General Configuration > Application Web Servers or Proxy Servers).

   If there are multiple instances of Oracle9iAS Web Cache are running on a multihomed host with multiple IP addresses, a port conflict can occur. The IP address for the default HTTP and HTTPS ports is set to ANY. Upon startup, Oracle9iAS Web Cache attempts to bind the ports to all IP addresses. If a port conflict occurs, change ANY to a specific IP address in the Listening Ports page (Cache-Specific Configuration > Listening Ports).

2. Restart Oracle9iAS Web Cache.

   See Also: "Starting and Stopping Oracle9iAS Web Cache"

If the administration port is in conflict, then the admin server process will not start and Oracle9iAS Web Cache Manager will not be accessible. The event log will contain messages that resemble the following output:

30/Nov/2001:10:56:11 -0800 -- Error: A failure occurred ( Address already in use
) when assigning a port ( domain: <NONE>, address: 0.0.0.0, port: 4000 ). Change
PORT attribute of the LISTEN element in the configuration file to a suitable
unused port.
30/Nov/2001:10:56:11 -0800 -- Error: Failed to start the server.
30/Nov/2001:10:56:11 -0800 -- Error: The server could not initialize
30/Nov/2001:10:56:11 -0800 -- Information: The server is exiting

To resolve this port conflict, modify the webcache.xml file, an internal file that contains the configuration settings, and change the administration port number. The webcache.xml file is located in $ORACLE_HOME/webcache on UNIX and in ORACLE_HOME\webcache on Windows. The following shows an excerpt of the webcache.xml file with the line for the administration port shown in boldface:

<?xml version="1.0"?>
<!DOCTYPE CALYPSO SYSTEM "internal:///webcache.dtd">
<CALYPSO>
  <VERSION DTD_VERSION="2.0"/>
  <MULTIPORT>
    <LISTEN IPADDR="ANY" PORT="1100" PORTTYPE="NORM"/>
    <LISTEN IPADDR="ANY" PORT="4000" PORTTYPE="ADMINISTRATION"/>
    <LISTEN IPADDR="ANY" PORT="4003" PORTTYPE="INVALIDATION"/>
    <LISTEN IPADDR="ANY" PORT="4002" PORTTYPE="STATISTICS"/>
  </MULTIPORT>

Startup Failure from Oracle Enterprise Manager

If you do not configure Oracle9iAS Web Cache during installation and attempt to start it at a later time from Oracle Enterprise Manager, then Oracle Enterprise Manager may return the following error when there is a port conflict with another running Oracle9iAS Web Cache in a different Oracle home on the same computer.

oracle.sysman.emSDK.util.jdk.EMException: Throwable: The attempt to start or  
stop Web Cache failed.

To resolve this issue, perform the following steps to the Oracle9iAS Web Cache that was not configured during installation:

1. Modify the Oracle9iAS Web Cache listening ports in the Listening Ports page (Cache-Specific Configuration > Listening Ports) so they are not in conflict with the other Oracle9iAS Web Cache.

   See Also: "Task 3: Configure Oracle9iAS Web Cache with Listening Ports for Incoming Browser Requests"

2. Change the Oracle9iAS Web Cache listening port value in the targets.xml file located in $ORACLE_HOME/sysman/emd/targets.xml on UNIX or ORACLE_HOME\sysman\emd\targets.xml on Windows.

3. Modify the PORT directive in httpd.conf to the Oracle9iAS Web Cache port number.

   See Also: "Task 4: Provide Directives to Oracle HTTP Server"

Cache Memory

Oracle9iAS Web Cache preallocates a large memory pool for data storage. When Oracle9iAS Web Cache is started, the admin and the cache server processes require 200 MB of memory to start. If there is not enough physical or virtual memory for these processes, the cache server process fails to start and messages that resemble the following output are written to the event_log file:

30/Nov/2001:10:58:02 -0600 -- Error: Oracle Web Cache Cache failed to initialize
30/Nov/2001:10:58:02 -0600 -- Error: The server could not initialize
30/Nov/2001:10:58:02 -0600 -- Information: The server is exiting
30/Nov/2001:10:58:02 -0600 -- Warning: The admin server couldn't start the cache 
server, running in admin-only mode

To resolve this cache memory issue:

1. Allocate additional memory for the admin and the cache server processes to start.

2. Restart Oracle9iAS Web Cache.

   See Also: "Starting and Stopping Oracle9iAS Web Cache"

Privileged Ports

Port numbers less than 1024 are reserved for use by privileged processes on UNIX. If you want to configure Oracle9iAS Web Cache to listen on a port less than 1024, such as on port 80, then the webcachectl executable needs to run as root. In order to run as the root user, ensure that root.sh was run during installation. If root.sh was not run during installation, run it now from the $ORACLE_HOME directory.

If webcachectl cannot run as root, then the cache server process fails to start and messages that resemble the following output are written to the event_log file:

30/Nov/2001:23:06:51 +0000 -- Error: Unable to listen on port 80
30/Nov/2001:23:06:51 +0000 -- Error: Failed to start the server.
30/Nov/2001:23:06:51 +0000 -- Error: The server could not initialize
30/Nov/2001:23:06:51 +0000 -- Information: The server is exiting

Greater Than One Thousand Maximum Connections

If you need Oracle9iAS Web Cache to support more than 1,024 connections on UNIX, then the webcachectl executable needs to run as root. In order to run as the root user, ensure that root.sh was run during installation. If root.sh was not run during installation, run it now from the $ORACLE_HOME directory.

If webcachectl cannot run as root, then the cache server process fails to start and messages that resemble the following output are written to the event_log file:

30/Nov/2001:18:18:24 -0800 -- Error: Could not increase number of file/socket 
descriptors to 10220.

30/Nov/2001:18:18:24 -0800 -- Error: Failed to start the server.

See Also: "Connection Limit"

Wallet Cannot Be Opened

When Oracle9iAS Web Cache is unable to open a wallet, messages that resemble the following output are written to the event_log file:

30/Nov/2001:23:13:41 +0000 -- Information: SSLInitialize: Origin Server Wallet 
file /etc/ORACLE/WALLETS/janedoe/ewallet.p12 does not exist
30/Nov/2001:23:13:41 +0000 -- Information: SSLInitialize: Origin Server Wallet 
Autologin file /etc/ORACLE/WALLETS/janedoe/cwallet.sso
does not exist - Wallet does not appear to be autologin wallet
30/Nov/2001:23:13:41 +0000 -- Warning: Origin Server Wallet Failed to open at 
location /etc/ORACLE/WALLETS/janedoe NZERROR=28759
-- Opened wallet as user=janedoe. -- Please verify wallet location and Auto 
Login support enabled.
30/Nov/2001:23:13:41 +0000 -- Warning: SSLInitialize: Orgin Server Wallet did 
not open -- Operating without wallet for backend -- Only
Diffie-Hellman Anonymous Connections Supported to Origin Servers!
30/Nov/2001:23:13:41 +0000 -- Information: SSLInitialize: Wallet file 
/etc/ORACLE/WALLETS/janedoe/ewallet.p12 does not exist
30/Nov/2001:23:13:41 +0000 -- Information: SSLInitialize: Wallet Autologin file 
/etc/ORACLE/WALLETS/janedoe/cwallet.sso does not exist - Wallet does not appear 
to be autologin wallet
30/Nov/2001:23:13:41 +0000 -- Warning: Wallet Failed to open at location 
/etc/ORACLE/WALLETS/janedoe NZERROR=28759 -- Opened wallet as user=janedoe. -- 
Please verify wallet location and Auto Login support enabled.
30/Nov/2001:23:13:41 +0000 -- Error: The server could not initialize
30/Nov/2001:23:13:41 +0000 -- Information: The server is exiting

To resolve this error, perform the procedure that follows. At the end of each step, restart Oracle9iAS Web Cache with the webcachectl restart command, and recheck the event_log file for wallet errors.

1. Follow the "Enabling Wallets to Open on Windows" to ensure that the wallet can be opened at startup.

2. Ensure that the wallet directory exists:
   • /etc/ORACLE/WALLETS/user_name on UNIX

   • %USERPROFILE%\ORACLE\WALLETS on Windows NT and Windows 2000

3. Ensure that wallet files cwallet.sso and ewallet.der exist.

   If these files do not exist, then an auto-login wallet does not exist. In this case, create the wallet.

   See Also: "Task 1: Create Wallets"

   If these files do exist, then the wallet user may not match the Oracle9iAS Web Cache user. Continue to Step 4.

4. Change the owner of the wallet to the user ID and group ID specified in the Process Identity page (Cache-Specific Configuration > Process Identity) of the Oracle9iAS Web Cache Manager.

   See Also: "Task 2: Modify Security Settings"

5. Confirm that the wallet was not copied from one computer to another.

   See Also: "Task 2: Modify Security Settings" for instructions on setting the user ID of the Oracle9iAS Web Cache executables "Task 1: Create Wallets" for instructions on creating the wallet

6. Ensure that Oracle Wallet Manager can open the wallet.

   If Oracle Wallet Manager cannot open the wallet, then the wallet is corrupt. In this case, re-create the wallet.

   See Also: "Task 1: Create Wallets"

Caching Rules

To diagnose if caching rules are serving wrong or older content:

1. Analyze the content of the event_log file and the access_log file in $ORACLE_HOME/webcache/logs on UNIX and in ORACLE_HOME\webcache\logs on Windows.

   If verbose logging is turned on in the event log, then error messages about the caching rules are reported.

   See Also: "Configuring Event Logs" for further information about turning on verbose logging

2. Determine the contents of the cache by:
   • Listing the most popular objects in the cache, along with the caching rules associated with the documents

   • Listing the contents of the cache

   • Previewing invalidation without invalidating actual content

     See Also: "Listing Popular Documents" to generate a list of the URLs of the most popular documents stored in the cache since the cache was last started "Listing All Contents" to generate a list of the URLs of the objects currently in the cache Step 5 in "Manual Invalidation Using Oracle9iAS Web Cache Manager" or "Invalidation Preview Request Syntax" to preview invalidation

3. Compare the contents of the cache to the caching rules in the Cacheability Rules page (General Configuration > Cacheability Rules) in Oracle9iAS Web Cache to determine discrepancies.

4. Adjust caching rules by adding or removing rules, adjusting regular expression syntax, or changing the precedence of rules.

   See Also: Chapter 7, "Creating Caching Rules"

Load on Oracle9iAS Web Cache Computer

On UNIX operating systems, the top and uptime utilities report a higher than expected average load when the Oracle9iAS Web Cache computer is idle. This occurs because Oracle9iAS Web Cache performs light maintenance work, even when it is idle. During idle mode, the following effect occurs:

• The uptime load--the average kernel scheduler queue length--is going to be longer. Oracle9iAS Web Cache increases the average queue length (uptime output) by approximately one.

• The CPU load is still low because the work Oracle9iAS Web Cache performs is minimal.

Diagnostic Information in the Server Response-Header Field or HTML Body

By default, Oracle9iAS Web Cache adds diagnostics information to the Server-response header field:

Server: Oracle9iAS/9.0.2 Oracle HTTP Server/version Oracle9iAS-Web-Cache/9.0.2 (diagnostic_information)

For diagnostics purposes, it can be useful to also display this information in the HTML response body of a document.

See Also: "Server Response-Header Field" for an overview of the Server response-header field

To configure diagnostic information to display in the HTML response body:

1. Use a text editor to open the webcache.xml file.

2. Locate the DEBUGINFO HEADER attribute in the SECURITY element:

   <?xml version="1.0"?>
   <!DOCTYPE CALYPSO SYSTEM "internal:///webcache.dtd">
   <CALYPSO>
   <VERSION DTD_VERSION="2.0.4"/>
   ...
     <SECURITY>
       <USER .../>
       <USER .../>
       <SECURESUBNET ...>
       </SECURESUBNET>
       <DEBUGINFO HEADER="YES" BODY="NO"/>
     </SECURITY>      
   ...
   
   

3. Change the value of the BODY attribute from NO to YES.

4. Restart Oracle9iAS Web Cache with the webcachectl restart command.

5. Append the string +wcdebug to the URL of the document into the browser to see the diagnostic information string embedded in the response body.

Note the following limitations when appending the string +wcdebug to the URL of the document to see the diagnostic information string embedded in the response body:

• In a cache cluster, if a cache member receives a request with +wcdebug for a content owned by another cache member, the page with debug information may be stored in the cache as an on-demand cached page. During a subsequent request for the same page without +wcdebug, you will retrieve the on-demand cached page with the debug information.

• Appending debug information to compressed pages causes an error in the browser. If you access the page with telnet, you will see the debug information prepended to the compressed page.

If you do not want users viewing the Oracle9iAS Web Cache diagnostic information in the Server-response header field, modify the webcache.xml file to disable it.

To disable the display of the diagnostic information:

1. Use a text editor to open the webcache.xml file.

2. Locate the DEBUGINFO HEADER attribute in the SECURITY element:

   <?xml version="1.0"?>
   <!DOCTYPE CALYPSO SYSTEM "internal:///webcache.dtd">
   <CALYPSO>
   <VERSION DTD_VERSION="2.0.4"/>
   ...
     <SECURITY>
       <USER .../>
       <USER .../>
       <SECURESUBNET ...>
       </SECURESUBNET>
       <DEBUGINFO HEADER="YES" BODY="NO"/>
     </SECURITY>      
   ...
   
   

3. Change the value of the HEADER attribute from YES to NO.

4. Ensure that the value of the BODY attribute is NO.

5. Restart Oracle9iAS Web Cache with the webcachectl restart command.

Invalidation Time-outs

The invalidation feature has a default time-out of 300 seconds for the propagation of invalidation requests in the cache hierarchy or cache cluster deployments.

See Also: "Invalidation Propagation" for an overview of invalidation propagation

When the time-out is exceeded in a cache hierarchy, a message that resembles the following output is written to the event_log file of the remote cache or subscriber cache:

22/Apr/2002:18:34:55 -0700 -- Information: <Invalidation>Invalidation sent 
upstream to webcache host '130.35.45.41' port '22002' has returned with response 
code: 'failed-no response code'.

To resolve this error:

1. On the central or provider cache, use a text editor to open the webcache.xml file.

2. Locate the CALYPSONETINFO element:

   <CALYPSONETINFO...INV_PEER_TIMEOUT="300"
                   INV_GLOBAL_TIMEOUT="300".../>
   
   

3. Modify the value of the INV_GLOBAL_TIMEOUT attribute to a larger value.

   The higher the value, the more system resources that will be used. If the network is fast, only increase the value to what is needed.

4. Restart Oracle9iAS Web Cache with the webcachectl restart command.

When the time-out is exceeded in a cache cluster, a message that resembles the following output is displayed in the Cache Cleanup Results dialog box or in the response to the invalidation request:

Can't connect to the web cache's invalidation listening port.

1. On cache cluster members, use a text editor to open the webcache.xml file.

2. Locate the CALYPSONETINFO element:

   <CALYPSONETINFO...INV_PEER_TIMEOUT="300"
                   INV_GLOBAL_TIMEOUT="300".../>
   
   

3. Modify the value of INV_PEER_TIMEOUT attribute.

   In a cache cluster, it is likely that cache cluster members are running in a LAN environment. Therefore, decreasing the value of INV_PEER_TIMEOUT will typically improve efficiency.

4. Restart Oracle9iAS Web Cache with the webcachectl restart command.

Query String Invalidations

If you are using the QUERYSTRING_PARMETER parameter in an invalidation request, it can take additional processing time Oracle9iAS Web Cache to match and invalidate the documents.

To optimize the invalidation process for query string invalidations:

1. Use a text editor to open the webcache.xml file.

2. Locate the SECURITY and WATCHDOG elements:

   <?xml version="1.0"?>
   <!DOCTYPE CALYPSO SYSTEM "internal:///webcache.dtd">
   <CALYPSO>
   <VERSION DTD_VERSION="2.0.4"/>
   ...
     <SECURITY>
       <USER .../>
       <USER .../>
       <SECURESUBNET ...>
       </SECURESUBNET>
       <DEBUGINFO HEADER="YES" BODY="NO"/>
     </SECURITY>      
   
     <WATCHDOG ENABLE="YES"/>
   ...
   
   

3. Between the SECURITY and WATCHDOG elements, add an INVALIDATIONINDEX element in the following format:

     <SECURITY>
     ...
     </SECURITY>
   
     <INVALIDATIONINDEX>
      <INDEXPARAM VALUE="VALUE_of_QUERYSTRING_PARAMETER"/>
      <INDEXPARAM VALUE="VALUE_of_QUERYSTRING_PARAMETER"/>
     </INVALIDATIONINDEX>
   
     <WATCHDOG ENABLE="YES|NO"/>
   
   

4. Restart Oracle9iAS Web Cache with the webcachectl restart command.

The following example request invalidates all documents under /corporate/asp/ matching the substring /view_building.asp and the embedded URL parameter value pairs of building=8 and floor=10. In addition, the request provides the comment "remove-view-building8-10th-floor" to be included in the invalidation result and event log.

<?xml version="1.0"?>
<!DOCTYPE INVALIDATION SYSTEM "internal:///WCSinvalidation.dtd">
<INVALIDATION VERSION="WCS-1.1">
  <OBJECT>
    <ADVANCEDSELECTOR URIPREFIX="/corporate/asp/"
                      HOST="www.company.com:80">
      <OTHER NAME="URI" TYPE="SUBSTRING" VALUE="/view_building.asp"/>
      <OTHER NAME="QUERYSTRING_PARAMETER" TYPE="SUBSTRING" VALUE="building=8"/>
      <OTHER NAME="QUERYSTRING_PARAMETER" TYPE="SUBSTRING" VALUE="floor=10"/>
    </ADVANCEDSELECTOR>
    <ACTION REMOVALTTL="0" />
    <INFO VALUE="remove-view-building8-10th-floor"/>
  </OBJECT>
</INVALIDATION>

To optimize this search, update webcache.xml file with the following:

<?xml version="1.0"?>
<!DOCTYPE CALYPSO SYSTEM "internal:///webcache.dtd">
<CALYPSO>
<VERSION DTD_VERSION="2.0.4"/>
...
  <SECURITY>
    <USER TYPE="INVALIDATION" PASSWORDHASH="48690"/>
    <USER TYPE="MONITORING" PASSWORDHASH="48690"/>
    <SECURESUBNET ALLOW="ALL">
      <IP ADDR="1.2.3.4900000"/>
      <IP ADDR="5.6.7.8.9999"/>
    </SECURESUBNET>
  </SECURITY>      

  <INVALIDATIONINDEX>
    <INDEXPARAM VALUE="building"/>
    <INDEXPARAM VALUE="floor"/>
  </INVALIDATIONINDEX>

  <WATCHDOG ENABLE="YES"/>
...

See Also: Table 8-1, " INVALIDATION Elements and Attributes" for a description of the invalidation request syntax "Example: Invalidating Documents Using Substring and Query String Matching"

Application Web Server Capacity

If an application Web server has reached capacity, then the following error message appears when accessing pages of a Web site:

The application Web server is busy. Possible reach capacity.

This error indicates that the application Web server has reached capacity--that is, the number of concurrent connections has been exceeded. To resolve this problem, you can either:

• Increase capacity

  In the Resource Limits page (Cache-Specific Configuration > Resource Limits) of Oracle9iAS Web Cache Manager, check the value of the Maximum Incoming Connections field. This field provides the currently configured capacity. If the capacity can be adjusted, increase it.

  See Also: "Task 9: Specify Settings for Origin Servers"

• Evaluate the caching rules to determine if additional content can be cached

  See Also: Chapter 7, "Creating Caching Rules"

Content-Length Request-Header Field

If the application Web server sets the Content-Length request-header field to some number of bytes, then Oracle9iAS Web Cache, which is configured by default for a five second connection time-out, keeps the connection open until the browser has received the bytes or the connection times out.

If the actual length of the page is less than the Content-Length, then the browser expects more data to arrive and the connection will eventually time out. If the actual length of the page is greater than the Content-Length, then the browser will not receive the complete page. This problem does not occur for cache hits because Oracle9iAS Web Cache correctly calculates the Content-Length itself when inserting pages into the cache repository. For cache misses, there are two workarounds for the improper Content-Length problem:

• Fix your application to ensure that Content-Length is correctly reported

• Configure the browser or client emulator to send HTTP/1.0 requests without the Keep-Alive request-header field

Because many servers are not configured to send the Keep-Alive request-header field, they disconnect after sending the last byte of data. Therefore, you may not see this issue when querying the application Web server directly from a client emulation tool or browser. Without the Keep-Alive request-header field, most browsers disregard the discrepancies between Content-Length and the actual data received.

HTTP 500 Response Status Codes

Oracle9iAS Web Cache does not cache pages that generate HTTP 500 response status codes. However, if an application reports an exception and does not send the error code, then the exception may be cached by Oracle9iAS Web Cache.

When you are developing a servlet and JSP and want to cache the content of the servlet and JSP, ensure that you send an non-200 HTTP error code in the runtime exception handling code. Otherwise, if the document has a cacheability rule associated with it, then Oracle9iAS Web Cache caches the document with the exception until the document is invalidated.

If you are using OracleJSP on Jserv as your JSP engine and servlet engine, then OracleJSP will generate HTTP 200 status code exceptions when a JSP file is not found or there is a compilation error in a JSP file. This is mainly for ease of debugging of JSP development in a JServ environment.

To enable OracleJSP on Jserv to generate an HTTP 404 Not Found or 500 response status codes rather than HTTP 200 status codes, set send_error to true and unsafe_reload to true in zone.properties. zone in your Jserv deployment environment.zone.roperties is located in $ORACLE_HOME/Apache/Jserv/etc on UNIX or ORACLE_HOME\Apache\Jserv\etc on Windows.

When using OracleJSP on OC4J, it is not necessary to establish these settings. OC4J always sends 500 status codes when it encounters a compilation error.

See Also: http://www.ietf.org/rfc/rfc2616.txt for further information about HTTP status codes Oracle HTTP Server Administration Guide for further information about Jserv

Administrator Password in the Change Administration Password Dialog Box

If you change the administrator password in the Change Administration Password dialog box (General Configuration > Security) without using the webcachectl restart command, and attempt to re-change the password again, the following error appears:

Incorrect old password.

The resolve this problem, remove the .webcache_tmp*.* file in $ORACLE_HOME/webcache on UNIX and ORACLE_HOME\webcache on Windows.

Changes to the administrator password made in the Change Administration Password dialog box are saved initially to a temporary version of the webcache.xml file named .webcache_tmp*.*. This file is stored in $ORACLE_HOME/webcache on UNIX and ORACLE_HOME\webcache on Windows. Until the new password is committed to the webcache.xml file with the webcachectl restart command, Oracle9iAS Web Cache Manager uses the configuration changes that were in process by using the temporary file. As a result, the Change Administration Password dialog uses the password in the temporary file for the current password.

Browser-Specific Issues

Table 10-1 describes browser limitations and their impact on Oracle9iAS Web Cache.

Table 10-1  Browser Issues

Problem	Description
Compressing JavaScript Files	Problem Description: Compressed JavaScript files cause some Netscape browsers to behave erratically and possibly fail. This issue only effects files that are referenced with the src attribute of the script tag; it does not include files that contain inline JavaScripts. Known browsers effected: Netscape 4.x Example: <script language="JavaScript" src="copyright.js"></script> If copyright.js is compressed for Netscape, then the browser may fail. Workaround: By default, compression is turned off for included JavaScript files. View the Cacheability Rules page to see this setting (General Configuration > Cacheability Rules).
Compressing Documents with Content-Disposition Response-Header Fields	Problem Description: Documents with Content-Disposition response-header fields show incorrect file names when they are compressed. Known browsers effected: Internet Explorer 5.0, 5.5, and 6.0 Example: Response headers for URL /reportgen include to following: Content-Type: application/excel Content-Disposition: attachment; filename="file.csv" When the document is not compressed, a Save As dialog appears with file.csv as the default filename. However, if it is compressed, reportgen appears as the default name. Without the correct extension, the file will not open correctly on Windows operating systems. Workaround: Even if compression is selected, Oracle9iAS Web Cache does not compress documents containing a Content-Disposition response-header field.
Decompressing Documents with Content-Disposition Response-Header Fields	Description: Documents with Content-Disposition response-header fields are not decompressed when you choose File > Save As from Netscape browsers. Known browsers effected: Netscape 4.x Workaround: Even if compression is selected, Oracle9iAS Web Cache does not compress documents containing a Content-Disposition response-header field.
Compressing Style Sheets	Description: Compressed style sheets can cause background attributes, such as background images, to not appear in the output. Known browsers effected: Internet Explorer 6.0 Workaround: Disable compression for style sheets in the Cacheability Rules page (General Configuration > Cacheability Rules).
Keep-Alive	Problem Description: For HTTPS requests, Internet Explorer 5.5 may send requests after Oracle9iAS Web Cache has already tried to close the connection. Known browsers effected: Internet Explorer 5.5 Workaround: Disable keep-alive by setting Keep-Alive to 0 in the Network Timeouts page (Cache-Specific Configuration > Network Timeouts) of the Oracle9iAS Web Cache Manager. This closes the connection between Oracle9iAS Web Cache and the browser after the browser returns a response.