Contributor: Julia Pond, Warren Briese, Kevin Clark, Priscila Darakjian, Sander Goudswaard, Pushkar
Kapasi, Chuck Murray, Mark Nelson, Bert Rich, Shankar Raman, Baogang Song, Kevin Wang
The Programs (which include both the software and documentation) contain proprietary information of
Oracle Corporation; they are provided under a license agreement containing restrictions on use and
disclosure and are also protected by copyright, patent and other intellectual and industrial property
laws. Reverse engineering, disassembly or decompilation of the Programs, except to the extent required
to obtain interoperability with other independently created software or as specified by law, is prohibited.
The information contained in this document is subject to change without notice. If you find any problems
in the documentation, please report them to us in writing. Oracle Corporation does not warrant that this
document is error-free. Except as may be expressly permitted in your license agreement for these
Programs, no part of these Programs may be reproduced or transmitted in any form or by any means,
electronic or mechanical, for any purpose, without the express written permission of Oracle Corporation.
If the Programs are delivered to the U.S. Government or anyone licensing or using the programs on
behalf of the U.S. Government, the following notice is applicable:
Restricted Rights Notice Programs delivered subject to the DOD FAR Supplement are “commercial
computer software” and use, duplication, and disclosure of the Programs, including documentation,
shall be subject to the licensing restrictions set forth in the applicable Oracle license agreement.
Otherwise, Programs delivered subject to the Federal Acquisition Regulations are “restricted computer
software” and use, duplication, and disclosure of the Programs shall be subject to the restrictions in FAR
52.227-19, Commercial Computer Software - Restricted Rights (June, 1987). Oracle Corporation, 500
Oracle Parkway, Redwood City, CA 94065.
The Programs are not intended for use in any nuclear, aviation, mass transit, medical, or other inherently
dangerous applications. It shall be the licensee's responsibility to take all appropriate fail-safe, backup,
redundancy, and other measures to ensure the safe use of such applications if the Programs are used for
such purposes, and Oracle Corporation disclaims liability for any damages caused by such use of the
Programs.
Oracle is a registered trademark, and Oracle Store, Oracle8i, Oracle9i, SQL*Plus, and PL/SQL are
trademarks or registered trademarks of Oracle Corporation. Other names may be trademarks of their
respective owners.
Contents
Send Us Your Comments ................................................................................................................... xi
Preface.......................................................................................................................................................... xiii
Group ............................................................................................................................................. 4-4
Transfer Log................................................................................................................................... 6-9
7 Oracle HTTP Server Modules
List of Modules.................................................................................................................................... 7-2
The SAXPath License ................................................................................................................ B-23
Glossary
Index
x
Send Us Your Comments
Oracle HTTP Server Administrator’s Guide, 10g Release 1 (10.1)
Part No. B12255-01
Oracle Corporation welcomes your comments and suggestions on the quality and usefulness of this
document. Your input is an important part of the information used for revision.
■Did you find any errors?
■Is the information clearly presented?
■Do you need more information? If so, where?
■Are the examples correct? Do you need more examples?
■What features did you like most?
If you find any errors or have any other suggestions for improvement, please indicate the document
title and part number, and the chapter, section, and page number (if available). You can send comments to us in the following ways:
■Electronic mail: infodev_us@oracle.com
■FAX: 650-506-7227 Attn: Server Technologies Documentation Manager
■Postal service:
Oracle Corporation
Server Technologies Documentation
500 Oracle Parkway, Mailstop 4op11
Redwood Shores, CA 94065
USA
If you would like a reply, please give your name, address, telephone number, and (optionally) electronic mail address.
If you have problems with the software, please contact your local Oracle Support Services.
xi
xii
This guide describes how to administer the Oracle HTTP Server.
This preface contains these topics:
■Intended Audience
■Documentation Accessibility
■Organization
■Related Documentation
■Conventions
Preface
xiii
Intended Audience
The Oracle HTTP Server Administrator’s Guide is intended for database
administrators and security managers.
Documentation Accessibility
Our goal is to make Oracle products, services, and supporting documentation
accessible, with good usability, to the disabled community. To that end, our
documentation includes features that make information available to users of
assistive technology. This documentation is available in HTML format, and contains
markup to facilitate access by the disabled community. Standards will continue to
evolve over time, and Oracle is actively engaged with other market-leading
technology vendors to address technical obstacles so that our documentation can be
accessible to all of our customers. For additional information, visit the Oracle
Accessibility Program Web site at
http://www.oracle.com/accessibility/
Accessibility of Links to External Web Sites in DocumentationThis
documentation may contain links to Web sites of other companies or organizations
that Oracle does not own or control. Oracle neither evaluates nor makes any
representations regarding the accessibility of these Web sites.
xiv
Organization
This document contains:
Chapter 1, "Oracle HTTP Server Overview"
This chapter describes the Oracle HTTP Server, highlighting the differences
between the Oracle distribution and the open source Apache product on which it is
based. It also explains how to start, stop and restart the server.
Chapter 2, "Oracle HTTP Server Concepts"
This chapter introduces you to the Oracle HTTP Server directory structure, and
configuration files, configuration file syntax, modules, and directives.
Chapter 3, "Specifying Server and File Locations"
This chapter explains how to set Oracle HTTP Server and server administrator
options, and specifies file locations.
Chapter 4, "Managing Server Processes"
This chapter provides an overview of the Oracle HTTP Server processes, and
provides information on how to regulate, and monitor these processes.
Chapter 5, "Managing the Network Connection"
This chapter provides information about specifying IP addresses and ports, and
managing server interaction, and network connection persistence.
Chapter 6, "Configuring and Using Server Logs"
This chapter discusses Oracle Diagnostic Logging, log formats, and describes
various log files and their locations.
Chapter 7, "Oracle HTTP Server Modules"
This chapter describes the modules (mods) included in the Oracle HTTP Server. The
modules extend the basic functionality of the Web server, and support integration
between Oracle HTTP Server and other Oracle Database components.
Chapter 8, "Managing Security"
This chapter provides an overview of Oracle HTTP Server security features and
configuration information for setting up a secure Web site using them.
xv
Chapter 9, "Frequently Asked Questions"
This chapter provides answers to frequently asked questions about Oracle HTTP
Server.
Chapter A, "Oracle HTTP Server Configuration Files"
This appendix lists commonly used Oracle HTTP Server configuration files.
Chapter B, "Third Party Licenses"
This appendix includes the Third Party License for all the third party products
included with Oracle Database.
Glossary
The glossary defines terminology used throughout this guide and the Oracle
Database documentation set.
Related Documentation
For more information, see these Oracle resources:
■Oracle Database Documentation Library
■Oracle Database Platform-Specific Documentation on Oracle Database Disk 1
Printed documentation is available for sale in the Oracle Store at
http://oraclestore.oracle.com/
xvi
To download free release notes, installation documentation, white papers, or other
collateral, please visit the Oracle Technology Network (OTN). You must register
online before using OTN; registration is free and can be done at
http://otn.oracle.com/membership/
If you already have a username and password for OTN, then you can go directly to
the documentation section of the OTN Web site at
http://otn.oracle.com/documentation/
Conventions
This section describes the conventions used in the text and code examples of this
documentation set. It describes:
■Conventions in Text
■Conventions in Code Examples
■Conventions for Windows Operating Systems
Conventions in Text
We use various conventions in text to help you more quickly identify special terms.
The following table describes those conventions and provides examples of their use.
ConventionMeaningExample
BoldBold typeface indicates terms that are
ItalicsItalic typeface indicates book titles or
UPPERCASE
monospace
(fixed-width)
font
defined in the text or terms that appear in
a glossary, or both.
emphasis.
Uppercase monospace typeface indicates
elements supplied by the system. Such
elements include parameters, privileges,
datatypes, RMAN keywords, SQL
keywords, SQL*Plus or utility commands,
packages and methods, as well as
system-supplied column names, database
objects and structures, usernames, and
roles.
When you specify this clause, you create an
index-organized table.
Oracle9i Database Concepts
Ensure that the recovery catalog and target
database do not reside on the same disk.
You can specify this clause only for a NUMBER
column.
You can back up the database by using the
BACKUP command.
Query the TABLE_NAME column in the USER_TABLES data dictionary view.
Use the DBMS_STATS.GENERATE_STATS
procedure.
xvii
ConventionMeaningExample
lowercase
monospace
(fixed-width)
font
lowercase
italic
monospace
(fixed-width)
font
Lowercase monospace typeface indicates
executables, filenames, directory names,
and sample user-supplied elements. Such
elements include computer and database
names, net service names, and connect
identifiers, as well as user-supplied
database objects and structures, column
names, packages and classes, usernames
and roles, program units, and parameter
values.
Note: Some programmatic elements use a
mixture of UPPERCASE and lowercase.
Enter these elements as shown.
Lowercase italic monospace font
represents placeholders or variables.
Enter sqlplus to open SQL*Plus.
The password is specified in the orapwd file.
Back up the datafiles and control files in the
/disk1/oracle/dbs directory.
The department_id, department_name,
and location_id columns are in the
hr.departments table.
Set the QUERY_REWRITE_ENABLED
initialization parameter to true.
Connect as oe user.
The JRepUtil class implements these
methods.
You can specify the parallel_clause.
Run Uold_release.SQL where old_release refers to the release you installed
prior to upgrading.
Conventions in Code Examples
Code examples illustrate SQL, PL/SQL, SQL*Plus, or other command-line
statements. They are displayed in a monospace (fixed-width) font and separated
from normal text as shown in this example:
SELECT username FROM dba_users WHERE username = ’MIGRATE’;
The following table describes typographic conventions used in code examples and
provides examples of their use.
ConventionMeaningExample
[ ]Brackets enclose one or more optional
items. Do not enter the brackets.
{ }Braces enclose two or more items, one of
which is required. Do not enter the braces.
|A vertical bar represents a choice of two
or more options within brackets or braces.
Enter one of the options. Do not enter the
vertical bar.
xviii
DECIMAL (digits [ , precision ])
{ENABLE | DISABLE}
{ENABLE | DISABLE}
[COMPRESS | NOCOMPRESS]
ConventionMeaningExample
...Horizontal ellipsis points indicate either:
■That we have omitted parts of the
CREATE TABLE ... AS subquery;
code that are not directly related to
the example
■That you can repeat a portion of the
SELECT col1, col2, ... , coln FROM
employees;
code
.
.
.
Vertical ellipsis points indicate that we
have omitted several lines of code not
directly related to the example.
Other notationYou must enter symbols other than
brackets, braces, vertical bars, and ellipsis
points as shown.
ItalicsItalicized text indicates placeholders or
variables for which you must supply
particular values.
UPPERCASEUppercase typeface indicates elements
supplied by the system. We show these
terms in uppercase in order to distinguish
them from terms you define. Unless terms
appear in brackets, enter them in the
order and with the spelling shown.
However, because these terms are not
case sensitive, you can enter them in
lowercase.
lowercaseLowercase typeface indicates
programmatic elements that you supply.
For example, lowercase indicates names
of tables, columns, or files.
Note: Some programmatic elements use a
mixture of UPPERCASE and lowercase.
Enter these elements as shown.
In releases prior to Oracle8i release 8.1.3,
when you installed Oracle components,
all subdirectories were located under a
top level ORACLE_HOME directory. For
Windows NT, the default location was
C:\orant.
This release complies with Optimal
Flexible Architecture (OFA) guidelines.
All subdirectories are not under a top
level ORACLE_HOME directory. There is a
top level directory called ORACLE_BASE
that by default is C:\oracle. If you
install the latest Oracle release on a
computer with no other Oracle software
installed, then the default setting for the
first Oracle home directory is
C:\oracle\orann, where nn is the
latest release number. The Oracle home
directory is located directly under
ORACLE_BASE.
All directory path examples in this guide
follow OFA conventions.
Refer to Oracle9i Database Getting Startingfor Windows for additional information
about OFA compliances and for
information about installing Oracle
products in non-OFA compliant
directories.
Go to the ORACLE_BASE\ORACLE_HOME\rdbms\admin directory.
xxi
xxii
1
Oracle HTTP Server Overview
This chapter describes the Oracle HTTP Server, highlighting the differences
between the Oracle distribution and the open source Apache product on which it is
based. It also explains how to start, stop and restart the server.
Topics discussed are:
■Oracle HTTP Server Features
■Oracle HTTP Server Components
■Oracle HTTP Server Support
■Oracle HTTP Server Management
■Starting, Stopping, and Restarting Oracle HTTP Server
Documentation from the Apache Software Foundation is referenced when
applicable.
Note: Readers using this guide in PDF or hard copy formats will
be unable to access third-party documentation, which Oracle
provides in HTML format only. To access the third-party
documentation referenced in this guide, use the HTML version of
this guide and click the hyperlinks.
Oracle HTTP Server Overview 1-1
Oracle HTTP Server Features
Oracle HTTP Server Features
Oracle HTTP Server is the Web server component of Oracle Database. It is based on
the Apache HTTP Server, version 1.3.28. It is a robust, reliable Web server,
preconfigured to do the following:
■provide a high availability infrastructure integration with Oracle Process
Manager and Notification Server (OPMN), for process management, death
detection and failover for Oracle HTTP Server processes.
See Also:Oracle Application Server 10g High Availability Guide
■provide Dynamic Monitoring Services (DMS) metrics that give runtime
performance statistics for Oracle HTTP Server processes.
See Also: Oracle Application Server 10g Performance Guide
■provide a request ID, which enhances request tracking through various
components by attaching a request ID to each request. This provides more
detailed information, allowing you to see how much time a particular request
spends in any component or layer.
■enable securing of transactions with Secure Sockets Layer (SSL) technology.
See Also:
■Oracle Application Server 10g Security Guide
■Chapter 8, "Managing Security" on page 8-1
■execute Perl scripts in the same process as the Oracle HTTP Server, or as CGI
script.
■access database stored procedures with a PL/SQL engine.
See Also: Oracle Application Server 10g mod_plsql User’s Guide
■enable scripting of HTML pages with PL/SQL code.
1-2 Oracle HTTP Server Administrator’s Guide
Oracle HTTP Server Components
Oracle HTTP Server consists of several components that run within the same
process. These components provide the extensive list of features that Oracle HTTP
Server offers when handling client requests. Following are the major components:
■HTTP Listener: Oracle HTTP Server is based on an Apache HTTP listener to
serve client requests. An HTTP server listener handles incoming requests and
routes them to the appropriate processing utility.
■Modules (mods): Many of the standard Apache modules are included with
Oracle HTTP Server. Oracle also includes several internal modules that are
specific to Oracle Database components.
See Also: "Oracle HTTP Server Modules" on page 1-3 for a
complete list of modules shipped with Oracle HTTP Server.
■Perl Interpreter: A persistent Perl runtime environment embedded in Oracle
HTTP Server through mod_perl.
See Also: Oracle Application Server 10g Concepts for more
information regarding Oracle Database components, and how they
relate to each other.
Oracle HTTP Server Components
Oracle HTTP Server Modules
Table 1–1 identifies the modules shipped with Oracle HTTP Server. Modules extend
the basic functionality of the Web server, and support integration between Oracle
HTTP Server and other Oracle Database components. Note that the list differs from
the Apache open source distribution (given the inclusion of Oracle modules), and
that not all modules are supported by Oracle.
Table 1–1 Oracle HTTP Server Modules
ModuleOracle Support Notes
mod_accessYes
mod_actionsYes
mod_aliasYes
mod_asisNo
mod_authYes
mod_auth_anonYes
Oracle HTTP Server Overview 1-3
Oracle HTTP Server Components
Table 1–1 Oracle HTTP Server Modules (Cont.)
ModuleOracle Support Notes
mod_auth_dbNoDisabled. Not shipped by Oracle.
mod_auth_dbmNo
mod_auth_digest
No
mod_autoindexYes
mod_cern_metaNo
mod_certheadersYes
mod_cgiYes
mod_defineYesUNIX systems only.
mod_digestYes
mod_dirYes
mod_dmsYesOracle module.
mod_envYes
mod_exampleNo
mod_expiresYes
mod_fastcgiYes
mod_headersYes
mod_imapNo
mod_includeYes
mod_infoYe s
Disabled. Experimental MD5 authentication; not
shipped by Oracle.
mod_isapiNoWindows systems only. Not shipped by Oracle
mod_log_agentNoDeprecated.
mod_log_configYes
mod_log_refererYesDeprecated.
mod_mimeYes
mod_mime_magicYes
mod_mmap_staticNo
mod_negotiationYes
1-4 Oracle HTTP Server Administrator’s Guide
Table 1–1 Oracle HTTP Server Modules (Cont.)
ModuleOracle Support Notes
mod_onsintYesOracle module.
mod_osslYesOracle module.
mod_perlYes
mod_plsqlYesOracle module.
mod_proxyYes
mod_rewriteYes
mod_setenvifYes
mod_soYes
mod_spelingYes
mod_statusYes
mod_unique_idYes
mod_userdirYes
mod_usertrackYes
Oracle HTTP Server Support
mod_vhost_aliasYes
Oracle HTTP Server Support
Oracle provides technical support for the following Oracle HTTP Server features
and conditions:
■Modules included in the Oracle distribution, except as noted in the table in
Table 1–1, "Oracle HTTP Server Modules". Modules from any other source,
including the Apache Software Foundation, are not supported by Oracle.
■Problems that can be reproduced within an Apache configuration consisting
only of supported Oracle Apache modules.
■Use of the included Perl interpreter within the supported Apache configuration.
Oracle HTTP Server Overview 1-5
Oracle HTTP Server Management
Oracle HTTP Server Management
You can manage Oracle HTTP Server using opmnctl. It is the command-line utility
for Oracle Process Manager and Notification Server (OPMN) for process
management. It is located in
■UNIX: ORACLE_HOME/opmn/bin
■Windows: ORACLE_HOME\opmn\bin
See Also: Oracle Process Manager and Notification Server
Administrator’s Guide for more information on opmnctl.
Starting, Stopping, and Restarting Oracle HTTP Server
Oracle HTTP Server is managed by Oracle Process Manager and Notification Server
(OPMN). You must always use the opmnctl utility to start, stop and restart Oracle
HTTP Server. Otherwise, the configuration management infrastructure cannot
detect or communicate with the Oracle HTTP Server processes, and problems may
occur.
Note: Do not use the apachectl utility to manage the Oracle
HTTP Server.
To determine the state of Oracle HTTP Server, use the following command:
opmnctl status
The processes are listed with their current state such as “Up” or “Down”.
Starting Oracle HTTP Server
To start Oracle HTTP Server, use the startproc command:
Restarting Oracle HTTP Server performs a graceful restart, which is invisible to
clients. In a graceful restart, on UNIX, a USR1 signal is sent. When the process
receives this signal, it tells the children to exit after processing the current request.
(Children that are not servicing requests exit immediately.)
The parent re-reads the configuration files and re-opens the log files, replacing the
children with new children in accordance with the settings it finds when re-reading
the configuration files. It always observes the process creation settings
(MaxClients, MaxSpareServers, MinSpareServers) specified, and takes the
current server load into account.
Starting, Stopping, and Restarting Oracle HTTP Server
To restart Oracle HTTP Server, use the restartproc command:
See Also: Oracle Process Manager and Notification Server
Administrator’s Guide for more information on opmnctl command
options.
Oracle HTTP Server Overview 1-7
Starting, Stopping, and Restarting Oracle HTTP Server
1-8 Oracle HTTP Server Administrator’s Guide
Oracle HTTP Server Concepts
This chapter introduces you to the Oracle HTTP Server directory structure, and
configuration files, configuration file syntax, modules, and directives.
Topics discussed are:
■Understanding Oracle HTTP Server Directory Structure
■Accessing Configuration Files
■Configuration Files Syntax
■Understanding Modules
■Classes of Directives
■Scope of Directives
■About .htaccess Files
Documentation from the Apache Software Foundation is referenced when
applicable.
2
Note: Readers using this guide in PDF or hard copy formats will
be unable to access third-party documentation, which Oracle
provides in HTML format only. To access the third-party
documentation referenced in this guide, use the HTML version of
this guide and click the hyperlinks.
Oracle HTTP Server Concepts 2-1
Understanding Oracle HTTP Server Directory Structure
Understanding Oracle HTTP Server Directory Structure
Oracle HTTP Server is installed in the ORACLE_HOME/Apache directory on UNIX
or ORACLE_HOME\Apache directory on Windows for configuring modules. For
example, the modplsql folder contains the subdirectories necessary to configure
and run PL/SQL applications.
The Apache directory is located at the top level under the ORACLE_HOME. It
contains subdirectories for configuring modules mod_plsql. It also contains a
subdirectory called Apache, which is the base directory of Oracle HTTP Server.
Accessing Configuration Files
Oracle HTTP Server is configured by placing directives, which are basically
instructions, into text configuration files. Most of the configuration files are located
in:
■UNIX: ORACLE_HOME/Apache/Apache/conf
■Windows: ORACLE_HOME\Apache\Apache\conf
Some of these files are read only once when the server starts or is reloaded, whereas
some files are read every time a related file or directory is requested.
The configuration files which are read only once are called server-wide configuration
files.
See Also: Appendix A, "Oracle HTTP Server Configuration Files"
on page A-1
Configuration Files Syntax
Oracle HTTP Server contains one directive for each line. The back-slash “\” can be
used as the last character on a line to indicate that the directive continues onto the
next line. There must be no other characters or white space between the back-slash
and the end of the line.
Directives in the configuration files are case-insensitive, but arguments to directives
are often case-sensitive. Lines which begin with the character “#” are considered
comments, and are ignored. Comments may not be included on a line after a
configuration directive. Blank lines and white space occurring before a directive are
ignored, so you may indent directives for clarity.
2-2 Oracle HTTP Server Administrator’s Guide
Understanding Modules
Oracle HTTP Server is a modular server. Modules extend the basic functionality of
the Web server, and support integration between Oracle HTTP Server and other
Oracle Database components. Oracle HTTP Server includes Apache modules as
well as Oracle HTTP Server modules.
You can add modules using the LoadModule directive. Following is an example of
LoadModule usage.
LoadModule status_module modules/mod_status.so
See Also: Chapter 7, "Oracle HTTP Server Modules" on page 7-1
Classes of Directives
Table 2–1 classifies directives according to the context in which they can be used:
global, per-server, and per-directory.
Table 2–1 Classes and Directives
ClassContextWhere Used
Classes of Directives
globalserver configurationInside server configuration files, but only outside
per-serverserver configuration,
virtual host
per-directoryserver configuration,
virtual host, directory
Note: In Table 2–1, each class is a subset of the class preceding it.
of container directives (directives such as
VirtualHost that have a start and end
directive).
Inside server configuration files, both outside (for
the main server) and inside VirtualHost
directives.
Everywhere; particularly inside the server
configuration files.
For example, directives from the per-directory class can also be
used in the per-server and global contexts, and directives from the
per-server class can be used in the global context.
Oracle HTTP Server Concepts 2-3
Scope of Directives
Scope of Directives
Directives placed in the main configuration files apply to the entire server. If you
wish to change the configuration for only a part of the server, you can scope your
directives by placing them in specific sections.
The following section discusses the following types of directives:
■Container Directives
■Block Directives
Container Directives
Container directives specify the scope within which directives take effect. The
following container directives are discussed in detail in subsequent sections:
■<Directory>
■<DirectoryMatch>
■<Files>
■<FilesMatch>
■<Location>
■<LocationMatch>
■<Limit>
■<LimitExcept>
■<VirtualHost>
<Directory>
It is used to enclose a group of directives that apply only to the named directory
and subdirectories of that directory. Any directory that is allowed in a directory
context may be used. The directory is either the full path to a directory, or a
wildcard string. In a wildcard string, ? matches any single character and * matches
any sequences of characters. It is important to note that <Directory /> operated
on the whole file system, where as <Directory dir> refers to absolute
directories. <Directory> containers cannot be nested inside each other, but can
refer to directories in the document root that are nested.
2-4 Oracle HTTP Server Administrator’s Guide
Scope of Directives
<DirectoryMatch>
It should be used when specifying regular expressions, instead of using the tilde
form of <Directory> with wildcards in the directory specification. The following
two examples have the same result, matching directories starting with web and
ending with a number from 1 to 9:
The <Files file> and </Files> directives support access control by filename.
It is comparable to the <Directory> and <Location> directives. The directives
given within this section can be applied to any object within a base name (the last
component of the filename) matching the specified file name. <Files> sections are
processed in the order that they appear in the configuration file, after the
<Directory> sections, and .htaccess files are read, but before <Location>
sections. Note that the <Files> directives can be nested inside <Directory>
sections to restrict the portion of the file system to which they apply.
<FilesMatch>
Provides access control by filename, just as the <Files> directive does. However, it
accepts regular expression.
<Location>
Limits the application of the directives within a block to those URLs specified,
rather than to the physical file location like the <Directory> directive.
<Location> sections are processed in the order that they appear in the
configuration file, after the <Directory> sections and .htaccess files are read,
and after the <Files> sections. <Location> accepts wildcard directories and
regular expressions with the tilde character.
Oracle HTTP Server Concepts 2-5
Scope of Directives
<LocationMatch>
Functions in an identical manner to <Location> and you should use it for
specifying regular expressions instead of the tilde form of <Location> with
wildcards in the location specification.
For example:
<LocationMatch "/(extra|special)/data">
matches the URLs that contained the /extra/data or /special/data sub
string.
<Limit>
<Limit method> defines a block according to the HTTP method of the incoming
request. The following example limits the application of the directives that follow
scripts that use the specified method:
<Limit POST PUT OPTIONS>
order deny, allow
deny from all
allow from 127.0.0.192.168
</Limit>
Generally, <Limit> should not be used unless needed. It is useful only for
restricting directives to particular methods. <Limit> is frequently used with other
containers, and it is contained in any of them.
<LimitExcept>
Restrict access controls to all HTTP methods except the named ones.
2-6 Oracle HTTP Server Administrator’s Guide
Block Directives
About .htaccess Files
<VirtualHost>
Oracle HTTP Server has the capabilities to serve many different Web sites
simultaneously. Directives can also be scoped by placing them inside
<VirtualHost> sections, so that they will only apply to requests for a particular
Web site.
Virtual host refers to the practice of maintaining more than one server on one
machine, as differentiated by their apparent hostname. For example, it is often
desirable for companies sharing a Web server to have their own domain, and Web
servers accessible as, for example, www.oracle1.com and www.oracle2.com,
without requiring you to know any extra path information.
Oracle HTTP Server supports both IP-based virtual hosts and name-based virtual
hosts. The latter variant is sometimes also called host-based or non-IP virtual hosts.
Each virtual host can have its own name, IP address, and error and access logs.
Within a <VirtualHost> container, you can set up a large number of individual
servers run by a single invocation of the Oracle HTTP Server. With virtual hosting,
you can specify a replacement set of the server-level configuration directives that
define the main host, and are not allowed in any other container.
Specify a condition which must be true in order for directives within to take effect.
<IfModule> and <IfDefine> are block directives rather than container directives
because they do not limit the scope of the directives they contain. They define
whether Oracle HTTP Server parses the directives inside the block into its
configuration, and the directives are ignored once the server is running.
About .htaccess Files
Oracle HTTP Server enables for decentralized management of configuration
through special files places inside the Web tree. The special files are usually called
.htaccess, but can be specified in the AccessFileName directive. Directives
placed in .htaccess files apply to the directory where you place the file, and all
subdirectories. The .htaccess files follow the same syntax as the main
configuration files. Since .htaccess files are read on every request, changes made
in these files take immediate effect.
The server administrator further controls what directives may be placed in
.htaccess files by configuring the AllowOverride directive in the main
configuration files.
Oracle HTTP Server Concepts 2-7
About .htaccess Files
2-8 Oracle HTTP Server Administrator’s Guide
3
Specifying Server and File Locations
This chapter explains how to set Oracle HTTP Server and server administrator
options, and specifies file locations.
Topics discussed are:
■Setting Server and Administrator Functions
■Specifying File Locations
Documentation from the Apache Software Foundation is referenced when
applicable.
Note: Readers using this guide in PDF or hard copy formats will
be unable to access third-party documentation, which Oracle
provides in HTML format only. To access the third-party
documentation referenced in this guide, use the HTML version of
this guide and click the hyperlinks.
Specifying Server and File Locations 3-1
Setting Server and Administrator Functions
Setting Server and Administrator Functions
The following set basic Oracle HTTP Server and administrator functions. They are
located in the “Main Server Configuration” portion of the httpd.conf file.
See Also: "httpd.conf File Structure" on page A-2
■ServerName
■UseCanonicalName
■ServerAdmin
■ServerSignature
■ServerTokens
■ServerAlias
ServerName
Enables the server to set a hostname that can be used to create redirection URLs,
through which you can access directories without having to use a “/” at the end.
See Also: “ServerName directive” in the Apache Server
documentation.
UseCanonicalName
Determines which hostname and port to use when redirecting the URL to the same
server.
■on: This is the default setting. Server uses the hostname and port values set in
ServerName and Port.
■off: Server uses the hostname and port that you specify in the request.
See Also: “UseCanonicalName directive” in the Apache Server
documentation.
3-2 Oracle HTTP Server Administrator’s Guide
ServerAdmin
ServerSignature
Setting Server and Administrator Functions
Creates an email address that is included with every default error message that
clients encounter. It is useful to create a separate email address for this.
See Also: “ServerAdmin directive” in the Apache Server
documentation.
Enables the server to recognize which server, among the various proxies, created
the returned response, such as an error message.
■on: Server creates a footer to the returned document that includes information
such as ServerName and server version number. This is the default.
■email: Server creates an additional “mailto:” reference to the ServerAdmin
of the document.
■off: Footer and “mailto:” reference are not created.
See Also: “ServerSignature directive” in the Apache Server
documentation.
ServerTokens
ServerAlias
Controls server information which is returned to clients, such as in error messages.
This information includes a description of the generic operating system-type of the
server, and compiled-in modules.
■min(imal): provides information such as server name and version.
■OS: provides information such as server name, version and operating system.
■full: provides information such as server name, version, operating system,
and complied modules.
See Also: “ServerTokens directive” in the Apache Server
documentation.
Sets alternate names for the current virtual host.
See Also: “ServerAlias directive” in the Apache Server
documentation.
Specifying Server and File Locations 3-3
Specifying File Locations
Specifying File Locations
The following directives to control the location of various server files. They are
located in the “Global Environment” of the httpd.conf file.
See Also: "httpd.conf File Structure" on page A-2
■CoreDumpDirectory
■DocumentRoot
■ErrorLog
■LockFile
■PidFile
■ScoreBoardFile
■ServerRoot
CoreDumpDirectory
Specifies the directory in which the server dumps core. The default is the
ServerRoot directory. This directive is applicable to UNIX only.
See Also: “CoreDumpDirectory directive” in the Apache
Server documentation.
DocumentRoot
Sets the directory from which httpd serves files. Unless matched by a directive like
Alias, the server appends the path from the requested URL to the document root
to make the path to the document for static content.
See Also: “DocumentRoot directive” in the Apache Server
documentation.
3-4 Oracle HTTP Server Administrator’s Guide
ErrorLog
LockFile
PidFile
Specifying File Locations
Sets the name of the file to which the server notes any errors it encounters. If the
name of the file does not begin with a slash (/), then it is assumed to be relative to
the ServerRoot. If the name of the file begins with a pipe (|), then it is assumed to
be a command to spawn to handle the error log.
See Also: “ErrorLog directive” in the Apache Server
documentation.
Sets the path to the lockfile used when Oracle HTTP Server is compiled with either
USE_FCNTL_SERIALIZED_ACCEPT or USE_FLOCK_SERIALIZED_ACCEPT. It is
recommended that default value be used. The main reason for changing it is if the
logs directory is NFS mounted, since the lockfile must be stored on a local disk.
See Also: “LockFile directive” in the Apache Server
documentation.
Enables you to set and change the location of the PID file to which the server
records the process identification number. If the filename does not begin with a
slash (/), then it is assumed to be relative to the ServerRoot.
ScoreBoardFile
See Also: “PidFile directive” in the Apache Server
documentation.
Required in some architectures to set a file that the server uses to communicate
between the parent and children processes. To verify if your architecture requires a
scoreboard file, run Oracle HTTP Server and see if it creates the file named by the
directive. If your architecture requires it then you must ensure that this file is not
used at the same time by more than one invocation of the server.
See Also: “ScoreBoardFile directive” in the Apache Server
documentation.
Specifying Server and File Locations 3-5
Specifying File Locations
ServerRoot
Specifies the directory that contains the conf and logs subdirectories. If the server
is started with the -f option, then you will have to specify ServerRoot.
See Also: “ServerRoot directive” in the Apache Server
documentation.
3-6 Oracle HTTP Server Administrator’s Guide
Managing Server Processes
This chapter provides an overview of the Oracle HTTP Server processes, and
provides information on how to regulate, and monitor these processes.
Topics discussed are:
■Oracle HTTP Server Processing Model
■Handling Server Processes
■Limiting the Number of Processes and Connections
■Getting Information about Processes
Documentation from the Apache Software Foundation is referenced when
applicable.
Note: Readers using this guide in PDF or hard copy formats will
be unable to access third-party documentation, which Oracle
provides in HTML format only. To access the third-party
documentation referenced in this guide, use the HTML version of
this guide and click the hyperlinks.
4
Managing Server Processes 4-1
Oracle HTTP Server Processing Model
Oracle HTTP Server Processing Model
Once Oracle HTTP Server is started, the system is ready to listen for and respond to
http(s) requests. The request processing model is different on UNIX and Windows.
After installation, the main httpd parent process, as well as the child processes, run
as the user who installed Oracle Database. The User and Group directive are used
to set the privileges for the child processes. These directives are ignored if you are
not running as root.The child processes must be able to read all the content that
will be served.
Running Oracle HTTP Server as Root
On UNIX, you will hare to run as root if you want to run on ports less than 1024.
In order to run Oracle HTTP Server as root, perform the following steps:
1. Shutdown Oracle HTTP Server using the following command:
On Windows, Oracle HTTP Server launches a single parent process and one child
process. The child process creates multiple threads that listen and respond to client
requests.
You must decide how you want to set Oracle HTTP Server to handle processes or
threads.
4-2 Oracle HTTP Server Administrator’s Guide
Additional Security Considerations
For additional security on UNIX, you can change the user to “nobody”. Be sure that
the child processes can accomplish their tasks as the user “nobody”. Change all
static content, such as the ORACLE_HOME/Apache/Apache/htdocs directory on
UNIX or ORACLE_HOME\Apache\Apache\htdocs on Windows, so that all the
files are readable, but ideally not writable by the user “nobody”. Also, verify that all
the CGI and FastCGI programs can be run by user “nobody”.
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/Apache/modplsql/conf.
See Also: "PlsqlDatabasePassword" on page 7-36 on instructions
on performing the obfuscation.
If your PL/SQL application is using the file-system caching functionality in mod_plsql, then the httpd processes should have read and write privileges to the cache
directory through the parameter PlsqlCacheDirectory in ORACLE_
HOME/Apache/modplsql/conf/cache.conf on UNIX or ORACLE_
HOME\Apache\modplsql\conf\cache.conf on Windows. By default, thisparameter points to ORACLE_HOME/Apache/modplsql/cache on UNIX or
ORACLE_HOME\Apache\modplsql\cache on Windows.
Oracle HTTP Server Processing Model
Finally, given that the cached content might contain sensitive data, the final contents
of the file-system cache should be protected. So, although Oracle HTTP Server
might run as “nobody”, access to the system as this user should be well-protected.
See Also: "mod_plsql" on page 7-19
Managing Server Processes 4-3
Handling Server Processes
Handling Server Processes
Use the following directives to manage the server processes:
■ServerType
■Group
■User
ServerType
Provides the following two options, both being applicable on UNIX only:
inetd: Starts up a new child process every time a request comes in. The program
exits once the request is dealt with. This setting eliminates the option of having
several child processes in waiting, making it slower and expensive, but more secure.
standalone: Enables several waiting child processes, and requires the server to be
started only once. It is the default and recommended setting for a busy Web site.
You must specify the User and Group under which the servers answer requests.
See Also: “ServerType directive” in the Apache Server
documentation.
Group
Specifies the group under which the server answers requests. In order to use this
directive, the standalone server must be run initially as root. It is recommended that
you create a new group for running the server. This is applicable to UNIX only.
See Also: “Group directive” in the Apache Server
documentation.
User
Specifies the user ID to which the server answers requests. Run the standalone
server as root to use this directive.You should have privileges to access files that
are available for everyone, and should not be able to execute code which is not
meant for httpd requests. It is recommended that you set up a new user for running
the server. This is applicable to UNIX only.
See Also: “User directive” in the Apache Server documentation.
4-4 Oracle HTTP Server Administrator’s Guide
Limiting the Number of Processes and Connections
Limiting the Number of Processes and Connections
The following directives control and limit the number of child processes or
simultaneous requests. They are located in the “Global Environment” of the
httpd.conf file.
See Also: "httpd.conf File Structure" on page A-2
■StartServers
■ThreadsPerChild
■MaxClients
■MaxRequestsPerChild
■MaxSpareServers
■MinSpareServers
StartServers
Sets the number of child server processes created when Oracle HTTP Server is
started. The default is set at 5. This is applicable to UNIX only.
ThreadsPerChild
Controls the maximum number of child threads handling requests. The default is
set at 50. This is applicable to Windows only.
MaxClients
Limits the number of requests that can be dealt with at one time. The default and
recommended value is 150. This is applicable to UNIX only.
See Also: “StartServers directive” in the Apache Server
documentation.
See Also: “ThreadsPerChild directive” in the Apache Server
documentation.
See Also: “MaxClients directive” in the Apache Server
documentation.
Managing Server Processes 4-5
Limiting the Number of Processes and Connections
MaxRequestsPerChild
Controls the number of requests a child process handles before it dies. This value
should be specified again if the machine is rebooted. If you select the value to be 0,
which is the default, then the process will never die. This is applicable to UNIX
only.
See Also: “MaxRequestsPerChild directive” in the Apache
Server documentation.
MaxSpareServers
Sets the maximum number of idle child server processes. An idle process is one
which is running, but not handling a request. The parent process kills off idle child
processes that exceed the value set for this directive. The default is set at 10. This is
applicable to UNIX only.
See Also: “MaxSpareServers directive” in the Apache Server
documentation.
MinSpareServers
Sets the minimum number of idle child server processes. An idle process is one
which is running but not handling a request. The parent process will create new
children at the maximum rate of one process for each second if there are fewer
processes running. The default is set at 5. This is applicable to UNIX only.
See Also: “MinSpareServers directive” in the Apache Server
documentation.
4-6 Oracle HTTP Server Administrator’s Guide
Getting Information about Processes
There are several ways to monitor Oracle HTTP Server processes.
1. Use the performance monitor on Windows, or the ps utility on UNIX.
See Also: Oracle Application Server 10g Performance Guide and your
operating system documentation for more information.
2. Use mod_status for server status. By default, it is available from localhost only.
Getting Information about Processes
Managing Server Processes 4-7
Getting Information about Processes
4-8 Oracle HTTP Server Administrator’s Guide
Managing the Network Connection
This chapter provides information about specifying IP addresses and ports, and
managing server interaction, and network connection persistence.
Topics discussed are:
■Specifying Listener Ports and Addresses
■Managing Interaction Between Server and Network
■Managing Connection Persistence
■Configuring Reverse Proxies and Load Balancers
Documentation from the Apache Software Foundation is referenced when
applicable.
Note: Readers using this guide in PDF or hard copy formats will
be unable to access third-party documentation, which Oracle
provides in HTML format only. To access the third-party
documentation referenced in this guide, use the HTML version of
this guide and click the hyperlinks.
5
Managing the Network Connection 5-1
Specifying Listener Ports and Addresses
Specifying Listener Ports and Addresses
When Oracle HTTP Server is started, by default, it listens for requests on port 7777
(non-SSL). If port 7777 is occupied, Oracle HTTP Server listens on the next available
port number between a range of 7777-7877. Thus, if port 7777 is busy, it would listen
on port 7778, and so on.
A file named setupinfo.txt is automatically generated in ORACLE_
HOME/Apache/Apache on UNIX or ORACLE_HOME\Apache\Apache on
Windows.It contains port information for Oracle HTTP Server. This file is
generated at install time, and is not updated thereafter. If you restart Oracle HTTP
Server, the information in this file becomes inaccurate.
You can change the Oracle HTTP Server listener port (SSL and non-SSL) after
installation. If you make a port change, then you have to also update other
components to use the new port number.
See Also: Oracle Application Server 10g Administrator’s Guide for
complete instruction.
You can specify the server to listen to more than one port, selected addresses, or a
combination. The following directives, located in the “Global Environment” of the
httpd.conf file, specify listener ports and addresses. Note that BindAddress
and Port can be used only once. Apache group recommends the use of Listen
instead.
■BindAddress
■Listen
■Port
See Also: "httpd.conf File Structure" on page A-2
5-2 Oracle HTTP Server Administrator’s Guide
BindAddress
Port
Specifying Listener Ports and Addresses
Restricts the server to listen to a single IP address. If the argument to this directive
is *, then it listens to all IP addresses. This directives has been deprecated. Listen
offers similar functionality.
See Also: “BindAddress directive” in the Apache Server
documentation.
Specifies the port of the listener, if no Listen or BindAddress are present. If
Listen is present, the Port value becomes the default port value that is used
when Oracle HTTP Server builds URLs, or other references to itself. Usually, the
values of Port and Listen should match, unless Oracle HTTP Server is fronted by
a caching, or proxy server. Then, you can set Port to be the port that is being used
by the front end server, and Listen to the port that Oracle HTTP Server is actually
listening to. By doing this, redirects or other URLs generated by Oracle HTTP
Server point to the front-end server rather than directly to Oracle HTTP Server.
See Also: “Port directive” in the Apache Server documentation.
Listen
Specifies an IP port that Oracle HTTP Server should listen on. Multiple Listen
directives can be used to listen on multiple ports. If present, this value will override
the value of Port. Accordingly, if you have a Port value of 7777 and a Listen
value of 7778, then Oracle HTTP Server only listens on one port, 7778.
See Also: “Listen directive” in the Apache Server
documentation.
Managing the Network Connection 5-3
Managing Interaction Between Server and Network
Managing Interaction Between Server and Network
The following directives are used to specify how the server interacts with the
network. They are located in the “Global Environment” of the httpd.conf file.
■ListenBackLog
■SendBufferSize
■TimeOut
See Also: "httpd.conf File Structure" on page A-2
ListenBackLog
Specifies the maximum length of the queue of pending connections. This is useful if
the server is experiencing a TCP SYN overload, which causes numerous new
connections that open up but do not complete the task.
See Also: “ListenBackLog directive” in the Apache Server
documentation.
SendBufferSize
Increases the TCP buffer size to the number of bytes specified, thereby improving
performance.
See Also: “SendBufferSize directive” in the Apache Server
documentation.
TimeOut
Sets the maximum time, in seconds, that the server waits for the following:
■The total amount of time it takes to receive a GET request.
■The amount of time between receipt of TCP packets on a POST or PUT request.
■The amount of time between ACKs on transmissions of TCP packets in
responses.
The default is set at 300 seconds.
See Also: “TimeOut directive” in the Apache Server
documentation.
5-4 Oracle HTTP Server Administrator’s Guide
Managing Connection Persistence
The following directives determine how the server handles persistent connections.
They are located in the “Global Environment” of the httpd.conf file.
■KeepAlive
■KeepAliveTimeout
■MaxKeepAliveRequests
See Also:
■Oracle Application Server 10g Performance Guide
■"httpd.conf File Structure" on page A-2
KeepAlive
Enables a single connection to accept multiple requests from the same client. The
default is set to “On”.
See Also: “KeepAlive directive” in the Apache Server
documentation.
Managing Connection Persistence
KeepAliveTimeout
Sets the number of seconds the server waits for a subsequent request before closing
a KeepAlive connection. Once a request has been received, the timeout value
specified by the TimeOut directive applies. The default is set at 15 seconds.
See Also: “KeepAliveTimeout directive” in the Apache Server
documentation.
MaxKeepAliveRequests
Limits the number of requests allowed for each connection when KeepAlive is on.
If it is set to “0”, unlimited requests will be allowed. The default is set at 100.
See Also: “MaxKeepAliveRequests directive” in the Apache
Server documentation.
Managing the Network Connection 5-5
Configuring Reverse Proxies and Load Balancers
Configuring Reverse Proxies and Load Balancers
By default, Oracle Database installs using the local hostname as set up by
ServerName directive in Oracle HTTP Server. Most Web sites tend to have a
specific hostname or domain name for their Web server. However, this is not
possible out of the box because with the ServerName directive, Oracle HTTP
Server is instantiated with the local host.
Example 5–1 Using Reverse Proxies and Load Balancers with Oracle HTTP Server
Domain Name: www.oracle.com:80 123.456.7.8 (hosted on a reverse proxy, load
balancer, or firewall)
Host Name of Oracle Database Host: server.oracle.com 123.456.7.9
ServerName and Port of Oracle Database Host: server.oracle.com:7777
Make the following changes in the httpd.conf file:
Port 80
Listen 7777
Listen 80
# Virtual Hosts
# This section is mandatory for URLs that are generated by
# the PL/SQL packages of the Oracle Portal and various other components
# These entries dictate that the server should listen on port
# 7777, but will assert that it is using port 80, so that
# This will create URLs that are valid for the browser since
# the browser does not directly see the host server.oracle.com.
NameVirtualHost 123.456.7.9:7777
<VirtualHost server.oracle.com:7777>
ServerName www.oracle.com
Port 80
</VirtualHost>
# Since the previous virtual host entry will cause all links
# generated by the Oracle Portal to use port 80, the server.company.com
# server needs to listen on 80 as well since the Parallel Page
# Engine will make connection requests to Port 80 to request the
# portlets.
NameVirtualHost 123.456.7.9:80
<VirtualHost server.oracle.com:80>
ServerName www.oracle.com
Port 80
<VirtualHost>
5-6 Oracle HTTP Server Administrator’s Guide
Configuring Reverse Proxies and Load Balancers
See Also: "Running Oracle HTTP Server as Root" on page 4-2 for
instructions on running Oracle HTTP Server with ports lesser than
1024.
Managing the Network Connection 5-7
Configuring Reverse Proxies and Load Balancers
5-8 Oracle HTTP Server Administrator’s Guide
Configuring and Using Server Logs
This chapter discusses Oracle Diagnostic Logging, log formats, and describes
various log files and their locations.
Topics discussed are:
■Using Oracle Diagnostic Logging
■Specifying Log Formats
■Specifying Log Level
■Specifying Log Files
Documentation from the Apache Software Foundation is referenced when
applicable.
Note: Readers using this guide in PDF or hard copy formats will
be unable to access third-party documentation, which Oracle
provides in HTML format only. To access the third-party
documentation referenced in this guide, use the HTML version of
this guide and click the hyperlinks.
6
Configuring and Using Server Logs 6-1
Using Oracle Diagnostic Logging
Using Oracle Diagnostic Logging
Oracle offers a new method for reporting diagnostic messages. This new method,
Oracle Diagnostic Logging (ODL), presents a common format for diagnostic
messages and log files, and a mechanism for correlating all diagnostic messages
from various components across Oracle Database. Using ODL, each component logs
messages to its own private local repository. A tool called LogLoader collects
messages from each repository and loads them into a common repository where
messages can be viewed as a single log stream, or analyzed in different ways.
You can view Oracle Database diagnostic log files using a text editor.
See Also: Oracle Application Server 10g Administrator’s Guide for
detailed information regarding Oracle Diagnostic Logging.
Overview
Oracle HTTP Server enables you to choose the format in which you want to
generate log messages. You can either continue to generate log messages in the
legacy Apache message format, or generate log messages using ODL, which
complies with the new Oracle-wide standards for generating log messages.
Configuring Oracle HTTP Server
To enable Oracle HTTP Server to use ODL, enter the directives specified in the
subsequent section in the httpd.conf file. Oracle recommends that you enter the
directives before any modules are loaded (LoadModule directive) in the
httpd.conf file so that module-specific logging severities are in effect before
modules have the opportunity to perform any logging.
OraLogMode apache | oracle
Enables you to switch between ODL and legacy Apache logging facility.
Enables you to set message severity. The message severity specified with this
directives is interpreted as the lowest message severity that is desired, and all
messages of that severity level and higher will be logged. OraLogSeverity may
be specified multiple times. It can be specified globally (no module_name) and once
for each module for which a module-specific logging severity is desired.
module_name
This argument is the internal name of a module, as it appears in the module
structure. The <IfModule> directive also makes use of this internal name. The
module structure derives the module name from the value of the _FILE_ macro,
without path prefix, of the file which defines the module structure. If a module
name is not supplied, the OraLogSeverity directive is applied globally.
If the module name is specified, then the directive overrides the global directive
value of all the messages originating from the specified module. Specifying a
module name for a module that does not get loaded generates an error.
msg_type
Message types may be specified in upper or lower case, but will appear in the
message output in upper case. This parameter must be of one of the following
values:
■INTERNAL_ERROR
■ERROR
■WARNING
■NOTIFICATION
■TRACE
msg_level
This parameter must be an integer in the range of 1-32.
Configuring and Using Server Logs 6-3
Using Oracle Diagnostic Logging
Table 6–1 lists some examples of OraLogSeverity.
Table 6–1 Examples of OraLogSeverity
OraLogSeverity ExampleAction Taken
OraLogSeverity INTERNAL_
ERROR:10
OraLogSeverity WARNING:7
OraLogSeverity WARNING
Default
If a message level is not specified, then the level defaults to the lowest severity. If
the entire directive is omitted, then the value of the global Apache LogLevel
directive is used and translated to the corresponding Oracle message type and the
lowest level within the corresponding range, as listed in Table 6–2:
Logs all messages of type “internal error” of levels 1-10
Logs all messages of type “internal error” of all levels
Logs all messages of type “error” of all levels
Logs all messages of type “warning” of levels 1-7
For messages from other sources:
■Logs all messages of type “internal error” of all levels
■Logs all messages of type “error” of all levels
■Logs all messages of type “warning” of all levels
Table 6–2 Apache Log Level and Corresponding Oracle Message Type
Apache Log LevelOracle Message Type
emergINTERNAL_ERROR:16
alertINTERNAL_ERROR:32
critERROR:16
errorERROR:32
warnWARNING:32
noticeNOTIFICATION:16
infoNOTIFICATION:32
debugTRACE:32
See Also: "Specifying Log Level" on page 6-6
6-4 Oracle HTTP Server Administrator’s Guide
OraLogDir <bus stop dir>
Specifies the path to the directory which contains all log files. This directory must
exit.
Default:
■UNIX: ORACLE_HOME/Apache/Apache/logs/oracle
■Windows: ORACLE_HOME\Apache\Apache\logs\oracle
Specifying Log Formats
LogFormat specifies the information included in the log file, and the manner in
which it is written. The default format is the Common Log Format (CLF). The CLF
format is: host ident authuser date request status bytes
■host: This is the client domain name or its IP number.
■ident: If IdentityCheck is enabled and the client machine runs identd,
then this is the client identity information.
■authuser: This is the user ID for authorized user.
■date: This is the date and time of the request in the
<day/month/year:hour:minute:second> format.
Specifying Log Formats
■request: This is the request line, in double quotes, from the client.
■status: This is the three-digit status code returned to the client.
■bytes: This is the number of bytes, excluding headers, returned to the client.
Configuring and Using Server Logs 6-5
Specifying Log Level
Specifying Log Level
Table 6–3 lists all the different logging levels, their descriptions, and, example
messages:
Table 6–3 Logging Level
Logging Level DescriptionExample Message
EmergencyEmergencies- system is
unusable.
AlertAction must be taken
immediately.
CriticalCritical conditions.“socket: Failed to get a socket, exiting
ErrorError conditions.“Premature end of script headers”
WarningWarning conditions.“child process 1234 did not exit,
NoticeNormal but significant
condition.
InformationInformational messages that
describe possible problems and
possible solutions to those
problems.
DebugDebug-level messages.“Opening config file...”
“Child cannot open lock file. Exiting.”
“getpwuid: couldn’t determine user
name from uid”
child”
sending another SIGHUP”
“httpd: caught SIGBUS, attempting to
dump core in...”
“Server seems busy, (you may need to
increase StartServers, or
Min/MaxSpareServers)...”
6-6 Oracle HTTP Server Administrator’s Guide
Specifying Log Files
The log files are discussed in the subsequent sections:
■Access Log
■CustomLog
■Error Log
■PID File
■Piped Log
■Rewrite Log
■Script Log
■SSL Log
■Transfer Log
It is important to periodically rotate the log files by moving or deleting existing logs
on a moderately busy server. For this, the server must be restarted after the log files
are moved or deleted so that new log files are opened.
Specifying Log Files
Access Log
CustomLog
See Also: “Log Rotation” in the Apache Server documentation.
The server access log records all requests processed by the server. The location and
content of the access log is controlled by the CustomLog directive. The LogFormat
directive can be used to simplify the selection of the contents of the logs.
See Also: “Access Log” in the Apache Server documentation.
The CustomLog directive is used to log requests to the server. A log format is
specified, and the logging can optionally be made conditional on request
characteristics using environment variables.
See Also: “CustomLog directive” in the Apache Server
documentation.
Configuring and Using Server Logs 6-7
Specifying Log Files
Error Log
PID File
The server sends diagnostic information and records error messages to a log file
This filename can be changed with the PidFile directive. The process ID is for use
by the administrator for restarting and terminating the daemon. If the process dies
(or is killed) abnormally, then it is necessary to kill the children httpd processes.
See Also: “Pid File” in the Apache Server documentation.
Piped Log
Oracle HTTP Server is capable of writing error and access log files through a pipe to
another process, rather than directly to file. This increases the flexibility of logging,
without adding code to the main server. In order to write logs to a pipe, replace the
file name with the pipe character “|”, followed by the name of the executable which
should accept log entries on its standard input. Oracle HTTP Server starts the
piped-log process when the server starts, and restarts it if it crashes while the server
is running.
See Also: “Piped Log” in the Apache Server documentation.
6-8 Oracle HTTP Server Administrator’s Guide
Rewrite Log
Script Log
SSL Log
Specifying Log Files
Rewrite Log is necessary for debugging when mod_rewrite is used. This log file
produces a detailed analysis of how the rewriting engine transforms requests. The
level of detail is controlled by the RewriteLogLevel directive.
See Also: “Rewrite Log” in the Apache Server documentation.
Script Log enables you to record the input to and output from the CGI scripts. This
should only be used in testing, and not for live servers.
See Also: “Script Log” in the Apache Server documentation.
When Oracle HTTP Server starts in SSL mode, it creates ssl_engine_log and
ssl_request_log in
■UNIX: ORACLE_HOME/Apache/Apache/logs
■Windows: ORACLE_HOME\Apache\Apache\logs
Transfer Log
ssl_engine_log tracks SSL and protocol issues, where as ssl_request_log
records user activity. Use the SSLLogFile directive to control output.
See Also: "Enabling SSL" on page 8-10
Transfer Log specifies the file in which to store the log of accesses to the site. If it is
not explicitly included in the conf file, then no log is generated. The server
typically logs each request to a transfer file located, by default, in
The filename can be set using a CustomLog directive.
Configuring and Using Server Logs 6-9
Specifying Log Files
6-10 Oracle HTTP Server Administrator’s Guide
7
Oracle HTTP Server Modules
This chapter describes the modules (mods) included in the Oracle HTTP Server.
The modules extend the basic functionality of the Web server, and support
integration between Oracle HTTP Server and other Oracle Database components.
Documentation from the Apache Software Foundation is referenced when
applicable.
Note: Readers using this guide in PDF or hard copy formats will
be unable to access third-party documentation, which Oracle
provides in HTML format only. To access the third-party
documentation referenced in this guide, use the HTML version of
this guide and click the hyperlinks.
Oracle HTTP Server Modules 7-1
List of Modules
List of Modules
Table 7–1 lists all the Oracle HTTP Server modules discussed in this chapter.
Controls access to the server based on characteristics of a request, such as hostname
or IP address.
See Also: Module mod_access in the Apache Server
documentation.
Enables execution of CGI scripts based on file type or request method.
See Also: Module mod_actions in the Apache Server
documentation.
Enables manipulation of URLs in processing requests. It provides mapping between
URLs and filesystem paths, and URL redirection capabilities.
See Also: Module mod_alias in the Apache Server
documentation.
mod_asis
mod_auth
Enables sending files that contain their own HTTP headers. It is not supported by
Oracle.
See Also: Module mod_asis” in the Apache Server
documentation.
Enables user authentication with files based user lists.
See Also: Module mod_auth in the Apache Server
documentation.
Oracle HTTP Server Modules 7-3
mod_auth_anon
mod_auth_anon
Enables anonymous user access to protected areas (similar to anonymous FTP,
where the email addresses can be logged).
mod_auth_db
Uses Berkeley DB files to provide user authentication.
This module is disabled in the Oracle HTTP Server and is not supported by Oracle.
mod_auth_dbm
Uses DBM files to provide user authentication.
This module is not supported by Oracle.
mod_auth_digest
Uses MD5 Digest Authentication to provide user authentication.
See Also: Module mod_auth_anon in the Apache Server
documentation.
This module is not supported by Oracle.
mod_autoindex
Generates directory indexes automatically.
See Also: Module mod_autoindex in the Apache Server
documentation.
mod_cern_meta
Emulates CERN (Conseil Europeen pour le Recherche Nucleaire) HTTPD metafile
semantics. Metafiles are additional HTTP headers that can be produced for each file
the server accesses, in addition to the typical set.
This module is not supported by Oracle.
7-4 Oracle HTTP Server Administrator’s Guide
mod_certheaders
Enables reverse proxies that terminate SSL connections in front of Oracle HTTP
Server to transfer information regarding SSL connection, such as SSL client
certificate information, to Oracle HTTP Server, and applications running behind
Oracle HTTP Server. This information is transferred from the reverse proxy to
Oracle HTTP Server using HTTP headers. The information is transferred from the
headers to the standard CGI environment variable, which mod_ossl or mod_ssl
populates if the SSL connection is terminated by Oracle HTTP Server. It also enables
certain requests to be treated as HTTPS requests even though they are received
through HTTP.
Perform the following steps to configure mod_certheaders:
1. Configure Oracle HTTP Server to load mod_certheaders. To do this, add a
LoadModule directive to httpd.conf file.
■UNIX: LoadModule certheaders_module libexec/mod_
■Windows: LoadModule certheaders_module
2. Specify which headers should be translated to CGI environment variables. This
can be achieved by using the AddCertHeader directive. This directive takes a
single argument, which is the CGI environment variable that should be
populated from a HTTP header on incoming requests. For example, to populate
the SSL_CLIENT_CERT CGI environment variable, add the following line to
httpd.conf:
mod_certheaders
certheaders.so
modules/ApacheModuleCertHeaders.dll
AddCertHeader SSL_CLIENT_CERT
The AddCertHeader directive can be a global setting if it is placed in the base
virtual server section of httpd.conf. It can be specific to a single virtual host
by placing it within a virtual host container, or it can be specific to a set of URIs
by placing it within a <Directory> or <Location> container directive within
httpd.conf. The combination of these directives are additive, so that for a
given URI, all directives that are specific to that URI will be added to any that
are specific to that request’s virtual host, which will be added to any that is
defined for that base virtual host.
Oracle HTTP Server Modules 7-5
mod_certheaders
Table 7–2 lists all the supported CGI environment variables with their
corresponding HTTP header names.
Table 7–2 CGI Environment Variables with Corresponding Header Names
mod_certheaders can be used to instruct Oracle HTTP Server to treat certain
requests as if they were received through HTTPS even though they were
received through HTTP. This is useful when Oracle HTTP Server is front-ended
by a reverse proxy or load balancer, which acts as a termination point for SSL
requests, and forwards the requests to Oracle HTTP Server through HTTPS.
For load balancers, mod_certheaders must be explicitly configured to
determine which requests should be treated as HTTPS requests. To do this, use
the following directive:
SimulateHttps on
SimulateHttps can be embedded within a virtual host, such as:
<VirtualHost localhost:7777>
SimulateHttps on
.
.
.
</VirtualHost>
Oracle HTTP Server Modules 7-7
mod_cgi
mod_cgi
mod_define
This tells mod_certheaders to treat every request handled by this virtual host
as HTTPS, or the directive can be placed within a <LocationMatch>,
<Directory>, or <DirectoryMatch> directive container such as:
<Location /foo/>
SimulateHttps on
</Location>
This limits it to URLs starting with /foo/.
Enables the server to run CGI scripts.
See Also: Module mod_cgi in the Apache Server documentation.
Enables the Define directive, which defines a variable that can be expanded on
any configuration line. The Define directive has the status Extension, which
means that it is not compiled into the server by default.
This module requires the Extended API (EAPI). Oracle HTTP Server always has
EAPI-enabled.
This module is available on UNIX systems only.
mod_digest
Uses an older version of the MD5 Digest Authentication specification than that used
in mod_auth_digest to provide user authentication. mod_digest probably only
works with older browsers.
See Also: Module mod_digest in the Apache Server
documentation.
7-8 Oracle HTTP Server Administrator’s Guide
mod_dir
mod_dms
mod_example
Enables the server to perform slash (/) redirects. Directories must contain a trailing
slash. If a request for a URL without a trailing slash is received, mod_dir redirects
the request to the same URL followed by a trailing slash. For example:
http://myserver/documents/mydirectory
is redirected to
http://myserver/documents/mydirectory/
See Also: Module mod_dir in the Apache Server documentation.
Enables you to monitor performance of site components with Oracle’s Dynamic
Monitoring Service (DMS).
See Also:Oracle Application Server 10g Performance Guide
mod_env
Enables you to control the environment for CGI scripts and SSI (Server Side
Includes) pages by passing, setting, and unsetting environment variables.
mod_example
Provides examples and guidance on how to write modules using the Apache API.
When implemented, it demonstrates module callbacks triggered by the server.
This module is not supported by Oracle.
See Also: Module mod_env in the Apache Server documentation.
Oracle HTTP Server Modules 7-9
mod_expires
mod_expires
mod_fastcgi
mod_headers
Enables the server to generate Expires HTTP headers, which provide information to
the client about document validity. Documents are served from the source if, based
on the expiration criteria, the cached copy has expired.
See Also: Module mod_expires in the Apache Server
documentation.
Supports the FastCGI protocol, which enables you to maintain a pool of running
servers for CGI applications, thereby eliminating start-up and initialization
overhead.
See Also: Module mod_fastcgi in the Apache Server
documentation.
Enables you to merge, replace, or remove HTTP response headers.
See Also: Module mod_headers in the Apache Server
documentation.
mod_imap
Enables server-side image map processing.
This module is not supported by Oracle.
mod_include
Provides a filter that processes documents for SSI (Server Side Includes) directives.
See Also: Module mod_include in the Apache Server
documentation.
7-10 Oracle HTTP Server Administrator’s Guide
mod_info
Summarizes the entire server configuration, including all installed modules and
directive settings.
mod_isapi
Enables serving of Internet Server extensions (such as .dll modules).
It is available on the Windows platform only, and is not supported by Oracle.
mod_log_agent
Enables logging of client user agents. It is deprecated; you should use mod_log_
config instead of mod_log_agent.
This module is not supported by Oracle.
mod_log_referer
See Also: Module mod_info in the Apache Server
documentation.
mod_log_config
Provides configurable, customizable logging of server activities. You can choose the
log format, and select or exclude individual requests for logging, based on
characteristics of the requests.
mod_log_referer
Enables logging of documents that reference documents on the server. It is
deprecated; you should use mod_log_config instead of mod_log_referer.
See Also: Module mod_log_config in the Apache Server
documentation.
See Also: Module mod_log_referer in the Apache Server
documentation.
Oracle HTTP Server Modules 7-11
mod_mime
mod_mime
Enables the server to determine the type of a file from its filename, and associate
files with handlers for processing.
mod_mime_magic
Enables the server to determine the MIME type of a file by examining a few bytes of
its content. It is used in cases when mod_mime cannot determine a file type. Make
sure that mod_mime appears before mod_mime_magic in the configuration file, so
that mod_mime processes the files first.
mod_mmap_static
Maps a list of files into memory, useful for frequently requested files that are not
changed often.
See Also: Module mod_mime in the Apache Server
documentation.
See Also: Module mod_mime_magic in the Apache Server
documentation.
This module is not supported by Oracle.
mod_negotiation
Enables the server for content negotiation (selection of documents based on the
client’s capabilities).
See Also: Module mod_negotiation in the Apache Server
documentation.
7-12 Oracle HTTP Server Administrator’s Guide
mod_onsint
This module provides integration support with Oracle Notification Service (ONS)
and OPMN (Oracle Process Manager and Notification Server).
Benefits of mod_onsint
mod_onsint provides the following functionality:
■Provides a subscription mechanism for ONS notifications within Oracle HTTP
Server. This is particularly important on UNIX where Oracle HTTP Server
employs a multi-process architecture. In such an architecture, it is not feasible to
have an ONS subscriber in each process since there are up to 8192 processes
that comprise a single Oracle HTTP Server instance. Instead, mod_onsint
provides a single process that receives notification for all modules within an
Oracle HTTP Server instance.
■Publishes PROC_READY ONS notifications so that other components such as
OPMN are notified 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
■Provides functionality that enables Oracle HTTP Server to terminate as a single
unit if the parent process fails. The parent process is responsible for starting and
stopping all of the child processes for an Oracle HTTP Server instance. The
failure of the parent process without first shutting down the child processes
leaves Oracle HTTP Server in an inconsistent state that can only be fixed by
manually killing all of the orphaned child processes. Until this is done, a new
Oracle HTTP Server instance cannot be started since the orphaned child
processes still occupy the ports Oracle HTTP Server wants to use. mod_onsint
provides a monitor of the parent process. If it detects that the parent process has
died, it kills all of the remaining child processes. When combined with OPMN,
this provides restartability for Oracle HTTP Server in the case of a parent
process failure. mod_onsint ensures that all of the Oracle HTTP Server child
processes die, leaving the ports open for a new Oracle HTTP Server instance.
OPMN ensures that a new instance is started once the failure of the original
instance is detected.
Oracle HTTP Server Modules 7-13
mod_onsint
Implementation Differences for mod_onsint
Due to the difference in architecture of Oracle HTTP Server on UNIX and Windows,
the implementation of mod_onsint varies slightly on these platforms.
On UNIX, mod_onsint spawns a process at module initialization time. This
process is responsible for watching the parent process as well as sending and
receiving ONS messages. Callback functions from other modules interested in ONS
notifications are made in this process. For this information to be shared with other
Oracle HTTP Server child processes, the use of an interprocess communication
method such as a memory mapped file must be used. If a failure of a parent process
is detected on UNIX, a signal is sent to all the other child processes, causing them to
shut down.
On Windows, Oracle HTTP Server consists of only two processes, the parent and a
multi-threaded child that handles all of the HTTP requests. In this model, mod_
onsint runs as a thread within the child process. This thread watches the parent
process as well as sending and receiving ONS messages. Callback functions from
other modules interested in ONS notifications are made in the child process. If a
failure of the parent process is detected, the mod_onsint terminates the child
process, effectively shutting down Oracle HTTP Server.
See Also: "Oracle HTTP Server Processing Model" on page 4-2
There is no configuration of mod_onsint needed to provide functionality
equivalent to that provided with Oracle HTTP Server in Oracle9i Application
Server, Release 2 (9.0.2), other than the loading of the module. There is only an
optional directive called OpmnHostPort that can be set. 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. However, in certain
circumstances, you may want to choose a specific HTTP port and hostname that
OPMN should use to ping the listener with.
OpmnHostPort takes a single argument which is a host:port string that specifies
the values to pass to OPMN. For example, the following line would specify that
OPMN should use the localhost interface and port 7778 to ping this listener:
OpmnHostPort localhost: 7778
7-14 Oracle HTTP Server Administrator’s Guide
mod_ossl
mod_perl
This directive must be in the global section of the httpd.conf file. It cannot be
embedded into any virtual host of location container. After installation, an
OpmnHostPort directive is located in dms.conf. It points OPMN to the Oracle
HTTP Server “diagnostic port”, which is a special localhost only virtual host.
You cannot combine directives using the one-argument syntax with directives using
the two-argument syntax. If you use the two-argument syntax, the default for
groups without a group-specific secret key is ’disabled’.
This Oracle module enables strong cryptography for Oracle HTTP Server. It 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. However, in contrast to the OpenSSL module,
mod_ossl is based on the Oracle implementation of SSL, which supports SSL,
version 3, and is based on Certicom and RSA Security technology.
See Also:
■Oracle Application Server 10g Security Guide
■"Using mod_ossl to Authenticate Users" on page 8-10
mod_perl
This module embeds the Perl interpreter into the Oracle HTTP Server. This
eliminates start-up overhead and enables you to write modules in Perl.
Note: The demonstration script for this module that is shipped
with Oracle Database should be disabled in production
environments. It is included only to verify that the installation was
successful.
See Also: mod_perl Guide
Oracle HTTP Server Modules 7-15
mod_perl
Database Usage Notes
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
The following section contains information about 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 Database. It calls Oracle Callable Interface (OCI) to access
the databases.
DBI must be enabled in httpd.conf for DBI to function. To do this, perform the
following steps:
1. Edit httpd.conf using a text editor.
2. Search for “PerlModule Apache: :DBI”.
3. Uncomment the line “PerlModule Apache: :DBI”.
4. Restart Oracle HTTP Server using the following commands:
If the script specifies “use Apache::DBI” instead of “use DBI”, then it will only
be able to run from
http://<hostname.domain>:<port>/perl/<scriptname>.
Testing Database Connection
The following is a sample Perl script for testing the database connection of a local
seed database. To use the script to test another database connection, you must
replace scott/tiger with the user name and password for the target database.
Example 7–2 Sample Perl Script For Testing Connection for Local Seed Database
##### Perl script start ######
use DBI;
print "Content-type: text/plain\n\n";
$dbh = DBI->connect("dbi:Oracle:", "scott/tiger", "") || 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";
##### Perl script End ######
Using SQL NCHAR Datatypes
SQL NCHAR datatypes have been refined in Oracle9i, and are now called reliable
Unicode datatypes. SQL NCHAR datatypes such as NCHAR, NVARCHAR2 and NCLOB
allow you to store any Unicode characters regardless of the database character set.
The character set for those datatypes is specified by the national character set,
which is either AL16UTF-16 or UTF8.
See Also: Oracle9i documentation for more about SQL NCHAR
datatypes.
Oracle HTTP Server Modules 7-17
mod_perl
This release of DBD::Oracle supports SQL NCHAR datatypes and provides driver
extension functions to specify the character form for data binding. The following
script shows an example to access SQL NCHAR data:
Example 7–3 Sample Script to Access SQLNCHAR 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' );
As shown in Example 7–3, the set_form function is provided as a private function
that you can invoke with the standard DBI func() method. It takes an anonymous
hash that specifies which placeholder should be associated with which character
form. 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 form is ORA_IMPLICIT.
Another function is provided to specify the default character set form as follows:
# specify the default form to be NCHAR
$dbh->func( ORA_NCHAR, 'set_default_form' );
After this call is made, the form of all parameters is ORA_NCHAR, unless otherwise
specified with set_form calls. Note that unlike the set_form function, this is a
function on the database handle, so every statement from the database handle with
its default form specified has the form of your choice by default.
7-18 Oracle HTTP Server Administrator’s Guide
mod_plsql
set_form This function sets the character form for parameter(s). Valid forms are
either ORA_IMPLICIT (default) or ORA_NCHAR. The constants are available as:
ora_forms in DBD::Oracle.
Example 7–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' );
set_default_form This function sets the default character form for a database handle.
Example 7–5 Default Character Form for a Database Handle
$dbh->func( ORA_NCHAR , 'set_default_form' );
mod_plsql
This Oracle module connects the Oracle HTTP Server to an Oracle database,
enabling you to create Web applications using Oracle stored procedures.
In order to access a Web-enabled PL/SQL application, configure a PL/SQL
Database Access Descriptor (DAD) for mod_plsql. A DAD is a set of values that
specifies how mod_plsql connects to a database server to fulfill an HTTP request.
Besides the connect details, a DAD contains important configuration parameters for
various operations in the database and for mod_plsql 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.
■Any PL/SQL Application written using the PL/SQL Web ToolKit
■Oracle Application Server Portal
Oracle HTTP Server Modules 7-19
mod_plsql
Creating a DAD
Perform the following steps to create a DAD:
1. Edit the DAD configuration file ORACLE_
HOME/Apache/modplsql/conf/dads.conf.
2. Add a DAD where the DAD has the following format:
a. The Oracle HTTP Server <Location> directive which defines a virtual path
used to access the PL/SQL Web Application. This directive begins
enclosing a group of directives that apply to the named Location.
For example, the directive <Location /myapp> defines a virtual path
called “/myapp” that will be used to invoke a PL/SQL Web Application
through a URL like http://host:port/myapp/.
Note: Older versions of mod_plsql were always mounted on a
virtual path with a prefix of ’/pls’. This restriction is removed in
newer versions but might still be a restriction imposed by some of
the older PL/SQL applications.
b. The Oracle HTTP Server “SetHandler” directive which directs Oracle
HTTP Server to enable mod_plsql to handle the request for the virtual
path defined by the named Location
SetHandler pls_handler
c. 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
AllowOverride None
d. One or more mod_plsql specific directives. For example:
PlsqlDatabaseUsername scott
PlsqlDatabasePassword tiger
PlsqlDatabaseConnectString orcl
PlsqlAuthenticationMode Basic
e. An Oracle HTTP Server </Location> directive which closes the group of
directives for the named Location, and defines a single DAD.
7-20 Oracle HTTP Server Administrator’s Guide
3. Save the edits.
4. Obfuscate the DAD password by running the “dadTool.pl” script located in
5. Restart the Oracle HTTP Server for the configuration to take effect.
You can create additional DADs by defining other uniquely named Locations in
dads.conf.
This section contains the following topics:
Configuration Files
Configuration Parameters
Configuration Files
mod_plsql configuration reside in the following three configuration files:
■plsql.conf
mod_plsql
ORACLE_HOME/Apache/modplsql/conf.
See Also: "PlsqlDatabasePassword" on page 7-36 for instructions
on performing the obfuscation.
■dads.conf
■cache.conf
plsql.conf
This file contains the LoadModule directive to load mod_plsql into Oracle HTTP
Server, any global setting for mod_plsql, and include directives for dads.conf
and cache.conf. This file is included by the Oracle HTTP Server configuration file
ORACLE_HOME/Apache/Apache/conf/oracle_apache.conf on UNIX or
ORACLE_HOME\Apache\Apache\conf\oracle_apache.conf on Windows,
which itself gets included in the primary Oracle HTTP Server configuration file
httpd.conf.
See Also: "oracle_apache.conf" on page A-5
Oracle HTTP Server Modules 7-21
mod_plsql
dads.conf
This file contains the configuration parameters for the PL/SQL database access
descriptor (DAD). A DAD is a set of values that specifies how mod_plsql connects
to a database server to fulfill a HTTP request.
cache.conf
This file contains the configuration settings for the file system caching functionality
implemented in mod_plsql. This configuration file is relevant only if PL/SQL
applications use the OWA_CACHE package to cache dynamically generated content
in the file system.
See Also: Oracle HTTP Server mod_plsql User’s Guide for details on
caching functionality in mod_plsql.
Configuration Parameters
Table 7–3 contains a list of mod_plsql configuration parameters. They are
discussed in detail in later 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_TAIWAN.UTF8”
Also, multi-line directives enables you to specify the same directive multiple times
in a DAD.
Table 7–3 mod_plsql Configuration Files and Parameters
Configuration FileParameters
plsql.confPlsqlDMSEnable
7-22 Oracle HTTP Server Administrator’s Guide
PlsqlLogEnable
PlsqlLogDirectory
PlsqlIdleSessionCleanupInterval
Table 7–3 mod_plsql Configuration Files and Parameters (Cont.)
Configuration FileParameters
dads.confPlsqlAfterProcedure
PlsqlAlwaysDescribeProcedure
PlsqlAuthenticationMode
PlsqlBeforeProcedure
PlsqlBindBucketLengths
PlsqlBindBucketWidths
PlsqlCGIEnvironmentList
PlsqlCompatibilityMode
PlsqlDatabaseConnectString
PlsqlDatabasePassword
PlsqlDatabaseUserName
PlsqlDefaultPage
PlsqlDocumentPath
PlsqlDocumentPath
PlsqlDocumentProcedure
PlsqlDocumentTablename
PlsqlErrorStyle
PlsqlExclusionList
PlsqlFetchBufferSize
PlsqlInfoLogging
PlsqlMaxRequestsPerSession
PlsqlNLSLanguage
PlsqlPathAlias
PlsqlPathAliasProcedure
PlsqlSessionCookieName
PlsqlSesssionStateManagement
PlsqlTransferMode
PlsqlUploadAsLongRaw
mod_plsql
Oracle HTTP Server Modules 7-23
mod_plsql
Table 7–3 mod_plsql Configuration Files and Parameters (Cont.)
Configuration FileParameters
cache.confPlsqlCacheCleanupTime
PlsqlCacheDirectory
PlsqlCacheEnable
PlsqlCacheMaxAge
PlsqlCacheMaxSize
PlsqlCacheTotalSize
plsql.conf
This file contains the LoadModule directive to load mod_plsql into the Oracle
HTTP Server, global settings for mod_plsql, and include directives for
dads.conf and cache.conf.
Note: Refer to plsql.README located in ORACLE_
HOME/Apache/modplsql/conf for detailed description of
plsql.conf.
The following section discusses the following parameters that can be specified in
plsql.conf:
■PlsqlDMSEnable
■PlsqlLogEnable
■PlsqlLogDirectory
■PlsqlIdleSessionCleanupInterval
PlsqlDMSEnable Enables Dynamic Monitoring Service (DMS) for mod_plsql.
CategoryValue
SyntaxPlsqlDMSEnable On/Off
DefaultOn
ExamplePlsqlDMSEnable On
7-24 Oracle HTTP Server Administrator’s Guide
mod_plsql
PlsqlLogEnable Enables debug level logging for mod_plsql.
Debug level logging is meant to be used for debugging purposes only. When
logging is enabled, log files are generated at:
■UNIX: ORACLE_HOME/Apache/modplsql/logs
■Windows: ORACLE_HOME\Apache\modplsql\logs
as configured by PlsqlLogDirectory. This parameter should be set to “Off”
unless recommended by Oracle support to debug problems with mod_plsql.
To view more details about the internal processing of mod_plsql, set this directive
to “On”. This causes mod_plsql to start logging for every request that is
processed. The log files are generated as specified by the PlsqlLogDirectory
directive.
CategoryValue
SyntaxPlsqlLogEnable On/Off
DefaultOff
ExamplePlsqlLogEnable Off
PlsqlLogDirectory Specifies the directory where debug level logs are written out.
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.
■Most customer applications use Basic Authentication. Custom Authentication
modes (GlobalOwa, CustomOwa, PerPackageOwa) are used by very few
PL/SQL applications. The SingleSignOn mode is supported only for Oracle
Application Server releases, and is used by Oracle Application Server Portal
and Oracle Application Server Single Sign-On.
■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, if
you wish to perform dynamic authentication, the DAD username/password
parameters must be omitted.
■In older versions of the product, this configuration parameter was derived from
a combination of enablesso and custom_auth.
■enablesso = Yes translates to PlsqlAuthenticationMode
SingleSignOn
■custom_auth = Global translates to PlsqlAuthenticationMode
GlobalOwa
■custom_auth = Custom translates to PlsqlAuthenticationMode
CustomOwa
■custom_auth = PerPackage translates to
PlsqlAuthenticationMode PerPackageOwa
All other combinations translate to Basic.
See Also: “Securing Application Database Access through mod_
plsql” chapter in the Oracle HTTP Server mod_plsql User’s Guide for
more information regarding different authentication modes.
Oracle HTTP Server Modules 7-29
mod_plsql
PlsqlBeforeProcedure 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.