2 Understanding Oracle HTTP Server Modules

This chapter provides a high-level description of the Oracle-developed modules, or "plug-ins," used by the Oracle HTTP Server (OHS). It also provides a list of all other Apache- and third party-developed modules for OHS.

Modules (mods) extend the basic functionality of Oracle HTTP Server and support integration between Oracle HTTP Server and other Oracle Fusion Middleware components.

This chapter discusses the modules developed specifically by Oracle for Oracle HTTP Server. It includes the following sections:

2.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 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 out-of-the-box the Apache HTTP Server and third-party modules listed in Table 2-1. These modules are not developed by Oracle.

Table 2-1 Apache HTTP Server and Third-party Modules in Oracle HTTP Server

Module For more information, see:































mod_cgid (UNIX only)






















































Also, for Oracle HTTP Server-specific information regarding mod_security, see Appendix F, "Configuring mod_security".

















2.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.

See Section G.1, "mod_certheaders" for a list and description of the directives accepted by mod_certheaders.

2.3 mod_context

mod_context creates or propagates Execution Context IDs, or ECIDs, for requests handled by Oracle HTTP Server. If an ECID has been created for the request execution flow before it reaches Oracle HTTP Server, mod_context will make the ECID available for logging within Oracle HTTP Server and for propagation to other Fusion Middleware components, such as WebLogic Server. If an ECID has not been created when the request reaches Oracle HTTP Server, mod_context will create one.

mod_context is not configurable. It is enabled by loading it into the server with the LoadModule directive, and disabled by removing or commenting out the LoadModule directive corresponding to this module. It should always be enabled to aid with problem diagnosis.

2.4 mod_dms

mod_dms provides FMW infrastructure access to the OHS Oracle Dynamic Monitoring Service (DMS) data.

2.5 mod_odl

The mod_odl module allows Oracle HTTP Server to access Oracle Diagnostic Logging (ODL). ODL generates log messages in text or XML-formatted logs, in a format which complies with Oracle standards for generating error log messages. Oracle HTTP Server uses ODL by default.

Oracle HTTP Server complies with the Federal Information Processing Standard publication 140 (FIPS 140); it uses a version of the underlying SSL libraries that has gone through formal FIPS certification. As part of Oracle HTTP Server's FIPS 140 compliance, the mod_ossl plug-in now includes the SSLFIPS directive. For more information, see Section G.2.6, "SSLFIPS."

ODL provides the following benefits:

  • The capability to limit the total amount of diagnostic information saved. You can set the level of information saved and you can specify the maximum size of the log file and the log file directory.

  • When you reach the specified size, older segment files are removed and newer segment files are saved in chronological fashion.

  • Components can remain active, and do not need to be shutdown, when older diagnostic logging files are deleted.

You can view log files using Fusion Middleware Control or with WLST commands, or you can download log files to your local client and view them using another tool (for example, a text edit or another file viewing utility).

For more information on using ODL with Oracle HTTP Server, see Chapter 7, "Managing Oracle HTTP Server Logs."

See Also:

"Managing Log Files and Diagnostic Data" in Administering Oracle Fusion Middleware.

2.6 mod_ossl

mod_ossl, the Oracle Secure Sockets Layer (SSL) implementation in use with the Oracle database, enables strong cryptography for Oracle HTTP Server. It is a plug-in to Oracle HTTP Server that enables the server to use SSL and is very similar to the OpenSSL module, mod_ssl. mod_ossl supports SSL version 3 and TLS versions 1.0, 1.1. and 1.2, and is based on Certicom and RSA Security technology.

Oracle HTTP Server complies with the Federal Information Processing Standard publication 140 (FIPS 140); it uses a version of the underlying SSL libraries that has gone through formal FIPS certification. As part of Oracle HTTP Server's FIPS 140 compliance, the mod_ossl plug-in now includes the SSLFIPS directive. For more information, see Section G.2.6, "SSLFIPS."

Oracle no longer supports mod_ssl. A tool is provided to enable you to migrate from mod_ssl to mod_ossl, and convert your text certificates to Oracle wallets.

mod_ossl provides:

  • Encrypted communication between client and server, using RSA or DES encryption standards.

  • Integrity checking of client-server communication using MD5 or SHA checksum algorithms.

  • Certificate management with Oracle wallets.

  • Authorization of clients with multiple access checks, exactly as performed in mod_ssl.

mod_ossl Directives

See Section G.2 for a list and descriptions of directives accepted by mod_ossl.

See Also:

"Configuring SSL for the Web Tier" section of Administering Oracle Fusion Middleware.

2.7 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 mod_perl, follow the instructions in Section 4.6.4, "Configuring mod_perl".

2.7.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. 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:


The following steps assume you are using Fusion Middleware Control and a managed server. For general information on editing a configuration file, see Section 1.6.2, "Editing the Configuration".
  1. Edit the mod_perl.conf file:

    1. In Fusion Middleware Control, navigate to the Oracle HTTP Server Advanced Server Configuration page.

    2. Select the mod_perl.conf file from the menu and click Go.

    3. Add the following line to the mod_perl.conf file:

      PerlModule Apache::DBI

  2. Click Apply to save the file.

  3. Restart Oracle HTTP Server as described in Section 4.3.4, "Restarting Oracle HTTP Server Instances."

Place the Perl scripts that you want to run in the DOMAIN_HOME/config/fmwconfig/components/OHS/instances/componentName/cgi-bin.

Example 2-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
    or warn "Database disconnect failed; $DBI::errstr\n";

To run the DBI scripts, the URLs would look like the following:


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. Testing a Database Connection

Example 2-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 2-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 "can't log off Oracle"; 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 AL16UTF16 or UTF8.

Example 2-3 shows an example of accessing SQL NCHAR data.

Example 2-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' );


As shown in Example 2-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 2-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' );

2.8 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 uses the PL/SQL Web ToolKit needs to create a DAD to invoke the application.

This section contains the following topics:

mod_plsql Directives

See Section G.3.1 for a list and descriptions of directives accepted by mod_plsql.

2.8.1 Creating a DAD

To create a DAD, perform the following steps:

  1. Open the dads.conf configuration file.

    For the locations of mod_plsql configuration files, see Table 2-2.


    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.6.6, "Modifying an Oracle HTTP Server Configuration File."
  2. Add the following:

    1. 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>


      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 earlier PL/SQL applications.
    2. 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
    3. 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
    4. One or more specific mod_plsql directives. For example:

      PlsqlDatabaseUsername        scott
      PlsqlDatabasePassword        tiger
      PlsqlDatabaseConnectString   orcl
      PlsqlAuthenticationMode      Basic
    5. The </Location> tag to close the <Location> element.

  3. Save the edits.

  4. Obfuscate the DAD password by running the dadTool.pl script located in the ORACLE_HOME/bin directory.

    See Also:

    "PlsqlDatabasePassword" for instructions on performing the obfuscation.
  5. Restart Oracle HTTP Server as described in Section 4.3.4, "Restarting Oracle HTTP Server Instances."

You can create additional DADs by defining other uniquely named <Location> elements in dads.conf.

Example DADs

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

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

2.8.2 Configuration Files for mod_plsql

The mod_plsql configuration parameters reside in the configuration files that are located in the configuration directory (typically, DOMAIN_HOME/config/fmwconfig/components/OHS/componentName/), as described in Table 2-2.

Table 2-2 mod_plsql Configuration Files In a System Component Instance

Directory Name Contents




dads.conf and cache.conf

For information on editing these .conf files, see Section 1.6.2, "Editing the Configuration".

The mod_plsql configuration parameters are described in these sections: plsql.conf

The plsql.conf file resides in the CONFIG_DIR/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 G.3.1 for a list and description of the directives used in plsql.conf.

See Also:

The plsql.README file, located in ORACLE_HOME/ohs/mod_plsql, for a detailed description of plsql.conf. dads.conf

The dads.conf file contains the configuration parameters for the PL/SQL database access descriptor. (See Table 2-2 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 G.3.2 for a list and description of the directives used in dads.conf cache.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 Appendix G for a list and description of the directives used in cache.conf

2.8.3 Using Configuration Files and Parameters

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:


Multi-line directives enable you to specify same directive multiple times in a DAD.

2.8.4 Additional Documentation

For more Oracle HTTP Server-relevant information on PL/SQL, see the following:

2.9 mod_webgate

The mod_webgate module enables single sign-on (SSO) for Oracle HTTP Server. WebGate examines incoming requests and determines whether the requested resource is protected, and if so, retrieves the session information for the user.

For more information, see Section, "Using WebGate to Authenticate Users" and Section 1.3.2, "Security: Single Sign-On with WebGate." For information on configuring WebGate, see "Configuring Oracle HTTP Server WebGate for Oracle Access Manager" in Installing and Configuring Oracle HTTP Server.

2.10 mod_wl_ohs

The mod_wl_ohs module enables requests to be proxied from Oracle HTTP Server 12c (12.1.2) to Oracle WebLogic Server. This module is generally referred to as the Oracle WebLogic Server Proxy Plug-In.

For information about the prerequisites and procedure for configuring mod_wl_ohs, see "Configuring the Plug-In for Oracle HTTP Server" in Using Oracle WebLogic Server Proxy Plug-Ins 12.1.2. Directives for this module are listed in "Parameters for Oracle WebLogic Server Proxy Plug-Ins" in that document.


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 bundled with Oracle HTTP Server.