| Oracle® Application Server Release Notes 10g Release 3 (10.1.3.2) for Linux x86 Part Number B32200-08 |
|
|
View PDF |
| Oracle® Application Server Release Notes 10g Release 3 (10.1.3.2) for Linux x86 Part Number B32200-08 |
|
|
View PDF |
This chapter describes issues associated with Oracle HTTP Server. It includes the following topics:
This section contains the following topics:
Section 5.1.1, "Configuring Weighted Routing for AJP13 Destinations"
Section 5.1.2, "Changing the Location of the PID File Requires a Change in apachectl"
Section 5.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 5.2.2, "Log Level Choices for Configuring IIS Listener for Single Sign-On are Incorrect"
Section 5.2.3, "Correction to SSLCARevocationFile Directive Description"
Section 5.2.4, "Correction to SSLCARevocationPath Directive Description"
Section 5.2.5, "Incorrect Tags Listed for 40-Bit and 56-Bit Export Ciphers"
Section 5.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
|
 Copyright © 2010, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
