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:
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_actions |
|
|
mod_alias |
|
|
mod_asis |
|
|
mod_auth_basic |
|
|
mod_authn_alias |
|
|
mod_authn_anon |
|
|
mod_authn_default |
|
|
mod_authn_file |
|
|
mod_authz_default |
|
|
mod_authz_groupfile |
|
|
mod_authz_host |
|
|
mod_authz_user |
|
|
mod_autoindex |
|
|
mod_cern_meta |
|
|
mod_cgi |
|
|
mod_cgid (UNIX only) |
|
|
mod_deflate |
|
|
mod_dir |
|
|
mod_dumpio |
|
|
mod_env |
|
|
mod_expires |
|
|
mod_fastcgi (Deprecated) |
|
|
mod_file_cache |
|
|
mod_filter |
|
|
mod_headers |
|
|
mod_imagemap |
|
|
mod_include |
|
|
mod_info |
|
|
mod_log_config |
|
|
mod_logio |
|
|
mod_mime |
|
|
mod_mime_magic |
|
|
mod_negotiation |
|
|
mod_perl (Deprecated) |
|
|
mod_proxy |
|
|
mod_proxy_balancer |
|
|
mod_proxy_connect |
|
|
mod_proxy_ftp |
|
|
mod_proxy_http |
|
|
mod_reqtimeout |
|
|
mod_rewrite |
|
|
mod_security2 |
Also, for Oracle HTTP Server-specific information regarding mod_security, see Appendix P, "Configuring mod_security". |
|
mod_setenvif |
|
|
mod_speling |
|
|
mod_status |
|
|
mod_substitute |
|
|
mod_unique_id |
|
|
mod_userdir |
|
|
mod_usertrack |
|
|
mod_vhost_alias |
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 F.2, "mod_certheaders Module" for a list and description of the directives accepted by mod_certheaders.
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.
mod_dms provides FMW infrastructure access to the OHS Oracle Dynamic Monitoring Service (DMS) data.
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.
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 8, "Managing Oracle HTTP Server Logs."
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 TLS version 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 F.3.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.
See Section F.3 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 Administering Oracle Fusion Middleware.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 5.3.4, "Configuring mod_perl".
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:
Note:
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.3, "Modifying a Configuration File".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.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 $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 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";
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' );
$sth->execute;
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' );
Note:
mod_plsql is deprecated as of Oracle HTTP Server 12c (12.1.3).mod_plsql 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 must create a DAD to invoke the application.
This section contains the following topics:
See Section F.4.1 for a list and descriptions of directives accepted by mod_plsql.
Before working with mod_plsql, you should familiarize yourself with this directive and how it works with Oracle HTTP Server. The following documents provide the relevant information:
Note:
The file you must modify to create a DAD resides in the staging directory (DOMAIN_HOME/config/fmwconfig/components/OHS/ohs1; see Section 1.6.3, "Modifying a Configuration File"). To ensure that these modifications automatically propagate to the run-time directory, stop the Administration Server.To create a DAD, perform the following steps:
Open the dads.conf configuration file either in a text editor or from the Oracle HTTP Server Advanced Server Configuration page in Oracle Fusion Middleware Control (for details on this latter technique, see Section 1.6.3, "Modifying a Configuration File").
For the locations of mod_plsql configuration files, see Table 2-2.
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 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/ohs/bin directory.
See Also:
"PlsqlDatabasePassword" for instructions on performing the obfuscation.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.
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 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 |
|---|---|
|
CONFIG_DIR/moduleconf |
|
|
CONFIG_DIR/mod_plsql |
|
For information on editing these .conf files, see Section 1.6.3, "Modifying a Configuration File".
These sections describe the mod_plsql configuration parameters:
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 F.4.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.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 F.4.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 Appendix F 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.
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 9.4.2.2, "Using WebGate to Authenticate Users" and Section 1.3.3.3, "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.
The mod_wl_ohs module is a key feature of Oracle HTTP Server that enables requests to be proxied from Oracle HTTP Server 12c (12.1.3) to Oracle WebLogic Server. This module is generally referred to as the Oracle WebLogic Server Proxy Plug-In. This plug-in enhances an Oracle HTTP server installation by allowing Oracle WebLogic Server to handle requests that require dynamic functionality. In other words, you typically use a plug-in where the HTTP server serves static pages such as HTML pages, while Oracle WebLogic Server serves dynamic pages such as HTTP Servlets and Java Server Pages (JSPs).
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.3. Directives for this module are listed in "Parameters for Web Server Plug-Ins" in that document.
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 bundled with Oracle HTTP Server.