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:
This section lists all of the modules bundled with Oracle HTTP Server.
Oracle-developed Modules for Oracle HTTP Server
The following modules have been 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 not developed by Oracle.
See Also:
For information about Apache HTTP Server modules, including lists and descriptions of their valid directives, see the Apache documentation at:
|
|
|
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.
Note:
mod_dms is disabled by default in Oracle HTTP Server 11.1.1.9.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.
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 child process within a Oracle HTTP Server on UNIX and runs as a thread 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.
See Section E.2 for a list and descriptions of directives accepted by mod_onsint.
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:
See Section E.3 for a list and descriptions of directives accepted by mod_oradav.
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 TLS version 1.0, 1.1, and 1.2, and is based on RSA Security technology.
Note:
The SSLv2 protocol is no longer supported by Oracle HTTP Server. SSLv3 protocol is supported for backward compatibility. However Oracle discourages the use of SSLv3 protocol due to security concerns. For more information, see Section 8.9, "Disable SSLv2 and SSLv3 Security Protocols."See Section E.4 for a list and descriptions of directives accepted by mod_ossl.
See Also:
For more information, see the "Configuring SSL for the Web Tier" section of the Oracle Fusion Middleware Administrator's Guide.Note:
mod_osso is deprecated with Oracle Single Sign-On Server 10g. You should use one of the following options:Use the Webgate plug-in; for more information, see one of the following documents:
Use the SSO Agent solution provided in Oracle Access Manager 11g, which uses the same mod_osso module and configuration. For more information, see "Registering Partners (Agents and Applications) by Using the Console" in Oracle Fusion Middleware Administrator's Guide for Oracle Access Manager with Oracle Security Token Service.
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 Section E.5 for a list and descriptions of directives accepted by mod_osso.
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.
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".
This section provides information for mod_perl users working with databases. It explains how to test a local database connection and set character forms.
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.
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";
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 AL16UTF16 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' );
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:
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.
See Also:
This section contains the following topics:
See Section E.6 for a list and descriptions of directives accepted by mod_plsql.
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 thedads.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 named Location.
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 as http://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 the ORACLE_HOME/bin directory.
See Also:
Section E.6.2.11, "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>
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 directives are used in these configuration files:
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.
mod_plsql Directives in plsql.conf
See Section E.6.1 for a list and description of the directives used in plsql.conf.
See Also:
Theplsql.README file, located in ORACLE_HOME/ohs/mod_plsql, for a detailed description of plsql.confThe 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.
mod_plsql Directives in dads.conf
See Section E.6.2 for a list and description of the directives used in dads.conf.
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.
mod_plsql Directives in cache.conf
See Section E.6.3 for a list and description of the directives used in cache.conf.
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_TAIWAN.UTF8"
Multi-line directives enable you to specify same directive multiple times in a DAD.
Notes:
Be aware of the following:mod_security was removed from earlier versions of Oracle HTTP Server but was reintroduced in version 11.1.1.7. The current release follows the recommendations and practices prescribed for open source mod_security 2.6.2. Only documentation applicable to open source Apache mod_security 2.6.2 is applicable to the Oracle HTTP Server implementation of the module.
In Oracle HTTP Server 11.1.1.7 and later, mod_security is not loaded or configured by default; however, if you have an installation patched from 11.1.1.6, it might have loaded and configured the module due to the patch implementation.
Oracle only supports the Oracle-supplied version of mod_security. Newer versions from modsecurity.org will not be supported.
mod_security is an open-source module that you can use to detect and prevent intrusion attacks against Oracle HTTP Server; for example, you can specify a mod_security rule to screen all incoming requests and deny requests that match the conditions specified in the rule. The mod_security module (version 2.6.2) and its prerequisites are included in the Oracle HTTP Server installation as a shared object named mod_security2.so in the ORACLE_HOME/ohs/modules directory.
This version of OHS supports only mod_security (version 2.6.2) directives, variables, action, phases and functions. It will not be supported if you replace this module with a later version. For more information about these directives, see the mod_security documentation, at:
http://www.modsecurity.org/documentation/ .
To make the mod_security module available for use when Oracle HTTP Server is running, ensure that mod_security.conf begins with the following lines:
#Load Module
LoadModule security2_module "${ORACLE_HOME}/ohs/modules/mod_security2.so"
as shown in the mod_security.conf example in Appendix D, "Configuring mod_security". If you are an Oracle HTTP Server 11.1.1.6 user who is now using 11.1.1.9, the module is already configured properly due to previous patch implementations.
Configuring mod_security involves specifying certain directives in the Oracle HTTP Server configuration file. You can specify the directives directly in the httpd.conf file in an IfModule container. Alternatively, you can specify the mod_security directives in a separate mod_security.conf file and include that .conf file in httpd.conf by using the Include directive.
Note that, by default, mod_security.conf does not exist, so you need to create one for your system. Appendix D, "Configuring mod_security", contains a sample mod_security.conf file that you can use for this purpose. Copy and paste the sample into a text editor and read the entire file, editing it for your system. Then save it as your own mod_security.conf and included from your httpd.conf.
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.
See Section E.7 for a list and descriptions of directives accepted by mod_wl_ohs.
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.