Oracle® Application Server Release Notes 10g Release 3 (10.1.3.2) for HP-UX Itanium Part Number B32413-04 |
|
|
View PDF |
This chapter describes issues associated with Oracle HTTP Server. It includes the following topics:
This section contains the following topics:
Section 4.1.1, "Configuring Weighted Routing for AJP13 Destinations"
Section 4.1.2, "Changing the Location of the PID File Requires a Change in apachectl"
Section 4.1.3, "Routing Requests to Different Middle Tiers Based on the URL of the Request"
In the Oc4jMount
directive, weighted load balancing works only when the destinations are instances or clusters. Weighted load balancing does not work for AJP13 destinations. For AJP13 destinations, the load is distributed evenly in a round-robin manner. For example, if your mod_oc4j.conf
file contains the following lines, Host_A and Host_B will get an equal number of requests despite the settings in the Oc4jRoutingWeight
directives.
Oc4jSelectMethod roundrobin:weighted Oc4jRoutingWeight Host_A 1 Oc4jRoutingWeight Host_B 25 Oc4jMount /j2ee ajp13://Host_A:<AJP Port>,Host_B:<AJP Port> Oc4jMount /j2ee/* ajp13://Host_A:<AJP Port>,Host_B:<AJP Port> # Instance weighted routing work as expected #Oc4jMount /j2ee instance://Host_A:home,Host_B:home #Oc4jMount /j2ee/* instance://Host_A:home,Host_B:home
A possible workaround to achieve weighted load balancing for AJP13 destinations is to specify the same host multiple times in the Oc4jMount
directive. The following example specifies Host_B twice.
Oc4jMount /j2ee ajp13://Host_A:<AJP Port>,Host_B:<AJP Port>,Host_B:<AJP Port>
The PidFile
directive specifies the location of the PID file. When Oracle HTTP Server starts up, it writes its process ID in the PID file.
If you edit the PidFile
directive to change the location of the PID file, you must also make a corresponding change in the ORACLE_HOME/Apache/Apache/bin/apachectl
file.
It is not possible to configure two separate Oracle HTTP Servers using the same virtual hostname and port, where the proxy server routes the requests based upon the URL path, and also have them participate as partners in the same SSO configuration.
For example: You configure your load balancer or Oracle Web Cache on the web tier to route requests to applications that use Oracle Single Sign-On to the appropriate middle tier, based on the URLs.
You have an Oracle HTTP Server configured to handle requests for http://wwww.mycompany.com
.
You have an Oracle Web Cache configured to route requests for http://www.mycompany.com/app1
to midtier1.
You have an Oracle Web Cache configured to route requests for http://www.mycompany.com/app2
to midtier2.
app1
and app2
are applications that use Oracle Single Sign-On.
When a user issues a request for /app1
, the request is redirected to midtier1. mod_osso on midtier1 redirects the request to the SSO server for authentication. After authentication, the SSO server calls the success URL, which is always www.mycompany.com/osso_login_success
regardless of which application the request was for, and this success URL is handled by the Oracle HTTP Server for www.mycompany.com
. Because the success URL does not specify which application the request is for, the Oracle HTTP Server for www.mycompany.com
does not know where to redirect the request (whether to redirect it to midtier1 or midtier2). The load balancer or Oracle Web Cache cannot be configured to redirect the success URL correctly as there is no application information in the success URL.
A possible solution to this issue is described in MetaLink note 390358.1, which can be obtained from Oracle Customer Services via a Service Request.
This section describes documentation errata. It includes the following topic:
Section 4.2.2, "Log Level Choices for Configuring IIS Listener for Single Sign-On are Incorrect"
Section 4.2.3, "Correction to SSLCARevocationFile Directive Description"
Section 4.2.4, "Correction to SSLCARevocationPath Directive Description"
Section 4.2.5, "Incorrect Tags Listed for 40-Bit and 56-Bit Export Ciphers"
Section 4.2.6, "Incorrect Web Address for mod_php Extensions Information"
Oracle HTTP Server is based on Apache version 1.3.34.
The "Configuring IIS Listener for Single Sign-On" section in Oracle HTTP Server Administrator's Guide incorrectly states that the valid log levels are debug
, inform
, error
, and emergency
.
The valid log levels are debug
, inform
, error
, and emerg
.
The description for the SSLCARevocationFile
directive in Oracle HTTP Server Administrator's Guide, Chapter 10, "Enabling SSL for Oracle HTTP Server," should be corrected as follows:
Specifies the file where you can assemble the Certificate RevocationLists (CRLs) from CAs (Certificate Authorities) that you accept certificates from. These are used for client authentication. Such a file is the concatenation of various PEM-encoded CRL files in order of preference. CRL files should be from a single issuer. Files specified by SSLCARevocationFile
should not be hashed. There should be only one SSLCARevocationFile
entry; if there are multiple entries, then the last one will be used. SSLCARevocationFile
can be used alternatively and/or additionally to SSLCARevocationPath
.
The description for the SSLCARevocationPath
directive in Oracle HTTP Server Administrator's Guide, Chapter 10, "Enabling SSL for Oracle HTTP Server," should be corrected as follows:
Specifies the directory where PEM-encoded Certificate Revocation Lists (CRLs) are stored. These CRLs come from the CAs (Certificate Authorities) that you accept certificates from. If a client attempts to authenticate itself with a certificate that is on one of these CRLs, then the certificate is revoked and the client cannot authenticate itself with your server.
CRL files in the SSLCARevocationPath
directory must be hashed. You can find the instructions to hash a CRL in Oracle Application Server Administrator's Guide, Section 11.2.5.2.1, "Renaming CRLs with a Hash Value for Certificate Validation." Note that orapki
creates a file with a ".rN
" extension. SSLCARevocationPath
will not work with this extension and it is still possible to access with a revoked certificate. To get it to work with Oracle HTTP Server, change the extension from ".rN
" to ".r0
".
SSLCARevocationPath
can be used alternatively and/or additionally to SSLCARevocationFile
.
Table 10-1, "SSLCipher Suite Tags", in the Oracle HTTP Server Administrator's Guide listed incorrectly the aliases for the 40-bit and the 56-bit export ciphers.
For 40-bit export cipher, do not use EXP40
. Use EXPORT40
instead.
For 56-bit export cipher, do not use EXP56
. Use EXPORT56
instead.
The Web site provided for additional information on mod_php extensions was incorrect. The correct Web site is
The "Using Oracle Application Server Proxy Plug-In" appendix in the Oracle HTTP Server Administrator's Guide mentions the proxy definition file without mentioning the actual filename. This is because the definition file can have any name.
If you are using the Oracle Application Server Proxy Plug-In with Microsoft IIS, you specify the full path to the definition file in the server_defs
entry in the Windows registry. See the "Using Oracle Application Server Proxy Plug-In" appendix in the Oracle HTTP Server Administrator's Guide for the specific location in the registry.
If you are using the Oracle Application Server Proxy Plug-In with Sun Java System listener, you specify the full path to the definition file using the server_defs
parameter on the Init
line in the magnus.conf
(or obj.conf
, depending on the version of your Sun Java System listener) configuration file. In the following example, /oracle/proxyplugin/proxydefs is the definition file:
Init fn="op_init" server_defs="/oracle/proxyplugin/proxydefs" log_file="/oracle/proxyplugin/oproxy.log" log_level=error