Understanding Oracle HTTP Server Modules
Modules (mods) extend the basic functionality of Oracle HTTP Server, and support integration between Oracle HTTP Server and other Oracle Fusion Middleware components.
Note:
Unless otherwise mentioned, the information in this document is applicable when Oracle HTTP Server is installed with Oracle WebLogic Server and Oracle Fusion Middleware Control. It is assumed that readers are familiar with the key concepts of Oracle Fusion Middleware, as described in the Oracle Fusion Middleware Concepts Guide and the Oracle Fusion Middleware Administrator's Guide.
For information about installing Oracle HTTP Server in standalone mode, see “Installing Oracle Web Tier in Stand-Alone Mode” in the Oracle Fusion Middleware Installation Guide for Oracle Web Tier.
This chapter discusses the modules developed specifically by Oracle for Oracle HTTP Server. It includes the following sections:
3.1 List of Included Modules
This section lists all of the modules bundled with Oracle HTTP Server.
Oracle-developed Modules for Oracle HTTP Server
The following modules have developed specifically by Oracle for Oracle HTTP Server:
Apache HTTP Server and Third-party Modules in Oracle HTTP Server
Oracle HTTP Server also includes the following Apache HTTP Server and third-party modules out-of-the-box. These modules are notdeveloped by Oracle.
See Also:
For information about Apache HTTP Server modules, see the Apache documentation.
-
mod_authz_host
-
mod_actions
-
mod_alias
-
mod_asis
-
mod_auth_basic
-
mod_auth_dbm
-
mod_authn_anon
-
mod_autoindex
-
mod_authn_dbm
-
mod_authn_file
-
mod_authz_groupfile
-
mod_authz_host
-
mod_authz_user
-
mod_cern_meta
-
mod_cgi
-
mod_cgid (Unix only)
-
mod_deflate
-
mod_dir
-
mod_env
-
mod_expires
-
mod_fastcgi
-
mod_headers
-
mod_imagemap
-
mod_include
-
mod_info
-
mod_log_config
-
mod_logio
-
mod_mime
-
mod_mime_magic
-
mod_negotiation
-
mod_proxy
-
mod_proxy_balancer
-
mod_proxy_connect
-
mod_proxy_ftp
-
mod_proxy_http
-
mod_rewrite
-
mod_setenvif
-
mod_speling
-
mod_status
-
mod_unique_id
-
mod_userdir
-
mod_usertrack
3.2 mod_certheaders
The mod_certheaders module enables reverse proxies that terminate Secure Sockets Layer (SSL) connections in front of Oracle HTTP Server to transfer information regarding the SSL connection, such as SSL client certificate information, to Oracle HTTP Server and the applications running behind Oracle HTTP Server. This information is transferred from the reverse proxy to Oracle HTTP Server using HTTP headers. The information is then transferred from the headers to the standard CGI environment variable. The mod_ossl module or the mod_ssl module populate the variable if the SSL connection is terminated by Oracle HTTP Server.
The mod_certheaders module also enables certain requests to be treated as HTTPS requests even though they are received through HTTP. This is done using the SimulateHttps
directive.
SimulateHttps
takes the container it is contained within, such as <VirtualHost>
or <Location>
, and treats all requests received for this container as if they were received through HTTPS, regardless of the real protocol used by the request.
3.3 mod_dms
The mod_dms module enables you to monitor the performance of site components using Oracle Dynamic Monitoring Service (DMS).
For more information about DMS, see the "Oracle Dynamic Monitoring Service" chapter in the Oracle Fusion Middleware Performance and Tuning Guide.
3.4 mod_onsint
The mod_onsint module provides integration support with Oracle Notification Service (ONS) and Oracle Process Manager and Notification Server (OPMN). It is an Oracle module and provides the following functionality.
-
Provides a subscription mechanism for ONS notifications within Oracle HTTP Server. mod_onsint receives notification for all modules within an Oracle HTTP Server instance.
-
Publishes
PROC_READY ONS
notifications so that OPMN knows that the listener is up and ready. It also provides information such as DMS metrics and information about how the listener can be contacted. These notifications are sent periodically by mod_onsint as long as the Oracle HTTP Server instance is running.
mod_onsint runs as a thread within a Oracle HTTP Server parent process on UNIX and within a child process on Windows. This thread is responsible for sending and receiving ONS messages.
There is an optional directive called OpmnHostPort
that can be configured for mod_onsint. This directive enables you to specify a hostname and port that OPMN should use for pinging the Oracle HTTP Server instance that mod_onsint is running in. If OpmnHostPort
is not specified, mod_onsint chooses an HTTP port automatically. In certain circumstances, you may want to choose a specific HTTP port and hostname that OPMN should use to ping the listener with.
OpmnHostPort
has the following syntax that specifies the values to pass to OPMN:
OpmnHostPort [<http> | <https>://]<host>:<port>
For example, the following line would specify that OPMN should use HTTP, the localhost interface and port 7778 to ping this listener:
OpmnHostPort http://localhost:7778
For more information about ONS and OPMN, see the "Oracle Process Manager and Notification Overview" chapter in the Oracle Fusion Middleware Oracle Process Manager and Notification Server Administrator's Guide.
3.5 mod_oradav
The mod_oradav module is an Oracle Call Interface (OCI) application written in C that extends the implementation of mod_dav. The mod_oradav directive can read and write to local files or to an Oracle database. The Oracle database must have an OraDAV driver (a stored procedure package) for the mod_oradav module to map WebDAV activity to database activity. Essentially the mod_oradav module enables WebDAV clients to connect to an Oracle database, read and write content, and query and lock documents in various schemas.
You can configure the mod_oradav module using standard Oracle HTTP Server directives. Use the Advanced Server Configuration page of Fusion Middleware Control to configure the mod_oradav module. The mod_oradav directive can immediately leverage other module code (such as mime_magic) to perform content management tasks. Most OraDAV processing activity involves streaming content to and from a content provider. The mod_oradav directive uses OCI streaming logic directly within Oracle HTTP Server.
See Also:
-
For information about using the mod_oradav module to access database schemas for access by third-party tools, such as Adobe GoLive, Macromedia Dreamweaver, and Oracle interMedia, go to the OraDAV information available on OTN at:
3.6 mod_ossl
The mod_ossl module enables strong cryptography for Oracle HTTP Server. This Oracle module is a plug-in to Oracle HTTP Server that enables the server to use SSL. It is very similar to the OpenSSL module, mod_ssl. The mod_ossl module is based on the Oracle implementation of SSL, which supports SSL version 3 and TLS version 1, and is based on Certicom and RSA Security technology.
See Also:
For more information, see the "Configuring SSL for the Web Tier" section of the Oracle Fusion Middleware Administrator's Guide.
3.7 mod_osso
The mod_osso module enables single sign-on for Oracle HTTP Server by examining incoming requests and determining whether the requested resource is protected. If the resource is protected, then the module retrieves the Oracle HTTP Server cookie.
The module is disabled by default. You can enable mod_osso module on the Server Configuration Properties page of Fusion Middleware Control. For more information see Section 4.3.1, "Using Fusion Middleware Control to Specify Server Properties."
See also:
For information about forced authentication, see the Oracle Fusion Middleware Application Developer's Guide for Oracle Identity Management.
For information about single sign-on, see the Oracle Fusion Middleware Security Guide.
3.8 mod_perl
The mod_perl module embeds the Perl interpreter into Oracle HTTP Server. This eliminates start-up overhead and enables you to write modules in Perl. Oracle Fusion Middleware uses Perl version 5.10.
The module is disabled, by default. To enable the mod_perl module, follow the instructions in Section 4.4.3, "Configuring the mod_perl Module".
See Also:
mod_perl documentation at http://perl.apache.org/docs/index.html
3.8.1 Using mod_perl with a Database
This section provides information for mod_perl users working with databases. It explains how to test a local database connection and set character forms.
3.8.1.1 Using Perl to Access the Database
Perl scripts access databases using the DBI/DBD driver for Oracle. The DBI/DBD driver is part of Oracle Fusion Middleware. It calls Oracle Call Interface (OCI) to access the databases.
Once mod_perl is enabled, DBI must be enabled in the mod_perl.conf
file to function. To enable DBI, perform the following steps:
-
Edit the
mod_perl.conf
file:-
In Fusion Middleware Control, navigate to the Oracle HTTP Server Advanced Server Configuration page.
-
Select the
mod_perl.conf
file from the menu and click Go. -
Add the following line to the
mod_perl.conf
file:PerlModule Apache::DBI
-
-
Click Apply to save the file.
-
Restart Oracle HTTP Server as described in Section 4.1.4, "Restarting Oracle HTTP Server."
Place the Perl scripts that you want to run in the ORACLE_INSTANCE
/config/OHS/
component_name
/cgi-bin
directory.
Example 3-1 Using a Perl Script to Access a Database
#!ORACLE_HOME/perl/bin/perl -w use DBI; my $dataSource = "host=hostname.domain;sid=orclsid;port=1521"; my $userName = "userid"; my $password = "password"; my $dbhandle = DBI->connect("dbi:Oracle:$dataSource", $userName, $password) or die "Can't connect to the Oracle Database: $DBI::errstr\n"; print "Content-type: text/plain\n\n"; print "Database connection successful.\n"; ### Now disconnect from the database $dbhandle->disconnect or warn "Database disconnect failed; $DBI::errstr\n"; exit;
To run the DBI scripts, the URLs would look like the following:
http://hostname.domain:port/cgi-bin/scriptname http://hostname.domain:port/perl/scriptname
If a script specifies "use Apache::DBI
" instead of "use DBI
", then it can only run from the URL http://
hostname.domain:port
/perl/
scriptname
.
3.8.1.2 Testing a Database Connection
Example 3-2 shows a sample Perl script for testing a database connection. Replace the instance name, user ID, and password in the connect
statement with proper values for the target database.
Example 3-2 Sample Perl Script For Testing Connection for Local Seed Database
use DBI; print "Content-type: text/plain\n\n"; $dbh = DBI->connect("dbi:Oracle:instance_name", userid/password, "") || die $DBI::errstr; $stmt = $dbh->prepare("select * from emp order by empno")|| die $DBI::errstr; $rc = $stmt->execute() || die $DBI::errstr; while (($empno, $name) = $stmt->fetchrow()) { print "$empno $name\n"; } warn $DBI::errstr if $DBI::err; die "fetch error: " . $DBI::errstr if $DBI::err; $stmt->finish() || die "can't close cursor"; $dbh->disconnect() || die "cant't log off Oracle";
3.8.1.3 Using SQL NCHAR Data Types
SQL NCHAR data types (NCHAR, NVARCHAR2 and NCLOB) are reliable Unicode data types. SQL NCHAR data types enable you to store Unicode characters regardless of the database character set. The character set for those data types is specified by the national character set, which is either AL16UTF-16 or UTF8.
Example 3-3 shows an example of accessing SQL NCHAR data.
Example 3-3 Sample Script to Access SQL NCHAR Data
# declare to use the constants for character forms use DBD::Oracle qw(:ora_forms); # connect to the database and get the database handle $dbh = DBI->connect( ... ); # prepare the statement and get the statement handle $sth = $dbh->prepare( 'SELECT * FROM TABLE_N WHERE NCOL1 = :nchar1' ); # bind the parameter of a NCHAR type $sth->bind_param( ':nchar1', $param_1 ); # set the character form to NCHAR $sth->func( { ':nchar1' => ORA_NCHAR } , 'set_form' ); $sth->execute;
As shown in Example 3-3, the set_form
function is provided as a private function that you can invoke with the standard DBI func
method. The set_form
function takes an anonymous hash that enables you to set the character form for parameters.
The valid values of character form are either ORA_IMPLICIT
or ORA_NCHAR
. Setting the character form to ORA_IMPLICIT
causes the application's bound data to be converted to the database character set, and ORA_NCHAR
to the national character set. The default is ORA_IMPLICIT
.
The constants are available as ora_forms
in DBD::Oracle
.
set_default_form
sets the default character form for a database handle. The following example shows its syntax:
# specify the default form to be NCHAR $dbh->func( ORA_NCHAR, 'set_default_form' );
This syntax causes the form of all parameters to be ORA_NCHAR
, unless otherwise specified with set_form
calls. Unlike the set_form
function, the set_default_form
functions on the database handle, so every statement from the database handle has the form of your choice.
Example 3-4 Sample for set_form
# a declaration example for the constants ORA_IMPLICIT and ORA_NCHAR use DBD::Oracle qw(:ora_forms); # set the character form for the placeholder :nchar1 to NCHAR $sth->func( { ':nchar1' => ORA_NCHAR } , 'set_form' ); # set the character form using the positional index $sth->func( { 2 => ORA_NCHAR } , 'set_form' ); # set the character form for multiple placeholders at once $sth->func( { 1 => ORA_NCHAR, 2 => ORA_NCHAR } , 'set_form' );
3.9 mod_reqtimeout
mod_reqtimeout sets timeout and minimum data rate for receiving requests. mod_reqtimeout module provides protection against some DOS attacks and related issues. For more information, see:
http://httpd.apache.org/docs/2.2/mod/mod_reqtimeout.html
3.10 mod_plsql
The mod_plsql module connects Oracle HTTP Server to an Oracle database, enabling you to create Web applications using Oracle stored procedures.
To access a Web-enabled PL/SQL application, configure a PL/SQL database access descriptor (DAD) for the mod_plsql module. A DAD is a set of values that specifies how the module connects to a database server to fulfill an HTTP request. Besides the connection details, a DAD contains important configuration parameters for various operations in the database and for the mod_plsql module in general. Any Web-enabled PL/SQL application which makes use of the PL/SQL Web ToolKit needs to create a DAD to invoke the application.
This section contains the following topics:
3.10.1 Creating a DAD
To create a DAD, perform the following steps:
-
Open the
dads.conf
configuration file.For the locations of mod_plsql configuration files, see Table 3-1.
Note:
You can also open and edit the
dads.conf
file by using Oracle Fusion Middleware Control, on the Oracle HTTP Server Advanced Server Configuration page, as described in Section 4.4.5, "Modifying an Oracle HTTP Server Configuration File." -
Add the following:
-
The
<Location>
element, which defines a virtual path used to access the PL/SQL Web Application. This directive groups a set of directives that apply to the namedLocation
.For example, the following directive defines a virtual path called
/myapp
that will be used to invoke a PL/SQL Web application through a URL such ashttp://host:port/myapp/
.<Location /myapp>
Note:
Earlier releases of the mod_plsql module were always mounted on a virtual path with a prefix of
/pls
. This restriction is removed in later releases but might still be a restriction imposed by some of the earlier PL/SQL applications. -
The
SetHandler
directive, which directs Oracle HTTP Server to enable the mod_plsql module to handle the request for the virtual path defined by the named Location:SetHandler pls_handler
-
Additional Oracle HTTP Server directives that are allowed in the context of a
<Location>
directive. Typically, the following directives are used:Order deny,allow Allow from all
-
One or more specific mod_plsql directives. For example:
PlsqlDatabaseUsername scott PlsqlDatabasePassword tiger PlsqlDatabaseConnectString orcl PlsqlAuthenticationMode Basic
-
The
</Location>
tag to close the<Location>
element.
-
-
Save the edits.
-
Obfuscate the DAD password by running the
dadTool.pl
script located in theORACLE_HOME/bin
directory.See Also:
"PlsqlDatabasePassword" for instructions on performing the obfuscation.
-
Restart Oracle HTTP Server as described in Section 4.1.4, "Restarting Oracle HTTP Server."
You can create additional DADs by defining other uniquely named <Location>
elements in dads.conf
.
The following DAD connects as a specific user and has a default home page:
<Location /pls/mydad> SetHandler pls_handler Order allow,deny Allow from All PlsqlDatabaseUsername scott PlsqlDatabasePassword tiger PlsqlDatabaseConnectString prod_db PlsqlDefaultPage scott.myapp.home </Location>
The following DAD uses HTTP Basic Authentication and supports document upload/download operations:
<Location /pls/mydad2> SetHandler pls_handler Order allow,deny Allow from All PlsqlDatabaseConnectString prod_db2 PlsqlDefaultPage scott.myapp.my_home PlsqlDocumentTablename scott.my_documents PlsqlDocumentPath docs PlsqlDocumentProcedure scott.docpkg.process_download </Location>
3.10.2 Configuration Files for mod_plsql
The mod_plsql configuration parameters reside in the configuration files that are located in the ORACLE_INSTANCE
directory, as described in Table 3-1.
Table 3-1 mod_plsql Configuration Files In an Oracle Instance
Directory Name | Contents |
---|---|
|
|
|
|
The mod_plsql configuration parameters are described in these sections:
The plsql.conf
file resides in the ORACLE_INSTANCE
/config/OHS/config/OHS/
component_name
/moduleconf
directory and Oracle HTTP Server automatically loads all .conf
files under this location. The plsql.conf
file contains the LoadModule
directive to load the mod_plsql module into Oracle HTTP Server, any global settings for the mod_plsql module, and include directives for dads.conf
and cache.conf
.
See Also:
The plsql.README
file, located in ORACLE_HOME/ohs/mod_plsql
, for a detailed description of plsql.conf
The following parameters are used with the plsql.conf
file:
Enables Dynamic Monitoring Service (DMS) for the mod_plsql module.
Category | Value |
---|---|
Syntax |
|
Default |
|
Example |
|
Enables debug level logging for the mod_plsql module. Debug level logging is meant to be used for debugging purposes only.
When logging is enabled, Oracle HTTP Server log files are typically created in the ORACLE_INSTANCE
/diagnostics/logs/OHS/config/OHS/
component_name
directory. However, the location specified in PlsqlLogDirectory determines the final location.
This parameter should be set to Off
unless recommended by Oracle support to debug problems with the mod_plsql module.
To view more details about the internal processing of the mod_plsql module, set this directive to On
. This causes the mod_plsql module to start logging every request that is processed. The log files are generated as specified by the PlsqlLogDirectory directive.
Category | Value |
---|---|
Syntax |
|
Default |
|
Example |
|
Specifies the directory where debug level logs are written.
Set the directory name of the location where log files should be generated when logging is enabled. To avoid possible confusion about the location of this directory, an absolute path is recommended.
On UNIX, this directory must have write permissions by the owner of the child httpd
processes.
Category | Value |
---|---|
Syntax |
|
Default |
None |
Example |
|
PlsqlIdleSessionCleanupInterval
Specifies the time (in minutes) in which the idle database sessions should be closed and cleaned by the mod_plsql module.
This directive is used in conjunction with connection pooling of database connections and sessions in the mod_plsql module. When a session is not used for the specified amount of time, it is closed and freed. This is done so that unused sessions can be cleaned, and the memory is freed on the database side.
Setting this time to a low number helps in faster cleanup of unused database sessions. If this number is too low, then this may adversely affect the performance benefits of connection pooling in the mod_plsql module.
If the number of open database sessions is not a concern, you can increase the value of this parameter for best performance. In such a case, if the site is accessed frequently enough that the idle session cleanup interval is never reached for a session, then the DAD configuration parameter PlsqlMaxRequestsPerSession can be modified so that it is guaranteed that a pooled database session gets recycled on a regular basis.
For most installations, the default value is adequate.
Category | Value |
---|---|
Syntax |
|
Default |
15 (minutes) |
Example |
|
The dads.conf
file contains the configuration parameters for the PL/SQL database access descriptor. (See Table 3-1 for the file location.) A DAD is a set of values that specifies how the mod_plsql module connects to a database server to fulfill a HTTP request.
The following parameters are used with the dads.conf
file:
Specifies the procedure to be invoked after calling the requested procedure. This enables you to put a hook point after the requested procedure is called. This is useful in doing SQL*Traces/SQL Profiles while debugging a problem with the requested procedure. This is also useful when you want to ensure that a specific call is made after running every procedure.
Category | Value |
---|---|
Syntax |
|
Default |
None |
Example |
|
-
This parameter should only be used for debugging purposes. In addition, you could use this parameter to stop SQL trace/SQL profiling.
Specifies whether the mod_plsql module should describe a procedure before trying to run it. If this is set to On
, then the mod_plsql module will always describe a procedure before invoking it. Otherwise, the mod_plsql module will only describe a procedure when its internal heuristics have interpreted a parameter type incorrectly.
Category | Value |
---|---|
Syntax |
|
Default |
|
Example |
|
-
This parameter should only be used for debugging purposes.
Specifies the authentication mode to use for allow access through the DAD.
Category | Value |
---|---|
Syntax |
|
Default |
|
Example |
|
-
If the DAD is not using the Basic authentication, then you must include a valid username/password in the DAD configuration. For the Basic mode, to perform dynamic authentication, the DAD username/password parameters must be omitted.
-
The SingleSignOn mode is supported only for Oracle Fusion Middleware releases, and is used by Oracle Portal and Oracle Single Sign-On. Most customer applications use Basic authentication. Custom authentication modes (GlobalOwa, CustomOwa, and PerPackageOwa) are used by very few PL/SQL applications.
Specifies the procedure to be invoked before calling the requested procedure. This enables you to put a hook point before the requested procedure is called. This is useful in doing SQL*Traces/SQL Profiles while debugging a problem with the requested procedure. This is also useful when you want to ensure that a specific call be made before running every procedure.
Category | Value |
---|---|
Syntax |
|
Default |
None |
Example |
|
-
This parameter should only be used for debugging purposes. In addition, you could use this parameter to start SQL Trace/SQL Profiling.
Note:
This configuration property is rarely ever changed, and system defaults suffice in almost all cases.
Specifies the rounding size to use while binding the number of elements in a collection bind. While executing PL/SQL statements, the Oracle database maintains a cache of PL/SQL statements in the shared SQL area, and attempts to reuse the cached statement if the same statement is run again. Oracle's matching criteria requires that the statement texts be identical, and that the bind variable data types match. Unfortunately, the type match for strings is sensitive to the exact byte size specified, and for collection bindings is also sensitive to the number of elements in the collection. Since the mod_plsql module binds statements dynamically, the odds of hitting the shared cache are low, and it may fill up with near-duplicates and lead to contention for the latch on the shared area. This parameter reduces that effect by bucketing bind lengths to the nearest level.
All numbers specified should be in ascending order. After the last specified size, subsequent bucket sizes will be assumed to be twice the last one.
Category | Value |
---|---|
Syntax |
|
Default |
4,20,100,400 |
Example |
|
-
This parameter is relevant only if you are using procedures with array parameters, and passing varying number of parameters to the procedure.
-
The default should be sufficient for most PL/SQL applications.
-
To see if this parameter needs to be changed, check the number of versions of a SQL statement in the SQL area.
-
After the higher configured value, mod_plsql starts auto-generating bucket sizes of larger values by doubling the last value, as needed. Therefore, after 400, the next bucket value becomes 800, then 1600, and so on.
-
Consider using flexible parameter passing to reduce the problem.
Note:
This configuration property is rarely ever changed, and system defaults suffice in almost all cases.
Specifies the rounding size to use while binding the number of elements in a collection bind. While executing PL/SQL statements, the Oracle database maintains a cache of PL/SQL statements in the shared SQL area, and attempts to reuse the cached statement if the same statement is run again. Oracle's matching criteria requires that the statement texts be identical, and that the bind variable data types match. Unfortunately, the type match for strings is sensitive to the exact byte size specified, and for collection bindings is also sensitive to the number of elements in the collection. Since the mod_plsql module binds statements dynamically, the odds of hitting the shared cache are low, and it may fill up with near-duplicates and lead to contention for the latch on the shared area. This parameter reduces that effect by bucketing bind widths to the nearest level.
All numbers specified should be in ascending order. After the last specified size, subsequent bucket sizes will be assumed to be twice the last one.
The last bucket width must be equal to or less than 4000. This is due to the restriction imposed by OCI where array bind widths cannot be greater than 4000.
Category | Value |
---|---|
Syntax |
|
Default |
|
Example |
|
-
This parameter is relevant only if you are using procedures with array parameters, and passing varying number of parameters to the procedure.
-
The default should be sufficient for most PL/SQL applications.
-
To see if this parameter needs to be changed, check the number of versions of a SQL statement in the SQL area.
-
After the higher configured value, mod_plsql starts auto-generating bucket sizes of larger values by doubling the last value, as needed. Therefore, after 400, the next bucket value becomes 800, then 1600, and so on.
-
Consider using flexible parameter passing to reduce the problem.
Specifies overrides and additions of CGI environment variables to the default set of environment variables passed to a PL/SQL procedure. This is a multi-line directive of name-value pairs to be added, overridden or removed. You can only specify one environment variable for each directive.
You can add CGI environment variables from the Oracle HTTP Server environment by specifying the variable name. To remove a CGI environment variable, set it equal to blank. To add your own name-value pair, use the syntax myname=myvalue.
Category | Value |
---|---|
Syntax |
|
Default |
None |
Example |
|
-
Environment variables added here are available in the PL/SQL application through the function
owa_util.get_cgi_env
.
Specifies the timeout in milliseconds for testing a connection pool in the mod_plsql module.
When PlsqlConnectionValidation is set to Automatic
or AlwaysValidate
, the mod_plsql module attempts to test pooled database connections. This parameter specifies the maximum time the mod_plsql module should wait for the test request to complete before it assumes that the connection is not usable.
Category | Value |
---|---|
Syntax |
|
Default |
10000 (milliseconds) |
Example |
|
Specifies the mechanism the mod_plsql module should use to detect terminated connections in its connection pool.
Note:
This configuration property is rarely ever changed, and system defaults suffice in almost all cases.
For performance reasons, the mod_plsql module pools database connections. If a database instance goes down, and the mod_plsql module was maintaining a pool of connections to the instance, then each pooled database connection results in an error when it is next used to service a request. This can be a concern in high availability configurations such as RAC where even if one node goes down, other nodes servicing the database might have been able to service the request successfully. The mod_plsql module provides for a mechanism whereby it can self-correct after it detects a failure that could be caused by a database node going down. This mechanism to self-correct is controlled by the parameter PlsqlConnectionValidation.
The following are the valid values for PlsqlConnectionValidation:
-
Automatic
: The mod_plsql module tests all pooled database connections which were created prior to the detection of a failure that could mean an instance failure. -
ThrowAwayOnFailure
: The mod_plsql module throws away all pooled database connections which were created prior to the detection of a failure that could mean an instance failure. -
AlwaysValidate
: The mod_plsql module always tests all pooled database connections which were created prior to issuing a request. Since this option has an associated performance overhead for each request, this should be used with caution. -
NeverValidate
: The mod_plsql module never pings any pooled database connection.
Category | Value |
---|---|
Syntax |
|
Default |
|
Example |
|
When the mod_plsql module encounters one of the following errors, it assumes that the database may have been down.
-
00443 — background process <string> did not start
-
00444 — background process <string> failed while starting
-
00445 — background process did not start after <x> seconds
-
00447 — fatal error in background processes
-
00448 — normal completion of background process
-
00449 — background process <string> unexpectedly terminated with error
-
00470 — LGWR process terminated with error
-
00471 — DBWR process terminated with error
-
00472 — PMON process terminated with error
-
00473 — ARCH process terminated with error
-
00474 — SMON process terminated with error
-
00475 — TRWR process terminated with error
-
00476 — RECO process terminated with error
-
00480 — LCK* process terminated with error
-
00481 — LMON process terminated with error
-
00482 — LMD* process terminated with error
-
00484 — LMS* process terminated with error
-
00485 — DIAG process terminated with error
-
01014 — ORACLE shutdown in progress
-
01033 — ORACLE initialization or shutdown in progress
-
01034 — ORACLE not available
-
01041 — internal error. hostdef extension doesn't exist
-
01077 — background process initialization failure
-
01089 — immediate shutdown in progress- no operations permitted
-
01090 — shutdown in progress- connection is not permitted
-
01091 — failure during startup force
-
01092 — ORACLE instance terminated. Disconnection forced
-
03106 — fatal two-task communication protocol error
-
03113 — end-of-file on communication channel
-
03114 — not connected to ORACLE
-
12570 — TNS: packet reader failure
-
12571 — TNS: packet writer failure
Specifies the connection to an Oracle database.
Category | Value |
---|---|
Syntax |
The string parameter depends on the second argument:
If the format argument is not specified, then the mod_plsql module assumes the string is either in the HOST:PORT:SID format, or resolvable by Net8. The differentiation between the two is made by the presence of the colon in the specified string. It is recommended that newer DADs do not use the |
Default |
None |
Example |
|
-
If the database is running in the same Oracle home, or the environment variable TWO_TASK is set, then this parameter need not be specified.
-
If the database is running in a separate Oracle home, then this parameter is mandatory.
-
If you have problems connecting to the database:
-
Check the username and password information in the DAD.
-
Make sure that you run tnsping db_connect_string, and commands such as:
sqlplus DADUsername/DADPassword@db_connect_string
-
Ensure that TNS_ADMIN is configured properly.
-
Verify that the HOST:PORT:SERVICE_NAME format works correctly.
-
Ensure that the TNS listener and database are up and running.
-
Ensure that you can ping the host from this machine.
-
-
From a the mod_plsql module perspective,
TNSFormat
andNetServiceNameFormat
are synonymous and denote connect descriptors that are resolved by Net8. TheTNSFormat
is provided as a convenience so that end-users use this to signify that the name resolution happens through the local tnsnames.ora. For situations where the resolution is through an LDAP lookup as configured in sqlnet.ora, it is recommended that the format specifier ofNetServiceNameFormat
be used.If your database supports high availability, for example, Oracle Real Application Clusters database, it is highly recommended that you use the
NetServiceNameFormat
such that the resolution for the net service name is through LDAP. This enables you to add or remove RAC nodes accessible through the mod_plsql module by changing Oracle Internet Directory with the new or deleted node information. In such situations, hard-coding database listener HOST:PORT information in dads.conf or in the localtnsnames.ora
is not recommended.
Specifies the password to use to log in to the database.
Category | Value |
---|---|
Syntax |
|
Default |
None |
Example |
|
Notes:
-
This is a mandatory parameter, except for a DAD that sets PlsqlAuthenticationMode to Basic and uses dynamic authentication.
-
For DADs using SingleSignOn authentication, this parameter uses the name of the schema owner.
After making manual configuration changes to DAD passwords, it is recommended that the DAD passwords are obfuscated by running the dadTool.pl
script located in ORACLE_HOME/bin
.
To obfuscate DAD passwords:
-
If necessary, change the user to the Oracle software owner user, typically
oracle
, using the following command:$ su - oracle
-
Set the
ORACLE_HOME
environment variable to specify the path to the Oracle home directory for the current release, and set the PATH environment variable to include the directory containing the Perl executable and the location of thedadTool.pl
script.Bourne, Bash, or Korn shell:
$ ORACLE_HOME=new_ORACLE_HOME_path;export ORACLE_HOME $ PATH=ORACLE_HOME/bin:ORACLE_HOME/perl/bin:$PATH;export PATH
C or tcsh shell:
% setenv ORACLE_HOME new_ORACLE_HOME_PATH % setenv PATH ORACLE_HOME/bin:ORACLE_HOME/perl/bin:PATH
On Microsoft Windows, set the PATH and PERL5LIB environment variable:
set PATH=ORACLE_HOME\bin;ORACLE_HOME\perl\bin;%PATH% set PERL5LIB=ORACLE_HOME\perl\lib
-
On UNIX platforms, set the shared library path environment variable.
Include the
ORACLE_HOME/lib
orlib32
directory in your shared library path. Table 3-2 shows the appropriate directory and environment variable for each platform.Table 3-2 Shared Library Path Environment Variable
Platform Environment Variable Include Directory AIX Based Systems
LIBPATH
ORACLE_HOME/lib
HP-UX PA-RISC
SHLIB_PATH
ORACLE_HOME/lib
Solaris Operating System
LD_LIBRARY_PATH
ORACLE_HOME/lib32
Other UNIX platforms, including Linux and HP Tru64 UNIX
LD_LIBRARY_PATH
ORACLE_HOME/lib
For example, on HP-UX PA-RISC systems, set the SHLIB_PATH environment to include the
ORACLE_HOME/lib
directory:$SHLIB_PATH=$ORACLE_HOME/lib:$SHLIB_PATH;export SHLIB_PATH
-
Change directory to the mod_plsql configuration directory for the current release of Oracle HTTP Server:
cd ORACLE_HOME/bin
-
Invoke the following Perl script to obfuscate DAD password:
perl dadTool.pl -f dadfilename
where
dadfilename
is the filename fordads.conf
, which includes the full path to the DAD file.For example:
perl dadTool.pl -f /u01/app/oracle/as11gr1/ORACLE_INSTANCE/config/OHS/component_name/mod_plsql/dads.conf
Specifies the username to use to log in to the database.
Category | Value |
---|---|
Syntax |
|
Default |
None |
Example |
|
-
This is a mandatory parameter, except for a DAD that sets PlsqlAuthenticationMode to Basic and uses dynamic authentication.
-
For DADs using SingleSignOn authentication, this parameter is the name of the schema owner.
Specifies the default procedure to call if none is specified in the URL.
Category | Value |
---|---|
Syntax |
|
Default |
None |
Example |
|
-
You can also use Oracle HTTP Server Rewrite rules to achieve the same effect as you get by setting this configuration parameter.
Specifies a virtual path in the URL that initiates document download from the document table. For example, if this parameter is set to docs
, then the following URLs will start the document downloading process for URLs of the format:
/pls/dad/docs /pls/plsqlapp/docs
Category | Value |
---|---|
Syntax |
|
Default |
|
Example |
|
-
Omit this parameter for applications that do not perform document uploads or downloads.
Specifies the procedure to call when a document download is initiated. This procedure is called to process the download.
Category | Value |
---|---|
Syntax |
|
Default |
None |
Example |
|
-
Omit this parameter for applications that do not perform document uploads or downloads.
Specifies the table in the database to which all documents are uploaded.
Category | Value |
---|---|
Syntax |
|
Default |
None |
Example |
|
-
Omit this parameter for applications that do not perform document uploads or downloads.
Specifies the error reporting mode for mod_plsql errors.
Specifies a pattern for procedures, packages, or schema names which are forbidden to be directly run from a browser. This is a multi-line directive in which each pattern is on a separate line. The pattern is not case sensitive and can accept a wildcard such as an asterisk (*). The default patterns disallowed from direct URL access are as follows:
-
sys.*
-
dbms_*
-
utl_*
-
owa_util*
-
owa.*
-
htp.*
-
htf.*
-
wpg_docload.*
Setting this directive to #NONE#
will disable all protection. This is strongly discouraged for an active site and should not be done. It may be used for debugging purposes.
If this parameter is overridden, the defaults still apply, which means that you do not have to explicitly add the default list to the list of excluded patterns.
Category | Value |
---|---|
Syntax |
|
Default |
sys.* dbms_* utl_* owa_util* owa.* htp.* htf.* wpg_docload.* |
Example |
will disallow access to URLs which contain one of:
will disable all protection. Its use is strongly discouraged for an active site. |
-
In addition to the patterns specified with this parameter, the mod_plsql module disallows any procedure name which contains the following special characters:
-
tabs
-
new lines
-
carriage-return
-
single quotation mark
-
reverse slash
-
form feed
-
left parenthesis
-
right parenthesis
-
space
This cannot be changed.
-
Specifies the number of rows of content to fetch from the database for each trip, using either owa_util.get_page or owa_util.get_page_raw.
By default, the mod_plsql module attempts to fetch 200 response lines of output where each line is of 255 bytes. In situations where the response bytes are single-bytes, the response buffer is populated to the maximum and can pack 255*200=51000 bytes for each round trip. For responses containing multi-byte data, the byte packing for each row could be less than ideal resulting in lesser bytes getting transferred for each round trip. If your application generates large pages frequently and the response does not fit in one round trip, then consider setting this parameter higher. The memory usage for the mod_plsql module will increase.
Category | Value |
---|---|
Syntax |
|
Default |
200 |
Example |
|
-
This parameter is changed only for performance reasons. The minimum value for this parameter is 28, but it is seldom reduced.
-
Change this parameter only under the following circumstances:
-
The average response page is large and you want to reduce the number of round-trips the mod_plsql module makes to the database to fetch the response.
-
The character set in use is multi-byte, and you want to compensate for the problem of get_page or get_page_raw fetching fewer bytes for each row. Calculations in the PL/SQL Web ToolKit are character-based and in the case of multi-byte characters, OWA packages assume a worst-case character byte size and do not attempt to pack each row to its maximum.
-
Specifies what mode the mod_plsql module should use to do extra performance logging.
InfoDebug mode: This logs more information to the Apache's error_log. This is used in conjunction with Apache's info logging level. If the Apache's logging level is not at least set to this high, this setting will be ignored.
Category | Value |
---|---|
Syntax |
|
Default |
Empty |
Example |
|
The logging setting is useful for debugging problems in your PL/SQL application.
Specifies the maximum number of requests a pooled database connection should service before it is closed and re-opened.
Category | Value |
---|---|
Syntax |
|
Default |
1000 |
Example |
|
-
This parameter helps relieve memory and resource problems that may occur due to prolonged session reuse by a PL/SQL application.
-
This parameter should not need to be changed. The default is sufficient in most cases.
-
Setting this parameter to a low number can degrade performance. A case for a lower value might be an infrequently-used DAD whose performance is not a concern, and for which limiting the number of requests provides some benefit.
Specifies the NLS_LANG variable for this DAD. This parameter overrides the NLS_LANG environment variable. When this parameter is set, the PL/SQL Gateway uses the specified NLS_LANG to connect to the database. Once connected, an alter session command is issued to switch to the specified language and territory. If the middle tier character set matches that of the database, then no alter session call is issued by the mod_plsql module.
Category | Value |
---|---|
Syntax |
|
Default |
None |
Example |
|
-
Most applications have PlsqlTransferMode set to CHAR which means that the character set in PlsqlNLSLanguage needs to match the character set of the database. In one special case, where the database and the mod_plsql module are both using fixed-size character sets, and the character set width matches, the character set can be different. The response character set is always the mod_plsql module character set.
-
If PlsqlTransferMode is set to RAW, then this parameter can be ignored.
Specifies a virtual path alias to map to a procedure call. This is application-specific. This directive is used with PlsqlPathAliasProcedure.
Category | Value |
---|---|
Syntax |
|
Default |
None |
Example |
|
-
For applications that do not use path aliasing, this parameter may be omitted.
Specifies the procedure to call when the virtual path in the URL matches the path alias as configured by PlsqlPathAlias.
Category | Value |
---|---|
Syntax |
|
Default |
None |
Example |
|
-
For applications that do not use path aliasing, this parameter may be omitted.
PlsqlRequestValidationFunction
Specifies an application-defined PL/SQL function which gives you the opportunity to allow and disallow further processing of the requested procedure. This is useful in implementing tight security for your PL/SQL application by blocking out package and procedure calls that should not be allowed to run from a DAD.
The function defined by this parameter must have the following prototype:
boolean function_name (procedure_name IN varchar2)
The procedure_name parameter will contain the name of the procedure that the request is trying to run.
For example, if all the PL/SQL application procedures callable from a browser are inside the package mypkg, then an implementation of this function can be as follows:
boolean my_validation_check (procedure_name varchar2) is begin if (upper (procedure_name) like upper ('myschema.mypkg%')) then return TRUE else return FALSE end if; end;
Category | Value |
---|---|
Syntax |
|
Default |
none |
Example |
|
-
By default, the mod_plsql module already disallows direct URL access to certain schemas and packages. For more information, refer to PlsqlExclusionList.
-
It is highly recommended that you provide an implementation for this function such that it only allows requests that belong to your application, and are callable from a browser.
-
Since this function will be called for every request, be sure to make this function as optimized as possible. Suggested recommendations are:
-
Name your PL/SQL packages in a fashion such that the implementation of this function can be similar to the previous example.
-
If your implementation performs a table lookup to determine what packages and procedures should be allowed, then performance can be improved if you pin the cursor in the shared pool.
-
Specifies the cookie name when PlsqlAuthenticationMode is set to SingleSignOn. This parameter is supported only for Oracle Fusion Middleware releases, and is used by Oracle Portal and Oracle Single Sign-On.
Category | Value |
---|---|
Syntax |
|
Default |
Same as DAD name |
Example |
|
-
For DADs not using SingleSignOn authentication, this parameter can be omitted. In most other cases, the session cookie name should be omitted (and this parameter automatically defaults to the DAD name).
-
A session cookie name must be specified only for Oracle Portal instances that need to participate in a distributed Oracle Portal environment. For those Oracle Portal nodes you want to seamlessly participate as a federated cluster, ensure that the session cookie name for all the participating nodes is the same.
-
Independent Oracle Portal nodes need to use distinct session cookie names.
Specifies how package and session state should be cleaned up at the end of each the mod_plsql request.
-
StatelessWithResetPackageState
causes the mod_plsql module to calldbms_session.reset_package_state
at the end of each mod_plsql request. This is the default. -
StatelessWithPreservePackageState
causes the mod_plsql module to callhtp.init
at the end of each mod_plsql request. This cleans up the state of session variables in the PL/SQL Web ToolKit. The PL/SQL application is responsible for cleaning up its own session state. Failure to do so causes erratic behavior, in which a request starts recognizing or manipulating state modified in previous requests. -
StatelessWithFastResetPackageState
causes the mod_plsql module to calldbms_session.modify_package_state(dbms_session.reinitialize)
at the end of each mod_plsql request. This API is faster than the mode ofStatelessWithResetPackageState
, and avoids some latch contention issues, but exists only in Oracle database releases 8.1.7.2 and later. This mode uses slightly more memory than the default mode.
Category | Value |
---|---|
Syntax |
|
Default |
|
Example |
|
-
The earlier values of stateful=no or stateful=STATELESS_RESET corresponds to
StatelessWithResetPackageState
. -
The earlier value of stateful=STATELESS_FAST_RESET corresponds to
StatelessWithFastResetPackageState
. -
The earlier value of stateful=STATELESS_PRESERVE corresponds to
StatelessWithPreservePackageState
.
The mod_plsql module does not support stateful mode of operation. To allow PL/SQL applications stateful behavior, save the state in cookies and/or in the database.
Specifies the transfer mode for data from the database back to the mod_plsql module. Most applications use the default value of CHAR
.
Category | Value |
---|---|
Syntax |
|
Default |
|
Example |
|
-
This parameter only needs to be changed to enable sending back responses in different character sets from the same DAD. In such a case, the
CHAR
mode is useless, since it always converts the response data from the database character set to the mod_plsql character set.
Specifies the file extensions to be uploaded as LONGRAW data type, as opposed to using the default BLOB data type. The default can be overridden by specifying multi-line directives of file extensions for field. A value of asterisk (*
) in this field causes all documents to be uploaded as LONGRAW.
Category | Value |
---|---|
Syntax |
|
Default |
None |
Example |
|
-
For applications that do not upload or download documents, this parameter may be omitted.
The cache.conf
file contains the configuration settings for the file system caching functionality implemented in the mod_plsql module. This configuration file is relevant only if PL/SQL applications use the OWA_CACHE
package to cache dynamically generated content in the file system.
The following parameters are specified in the cache.conf
file:
Specifies the time to start the cleanup of the cache storage.
This setting defines the exact day and time in which cleanup should occur. The frequency can be set as daily, weekly, and monthly.
-
To define daily frequency, the keyword
Everyday
is used. The cleanup starts every day at the time defined. For example,Everyday 2:00
causes the cleanup to happen everyday at 2:00 a.m. (local time). -
To define weekly frequency, the days of the week, (
Sunday
,Monday
,Tuesday
,Wednesday
,Thursday
,Friday
,Saturday
) are used. For example,Wednesday 15:30
causes the cleanup to happen every Wednesday at 3:30 p.m. (local time). -
To define monthly frequency, the keyword
Everymonth
is used. The cleanup starts on the Saturday of the month at the time defined. For example, Saturday Everymonth 23:00 causes the cleanup to happen the first Saturday of every month at 11:00 p.m. (local time).Category Value Syntax
PlsqlCacheCleanupTime {Sunday-Saturday | Everyday | Everymonth} {hh:mm}
Default
Saturday 23:00
Example
PlsqlCacheCleanupTime
Monday 20:00
Specifies the directory where cache files are written out by the mod_plsql module. This directory must exist or Oracle HTTP Server will not start.
On UNIX, this directory must have write permissions by the owner of the child httpd processes.
Category | Value |
---|---|
Syntax |
|
Default |
none |
Example |
|
Enables mod_plsql caching.
Category | Value |
---|---|
Syntax |
|
Default |
|
Example |
|
-
If an application does not make use of the
OWA_CACHE
package in the PL/SQL Web Toolkit, then you can choose to disable caching. In such situations, there will be a minor performance benefit.
Specifies the maximum time, in days, a cache file can reside in a file system cache, after which the cached file will be removed for cache maintenance.
This setting is to ensure that the cache system does not contain old content. This setting removes old cache files and makes space for new ones.
Category | Value |
---|---|
Syntax |
|
Default |
30 (days) |
Example |
|
Specifies the maximum possible size of a cache file.
This setting prevents the case in which one file can fill up the entire cache. In general, it is recommended that this be set to about 1-3 percent of the total cache size, which is specified by PlsqlCacheTotalSize.
Category | Value |
---|---|
Syntax |
|
Default |
1048576 |
Example |
|
Specifies the total size of the cache directory. The default is 20 MB.
This setting limits the amount of space the cache is allowed to use. Both PL/SQL cache and Session Cookie cache share this cache space. This setting is not a hard limit. It might exceed the limit temporarily during normal processing. This is normal behavior.
The cleanup algorithm uses this setting to determine how much to reduce the cache files. Therefore, the real space limit is the physical storage's available size.
This parameter takes bytes as values:
-
1 megabytes = 1048576 bytes
-
10 megabytes = 10485760 bytes
Category | Value |
---|---|
Syntax |
|
Default |
20971520 (bytes) |
Example |
|
3.10.3 Configuration Files and Parameters
Table 3-3 lists the mod_plsql files and their corresponding configuration parameters that were described in the preceding sections.
While specifying a value for a configuration parameter, follow Oracle HTTP Server conventions for specifying values. For instance, if a value has white spaces in it, enclose the value with double quotes. For example:
PlsqlNLSLanguage "TRADITIONAL CHINESE_*.UTF8"
Multi-line directives enable you to specify same directive multiple times in a DAD.
Table 3-3 mod_plsql Configuration Files and Parameters
Configuration File | Parameters |
---|---|
3.11 mod_wl_ohs
The mod_wl_ohs module enables requests to be proxied from Oracle HTTP Server 11g to Oracle WebLogic Server.
For information about the prerequisites and procedure for configuring mod_wl_ohs, see "Configuring the mod_wl_ohs Plug-In for Oracle HTTP Server" in Using Web Server 1.1 Plug-Ins with Oracle WebLogic server.
Note:
mod_wl_ohs is similar to the mod_wl plug-in, which you can use to proxy requests from Apache HTTP Server to Oracle WebLogic server. However, while the mod_wl plug-in for Apache HTTP Server should be downloaded and installed separately, the mod_wl_ohs plug-in is included in the Oracle HTTP Server installation.