|
Oracle9i Application Server Release Notes
Release 2 (9.0.3) for AIX-Based Systems, hp HP-UX PA-RISC (64-bit), hp Tru64 UNIX, and Linux x86 Part No. B10227-11 |
|
|
|
Oracle9i Application Server Release Notes
Release 2 (9.0.3) for AIX-Based Systems, hp HP-UX PA-RISC (64-bit), hp Tru64 UNIX, and Linux x86 Part No. B10227-11 |
|
|
|
This chapter discusses the following topics:
This section describes general issues and their workarounds for Oracle9iAS Web Cache. It contains the following subsections:
Oracle9iAS Web Cache uses 2 KB for the access log buffer size and the following memory for cached documents:
4 KB for the sum of all HTTP header fields
To change the default value, add the DOCHEADERBUFFERSIZE attribute with the new default size as its value to the <CACHE> element in the internal.xml file. For example:
<CACHE DOCHEADERBUFFERSIZE="20480"... />
3 KB for a single HTTP header field
To change the default value, add the MAXRESPONSEHEADERSIZE attribute with the new default size as its value to the <MISCELLANEOUS> element in the internal.xml file. For example:
<MISCELLANEOUS MAXRESPONSEHEADERSIZE="8192" ... />
32 KB for the HTTP response body
To change the default value, add the DOCBUFFERSIZE attribute with the new default size as its value to the <CACHE> element in the internal.xml file. For example:
<CACHE DOCBUFFERSIZE="65536"... />
If the HTTP response body is less than 4 KB, then Oracle9iAS Web Cache uses a 4 KB buffer size.
The internal.xml file is located in the ORACLE_HOME/webcache directory
Oracle9iAS Web Cache Manager does not enforce the same level of consistency checking upon receiving configuration input that Oracle9iAS Web Cache does upon starting up. Therefore, there may be instances where configuration changes are accepted by the Oracle9iAS Web Cache Manager, but Oracle9iAS Web Cache does not start up with the resulting configuration.
This is especially a problem when the admin server process is shut down (with the webcachectl stop or webcachectl stopadm command) after applying invalid configuration changes. In that case, the admin server process will not be able to start up, and the Oracle9iAS Web Cache Manager will become inaccessible.
To solve this problem:
If you want to retain the configuration changes you made, then send the webcache.xml file to Oracle Support Services to troubleshoot the invalid configuration entry. The webcache.xml file is located in the ORACLE_HOME/webcache directory
If you want to restore configuration to a previous configuration, then run the webcachectl reset command to restore to the previous version of the configuration. webcachectl is located in the ORACLE_HOME/webcache/bin directory.
|
Note: This limitation applies to Oracle Application Server using the Oracle Web Listener only. This does not apply to other listeners used with Oracle Application Server. It also does not apply to Oracle9i Application Server. |
Oracle Application Server, when used specifically with the Oracle Web Listener, strictly enforces virtual-host checking using the Host request header that is sent by almost all browsers. The Host header contains the string "hostname:port" where hostname and port are as entered in the location bar of the browser, even if the hostname in the location bar is an IP address. If the Oracle Web Listener receives a Host header that does not match an entry in the Host Name and Port columns of the Network section of the configuration (corresponding to the [Multiport] section in the sv*.cfg configuration file for the listener), it returns an HTTP error code 400 indicating that the request did not specify a valid virtual host.
This limitation applies to the following deployments:
In Oracle Application Server 4.x, this is strictly enforced for HTTP/1.1 requests only. For HTTP/1.0 requests, only the host name has to match an entry in the Network section. The port number in the Host header does not matter.
Oracle Web Listener, as shipped with Oracle Web Application Server 3.0, enforces this strictly for all HTTP requests, that is HTTP/1.0 and HTTP/1.1.
To make an Oracle Web Listener recognize and accept a Host header, a corresponding entry must be added to the Network section for that listener. When you add an entry with host name h1 and port p1, h1 is only used to match incoming Host headers and does not otherwise affect the operation of the listener. h1 does not need to be a DNS host name of the computer. However, p1 is used as a port on which the Oracle Web Listener tries to listen on. Hence there should be no other process on the computer listening on port p1.
Oracle9iAS Web Cache does not change the Host header that it receives as part of a request when relaying that request to the application Web server.
If you set up Oracle9iAS Web Cache to listen on port 1100 on a computer with DNS host name m1 and the Application Web Server is on computer m2 on port 80, and you use a browser to access http://m1:1100/, the Host header received by Oracle9iAS Web Cache is "Host: m1:1100". This is exactly the Host header that will be received by the application Web server.
If you are using Oracle Application Server with the Oracle Web Listener as your application Web server, this means that the Host header sent to Oracle9iAS Web Cache must be recognized by the Oracle Web Listener; that is, there must be a corresponding entry in the Network section.
If you are using Oracle9iAS Web Cache's host name and port directly in your browser, and if Oracle9iAS Web Cache and the Oracle Web Listener are on the same computer, the Oracle Web Listener will need to accept Oracle9iAS Web Cache's host name and port number in the Host header, and for that to occur Oracle9iAS Web Cache's port number needs to be in the Network section of the Listener's configuration. This would mean that both Oracle9iAS Web Cache and the Oracle Web Listener will try to listen on that port, which is not possible. See Section 10.1.3.2, "Entries for Network".
When you are using your browser to connect directly to Oracle9iAS Web Cache, ensure that Oracle9iAS Web Cache and the Oracle Web Listener are not on the same computer.
To deploy Oracle9iAS Web Cache and the Oracle Web Listener on the same computer, there has to be a port-translating switch between the browser and Oracle9iAS Web Cache that translates the port number to which the browser connects to Oracle9iAS Web Cache's listening port.
For example, assume that Oracle9iAS Web Cache is listening on port 7777 on computer m1.aaa.com, and Oracle Web Listener is the application Web server listening on port 80 on the same computer m1.aaa.com. In this example, the user enters http://www.aaa.com/ in the browser. The browser will attempt to connect to port 80 on www.aaa.com. www.aaa.com should be resolved through DNS to the switch, which should redirect requests for www.aaa.com on port 80 to computer m1 on port 1100. Note that the Host header will be: "Host: www.aaa.com:80". Oracle9iAS Web Cache will forward requests as needed to computer m1 port 80, that is, the Oracle Web Listener. For the Oracle Web Listener to accept this Host header, you will need to have added an entry to Network containing host name www.aaa.com and port 80. See Section 10.1.3.2, "Entries for Network" for how this can done on computer m1.
If you want Oracle9iAS Web Cache to handle a large number of concurrent HTTP requests, you may need to tune TCP/IP settings for your operating system, such as the maximum TCP/IP connection queue length.
|
See Also: Operating-system documentation for information about tuning network performance. |
In particular, if you run stress tests against Oracle9iAS Web Cache and continuously open more TCP/IP connections from one client computer to Oracle9iAS Web Cache, you may experience periodic oscillation of throughput. This is usually caused by the TCP/IP TIMED_WAIT state of the operating system. In real world deployments, this is not an issue since it is unlikely that a single client will generate a huge number of connections.
In the case of a denial-of-service attack, availability problems usually arise in the network layer in your operating system. For example, if one client generates large number of connections, TCP/IP connection problems generally arise in your operating system.
The following examples demonstrate utilities that set some of the TCP/IP parameters for Solaris, HP-UX, AIX, Linux, and Tru64 UNIX.
Example Utilities Script for Solaris 2.x
#!/usr/bin/bash -x /usr/sbin/ndd -set /dev/tcp tcp_conn_req_max_q 10240 /usr/sbin/ndd -set /dev/tcp tcp_conn_req_max_q0 10240 /usr/sbin/ndd -set /dev/tcp tcp_xmit_hiwat 32768 /usr/sbin/ndd -set /dev/tcp tcp_recv_hiwat 32768 /usr/sbin/ndd -set /dev/tcp tcp_time_wait_interval 1000
Example Utilities Script for HP-UX
#!/usr/bin/ksh /usr/bin/ndd -set /dev/tcp tcp_conn_req_max_q 10240 /usr/bin/ndd -set /dev/tcp tcp_time_wait_interval 1000
Example Utilities for AIX
Use the no utility to set the tcp tunable values on AIX.
For example, to see current values, enter:
prompt> no -a
To increase the size of send and receive buffers, enter:
prompt> no -o tcp_sendspace=65536 prompt> no -o tcp_recvspace=65536
Example Utilities for Linux
On Linux, the tunable TCP/IP parameters can be set through the /proc file system.
The /proc/sys/net/ipv4 directory contains the files which can be edited to change the TCP/IP default values.
For example, enter the following commands:
prompt> echo 900 > /proc/sys/net/ipv4/tcp_keepalive_time prompt> echo 10 > /proc/sys/net/ipv4/tcp_fin_timeout
Also, you can set the size of TCP/IP sender and receiver windows using the following command, where w_value and r_value are the new sizes of the windows:
prompt> echo w_value /proc/sys/net/core/wmem_max prompt> echo r_value /proc/sys/net/core/rmem_max
Example Utilities for Tru64 UNIX
Use the sysconfig utility to set the TCP/IP tunable values for Tru64 UNIX.
For example, to set the value of tcbhashsize to 16384, enter:
prompt> sysconfig -r inet tcbhashsize=16384
To enable keepalive, enter:
prompt> sysconfig -r inet tcp_keepalive_default=1
To set the maximum number of pending TCP/IP connections, enter:
prompt> sysconfig -r socket somaxconn=65535
This section describes configuration issues and their workarounds for Oracle9iAS Web Cache. It contains the following sections:
Section 10.2.4, "Mismatched Oracle Home Definitions Causes Web Cache to Fail to Start"
Section 10.2.6, "Using Session Binding within a Cache Cluster"
Section 10.2.7, "DAVOraWebCacheReadOnly Parameter Does Not Work"
To start initial Oracle9iAS Web Cache configuration:
If not currently logged on to the Oracle9iAS Web Cache computer, log in with the user ID of the user that performed the installation.
Start Oracle9iAS Web Cache. From the command line, enter webcachectl start.
Point your browser to the Oracle9iAS Web Cache Welcome URL:
http://web_cache_hostname:4000/
When prompted for the administrator user ID and password, enter administrator for the user name and the appropriate password. The first time you log in, the password is administrator.
|
See also: Oracle9iAS Web Cache Administration and Deployment Guide (available at http://otn.oracle.com/products/ias/web_cache for complete configuration coverage |
Oracle9iAS Web Cache uses two configuration files: webcache.xml and internal.xml. The Oracle9iAS Web Cache Manager writes its configuration information to the webcache.xml file. Oracle9iAS Web Cache uses internal.xml file. These files are located in the ORACLE_HOME/webcache directory Do not edit these configuration files manually, except in the cases described in these Release Notes, or when directed to do so by Oracle Support Services. Improper editing of these configuration files may cause problems in Oracle9iAS Web Cache.
In past releases, the following attributes required manual modification of the internal.xml file:
KEEPALIVE_TIMEOUT specifies the time, in seconds, for Oracle9iAS Web Cache to keep a connection open to the browser after it has returned a response.
OSRECV_TIMEOUT specifies the time, in seconds, for the origin server to generate a response to Oracle9iAS Web Cache.
In this release of Oracle9iAS Web Cache, these attributes have been merged into the Oracle9iAS Web Cache Manager (webcache.xml). During migration, these modifications are not preserved. If you modified these attributes, you have two choices. You can do one of the following:
Use the Network Timeouts page (Cache-Specific Configuration > Network Timeouts) of Oracle9iAS Web Cache Manager to reconfigure the settings
Preserve any change that you made to the old version of internal.xml, and copy the changes to the appropriate place in webcache.xml
If you are upgrading an existing Oracle9iAS Web Cache installation, the passwords for administration and invalidation are reset. The user name and password for administration is administrator/administrator and the user name and password for invalidation is invalidator/invalidator. You can change both passwords in the Security page (General Configuration > Security) of Oracle9iAS Web Cache Manager.
By default, Oracle9iAS Web Cache is configured to use the following default TCP ports:
Listening HTTP Requests: 7777
Listening HTTPS Requests: 4443
Administration HTTP Requests: 4000
Invalidation HTTP Requests: 4001
Statistics HTTP Requests: 4002
If these ports are in use, then the installation procedure attempts to assign other port numbers from a range of possible port numbers.
|
See also: Oracle9i Application Server Installation Guide |
The Oracle HTTP Server is configured to use the following default ports:
HTTP Requests: 7778
HTTPS Requests: 4444
At the end of installation, Oracle9iAS Web Cache will attempt to start. If there are port conflicts, then Oracle9iAS Web Cache may fail to start.
|
See also:
|
If the definition of Oracle home in the webcache.xml configuration file is different than the definition of Oracle home in your environment, Oracle9iAS Web Cache may fail to start.
For example on UNIX, if ORACLE_HOME was defined as /home/oracle_home_ias during the installation, that definition is written to the ORACLEHOME attribute in the webcache.xml file. Then, if your environment defines ORACLE_HOME as /private/oracle_home_ias and you invoke the webcachectl executable to start Oracle9iAS Web Cache, Oracle9iAS Web Cache will fail to start.
In this case, you may see a message similar to the following:
Error: No matching CACHE element found in webcache.xml for current host name (webcache-host) and ORACLE_HOME (/private/oracle_home_ias). Admin Server failed to start.
You can solve this situation by either redefining ORACLE_HOME in your environment or editing the webcache.xml file so that the definitions are identical. (In the webcache.xml file, you modify the ORACLEHOME attribute of the CACHE NAME element. In a cluster environment, there is more than one CACHE NAME element, one for each cluster member. Be sure to modify the correct element.)
In this case, you may see a message similar to the following:
The description for Event ID ( 1 ) in Source ( Oracle9iAS-Web-Cache ) cannot be found.The local computer may not have the necessary registry information or message DLL files to display messages from a remote computer.The following information is part of the event: Cannot open log files because NULL socket indicates problem.
To solve this situation, modify the webcache.xml file to match the registry settings located in HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE so that the definitions are identical. (In the webcache.xml file, you modify the ORACLEHOME attribute of the CACHE NAME element. In a cluster environment, there is more than one CACHE NAME element, one for each cluster member. Be sure to modify the correct element.)
By default, peer requests between two members of a cache cluster are not logged in the access log. Only client requests to the cluster are logged. Peer request logging can be enabled for individual cache cluster members by adding the ACCESSLOGIGNOREPEERREQUEST attribute to the MISCELLANEOUS element in the internal.xml configuration file.
The valid values for this attribute are:
YES
NO
The default value is YES.
The following example shows the MISCELLANEOUS element with peer-to-peer logging enabled:
<MISCELLANEOUS ERRORLOGFILE="my_oracle_home/webcache/logs/event_log" ACCESSLOGIGNOREPEERREQUEST="NO"/>
When Oracle9iAS Web Cache receives an initial request that requires session binding, it load balances across origin servers and passes the request to an origin server to establish the session. In addition, Oracle9iAS Web Cache internally maintains the session-to-origin server binding information for that session. When Oracle9iAS Web Cache receives a subsequent request for the same session, it looks up the session-to-origin server binding information and forwards the request to the same origin server.
In a cache cluster, the binding information for a session is maintained by the cache cluster member that received the initial request. This information is not shared by the cache cluster members. Therefore, subsequent requests for the same session must go through the same cache cluster member. In order to use cache session binding with a cache cluster deployment, you must use a Load Balancer with connection persistence capabilities. A Load Balancer with these capabilities ensures that subsequent requests for the same client session session are sent to the same cluster member.
The DAVOraWebCacheReadOnly parameter, if specified in the httpd.conf file, does not work in this release.
As a workaround, use the <LimitExcept> directive in the httpd.conf file, as described in the OraDAV module configuration chapter of the Oracle HTTP Server Administration Guide. Applying access restrictions to a location for all methods except GET, HEAD, and OPTIONS requests will essentially achieve the goal of using the DAVOraWebCacheReadOnly parameter. However, a caveat is that end users will always be restricted to GET, HEAD, and OPTIONS requests, even when Oracle9iAS Web Cache is not being used.
This section describes security limitations for Oracle9iAS Web Cache. It contains the following subsections:
Oracle9iAS Web Cache does not cache login requests or authenticated pages that use mod_sso static directives. To ensure that responses for those pages using dynamic directives with mod_sso are not cached, add the Surrogate-Control: no-store response-header field to identify the page as non-cacheable.
When configured with HTTPS listening ports, Oracle9iAS Web Cache is unable to forward browser certificates to origin servers. If browsers are using certificate-based single sign-on authentication, do not use Oracle9iAS Web Cache.
If a wallet contains a user certificate as a trustpoint for an origin server, then a core dump will occur when the user connects to the origin server. Oracle Corporation recommends not adding user certificates to trustpoints in the Oracle wallet, but instead, install the certificate authority (CA) signers' certificate as a trustpoint.
By default, Oracle9iAS Web Cache caches all *.htm and *.html pages. Since caching rules override HTTP headers in determining cacheability, HTML pages that contain HTTP authentication response headers are cached. To avoid pages that support basic HTTP authentication from being cached, modify the caching rules to not include pages that require authentication.
