Oracle HTTP Server Administrator's Guide 10g (9.0.4) Part Number B10381-01 |
|
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 Application Server components.
Documentation from the Apache Software Foundation is referenced when applicable.
Table 8-1 lists all the Oracle HTTP Server modules discussed in this chapter.
Oracle HTTP Server Modules |
|||
---|---|---|---|
Controls access to the server based on characteristics of a request, such as hostname or IP address.
See Also:
Module |
Enables execution of CGI scripts based on file type or request method.
See Also:
Module |
Enables manipulation of URLs in processing requests. It provides mapping between URLs and filesystem paths, and URL redirection capabilities.
See Also:
Module |
Enables sending files that contain their own HTTP headers. It is not supported by Oracle.
See Also:
Module |
Enables user authentication with files based user lists.
See Also:
Module |
Enables anonymous user access to protected areas (similar to anonymous FTP, where the email addresses can be logged).
See Also:
Module |
Uses Berkeley DB files to provide user authentication.
This module is disabled in the Oracle HTTP Server and is not supported by Oracle.
Uses DBM files to provide user authentication.
This module is not supported by Oracle.
Uses MD5 Digest Authentication to provide user authentication.
This module is not supported by Oracle.
Generates directory indexes automatically.
See Also:
Module |
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.
Allows reverse proxies that terminate SSL connections in front of Oracle HTTP Server, such as Oracle Application Server Web Cache, 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 allows certain requests to be treated as HTTPS requests even though they are received through HTTP.
Perform the following steps to configure mod_certheaders
:
mod_certheaders
. To do this, add a LoadModule
directive to
httpd.conf
file as shown below:
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
:
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.
Table 8-2 lists all the supported CGI environment variables with their corresponding HTTP 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.
If Oracle Application Server Web Cache is being used as the load balancer, it sends an HTTP header that identifies all requests it received through HTTPS. This means that mod_certheaders
automatically detects which requests should be treated as HTTPS requests by simply looking for this header. To enable this, add the following directive to httpd.conf
:
AddCertHeader HTTPS
This affects all URLs processed by Oracle HTTP Server.
For other 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>
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 |
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.
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 |
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 |
Enables you to monitor performance of site components with Oracle's Dynamic Monitoring Service (DMS).
Enables you to control the environment for CGI scripts and SSI (Server Side Includes) pages by passing, setting, and unsetting environment variables.
See Also:
Module |
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.
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 |
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 |
Enables you to merge, replace, or remove HTTP response headers.
See Also:
Module |
Enables server-side image map processing.
This module is not supported by Oracle.
Provides a filter that processes documents for SSI (Server Side Includes) directives.
See Also:
Module |
Summarizes the entire server configuration, including all installed modules and directive settings.
See Also:
Module |
Enables serving of Internet Server extensions (such as .dll
modules).
It is available on the Windows platform only, and is not supported by Oracle.
Connects the Oracle HTTP Server to the JServ servlet engine. It converts HTTP requests to servlet requests, returning HTTP responses to the client.
mod_jserv
is disabled by default in the Oracle HTTP Server distribution; it is included for legacy support only. The instructions below explain how to enable it with mod_oprocmgr
, in manual mode, or in automatic mode. Use the instructions for the mode that serves your needs. A working knowledge of JServ and Oracle HTTP Server directives is assumed.
This section explains how to enable the Oracle default mode for JServ. Use this mode if you want process management and load balancing capabilities for multiple JVMs. The ApJServManual
directive has a new mode, 'auto', that enables using JServ with the Oracle module
mod_oprocmgr
. The file jserv.conf
file contains
LoadModule
directives for mod_jserv
and mod_oprocmgr
.
Follow these steps to enable JServ with mod_oprocmgr
:
Include
directive for the jserv.conf
file in:
UNIX: ORACLE_HOME
/Apache/Apache/conf/httpd.conf
#include "/ORACLE_HOME
/Apache/Jserv/etc/jserv.conf"
Windows: ORACLE_HOME
\Apache\Apache\conf\httpd.conf
#include "C:\ORACLE_HOME\Apache\Jserv\conf\jserv.conf"
ApJServManual
directive in the file:
UNIX: ORACLE_HOME
/Apache/Jserv/etc/jserv.conf
Windows: ORACLE_HOME
\Apache\Jserv\conf\jserv.conf
ApJServManual auto
UNIX: ORACLE_HOME
/Apache/Jserv/etc/jserv.properties
Windows: ORACLE_HOME
\Apache\Jserv\conf\jserv.properties
UNIX: ORACLE_HOME
/Apache/Jserv/etc/zone.properties
Windows: ORACLE_HOME
\Apache\Jserv\conf\zone.properties
This section explains how to enable JServ in automatic mode. Use this mode if you need only one JVM. In this mode, the ApJServManual
directive is set to 'off' and the
mod_jserv
module launches and monitors the JVM. If the Oracle HTTP Server is restarted or stopped, mod_jserv
restarts or stops the JVM.
Follow these steps to enable JServ in automatic mode:
Include
directive for the
jserv.conf
file in:
UNIX: ORACLE_HOME
/Apache/Apache/conf/httpd.conf
#include "/ORACLE_HOME/Apache/Jserv/etc/jserv.conf"
Windows: ORACLE_HOME
\Apache\Apache\conf\httpd.conf
#include "C:\ORACLE_HOME\Apache\Jserv\conf\jserv.conf"
ApJServManual
directive in the file:
UNIX: ORACLE_HOME
/Apache/Jserv/etc/jserv.conf
Windows: ORACLE_HOME
\Apache\Jserv\conf\jserv.conf
ApJServManual off
jserv.conf
.
UNIX: ORACLE_HOME
/Apache/Jserv/etc/jserv.properties
Windows: ORACLE_HOME
\Apache\Jserv\conf\jserv.properties
to the same value as that specified in the ApJServDefaultPort
directive.
UNIX: ORACLE_HOME
/Apache/Jserv/etc/zone.properties
Windows: ORACLE_HOME
\Apache\Jserv\conf\zone.properties
This section explains how to enable JServ in manual mode. Use this mode if you need to run multiple JVMs. In this mode, the ApJServManual
directive is set to 'on' and you have to stop and start the JVM manually. To monitor the JVM, you must use an external monitoring facility.
Follow these steps to enable JServ in manual mode:
Include
directive for the
jserv.conf
file in the file:
UNIX: ORACLE_HOME
/Apache/Apache/conf/httpd.conf
#include "/ORACLE_HOME/Apache/Jserv/etc/jserv.conf"
Windows: ORACLE_HOME
\Apache\Apache\conf\httpd.conf
#include "C:\ORACLE_HOME\Apache\Jserv\conf\jserv.conf"
ApJServManual
directive in the file:
UNIX: ORACLE_HOME
/Apache/Jserv/etc/jserv.conf
Windows: ORACLE_HOME
\Apache\Jserv\conf\jserv.conf
ApJServManual on
jserv.conf
.
UNIX: ORACLE_HOME
/Apache/Jserv/etc/jserv.properties
Windows: ORACLE_HOME
\Apache\Jserv\conf\jserv.properties
UNIX: ORACLE_HOME
/Apache/Jserv/etc/zone.properties
Windows: ORACLE_HOME
\Apache\Jserv\conf\zone.properties
wrapper.bin.parameters
and wrapper.classpath
in the jserv.properties
file.
Scripts are provided in the
Note:
ORACLE_HOME
/Apache/Apache/bin
directory to start and stop JServ. These include commands to set the arguments and the classpath.
This section explains how to use mod_rewrite
to enable some applications to execute on JServ, and others on Oracle Application Server Containers for J2EE (OC4J).
Perform the following configuration steps to enable JServ and OC4J to coexist. This is important if you have the Portal and Wireless installation type, because of the Portal dependency on OC4J.
/application1/file1.jsp
to execute on JServ, and
/application2/file2.jsp
to execute on OC4J.
You must rewrite the URL for application1.
UNIX: ORACLE_HOME
/Apache/Apache/conf/httpd.conf
Windows: ORACLE_HOME
\Apache\Apache\conf\httpd.conf
and uncomment that the following directives:
LoadModule rewrite_module libexec/mod_rewrite.so AddModule mod_rewrite.c RewriteEngine on
UNIX: ORACLE_HOME
/Apache/jsp/conf/ojsp.conf
Windows: ORACLE_HOME
\Apache\jsp\conf\ojsp.conf
to add these directives:
RewriteRule /application1/(.*)/(.*).jsp$ /application1/$1/$2.jsp1 ApJServAction .jsp1 /servlets/oracle.jsp.JspServlet
ApJServAction .jsp /servlets/oracle.jsp.JspServlet
UNIX: ORACLE_HOME
/Apache/Jserv/etc/jserv.conf
Windows: ORACLE_HOME
\Apache\Jserv\conf\jserv.conf
and mount /servlets to the JVM that will service the JSP requests. Use the ApJServMount
or ApJServGroupMount
directive, depending on how the JServ processes are started.
See Also:
mod_jserv
's mapping for JSP applications does not provide for specifying application paths, such as:
ApJServAction /path/.jsp ...
However, you can configure different JSP applications to run on different JVMs under mod_jserv
. The configuration steps below show how to use mod_rewrite
to change the extension of JSP pages associated with a JSP application at request time (where *.jsp1
files belong to application1
, and *.jsp2
files belong to application2
). Each .jsp
extension has its own ApJServAction
handler, so that multiple JVMs can be used to run different JSP applications.
Follow the instructions below, substituting application names, directories, page extensions, and hostnames as applicable to your system:
mod_rewrite
by adding the following lines to
httpd.conf
:
LoadModule rewrite_module libexec/mod_rewrite.so AddModule mod_rewrite.c RewriteEngine on
ojsp.conf
:
RewriteRule ^/app1/(.*)/(.*)·jsp$ /app1/$1/$2.jsp1 RewriteRule ^/app2/(.*)/(.*)·jsp$ /app2/$1/$2.jsp2 ApJServAction .jsp1 /servlets1/oracle.jsp.JspServlet ApJServAction .jsp2 /servlets2/oracle.jsp.JspServlet
jserv.conf
:
ApJServMount /servlets1 ajpv12://hostname:8008/root ApJServMount /servlets2 ajpv12://hostname:8009/root
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.
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.
See Also:
Module |
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 |
Enables the server to determine the type of a file from its filename, and associate files with handlers for processing.
See Also:
Module |
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.
See Also:
Module |
Maps a list of files into memory, useful for frequently requested files that are not changed often.
This module is not supported by Oracle.
Enables the server for content negotiation (selection of documents based on the client's capabilities).
See Also:
Module |
Routes requests from the Oracle HTTP Server to Oracle Application Server Containers for J2EE (OC4J), through the AJP 1.3 protocol.
mod_oc4j
is enabled by default. During installation, the oc4j_deploy_tool.jar
adds mount points to mod_oc4j.conf
for applications deployed into OC4J instances. Requests that come in for specific mount points in
mod_oc4j
are routed to the OC4J instance for that mount point.
OC4J instances are started and managed by Oracle Process Manager and Notification Server (OPMN).
This section discusses the following topics:
All relevant directives in httpd.conf
and
mod_oc4j.conf
are described below. Sample configurations are also provided.
The mod_oc4j
directives are maintained in mod_oc4j.conf
. The
mod_oc4j.conf
file is included by default into the httpd.conf
file, using the directive below:
include "ORACLE_HOME/Apache/Apache/conf/mod_oc4j.conf"
The following directives are used to configure mod_oc4j
:
"Using mod_ossl Directives" for detailed information on SSL configuration directives.
See Also:
Loads the mod_oc4j
module.
Category | Value |
---|---|
Syntax |
|
Required |
Yes |
Default |
|
Example |
Specifies the size of the OC4J connection cache.
Defines maximum idle time for unused connections.
Directs mod_oc4j
to use JSESSIONID_<
cookie_name_extension
>
as OC4J's session identifier in the cookie.
Governs passing SSL environment variables.
If configured,
Note:
mod_oc4j
passes some security environment parameters to OC4J, set by mod_ossl
and mod_osso
, at request time.
Directs mod_oc4j
to pass some environment variables from Oracle HTTP Server to OC4J.
If configured,
Note:
mod_oc4j
passes some security environment parameters to OC4J, set by mod_ossl
and mod_osso
, at request time.
Directs mod_oc4j
to route requests containing a particular path to a destination. A destination can be a single OC4J process, or a set of OC4J instances.
Copies mount points from the base server.
This section provides some sample configurations for mod_oc4j
.
Level 1 is the simplest configuration.
This configuration mounts all requests starting with the URI /servlet/ to the default instance of OC4J processes. Because an instance of OC4J processes is handled by OPMN and the default instance must be the same as OPMN's default OC4J instance, this configuration requires that mod_oc4j
must be used with OPMN.
Make this entry in the httpd.conf
file:
Oc4jMount /servlet/*Example 8-2 Sample mod_oc4j configuration
This configuration performs the same work as the configuration in Example 8-1, using a <Location
> container directive instead of the Oc4jMount
directive.
Make this entry in the httpd.conf
file:
<Location /servlet> SetHandler oc4j-handler </Location>
This configuration mounts all requests starting with the URI /servlet/
or /j2ee/
and all JSP pages to the default OC4J instance of OC4J processes. This configuration requires that mod_oc4j
must be used with OPMN.
Make these entries in the mod_oc4j.conf
file:
Oc4JMount /servlet/* Oc4JMount /*.jsp Oc4JMount /j2ee/*Example 8-4 Sample mod_oc4j configuration
This configuration mounts:
/applicationA/
and all JSP pages to oc4j_instance_A
, in which all OC4J processes are managed by OPMN. This configuration requires that mod_oc4j
must be used with OPMN.
/applicationB/
to oc4j_instance_B
, in which all OC4J processes are managed by OPMN. This configuration requires that mod_oc4j
must be used with OPMN.
Make these entries in the mod_oc4j.conf
file:
Oc4JMount /applicationA/* oc4j_instance_A Oc4JMount /applicationB/* oc4j_instance_B Oc4JMount /j2ee/* Oc4JMount /*.jsp oc4j_instance_A
This section contains information about mod_oc4j
load balancing
Table 8-3
lists load balancing policies that
mod_oc4j
supports:
Selects an OC4J instance for load balancing.
Category | Value |
---|---|
Syntax |
|
Required |
No |
Default |
If |
Example |
|
Usage |
|
This directive is only applicable to the base server for Oracle Application Server 10g (9.0.4) and an error will be printed at startup if specified within a VirtualHost
container.
Associates a request routing weight for each machine during load balancing. Weighted routing is a load balancing strategy that distributes requests according to a predefined value assigned to each machine based on the predicted ability to handle load.
This directive is only applicable to the base server for Oracle Application Server 10g (9.0.4) and an error will be printed at startup if specified within a VirtualHost
container.
Metric-based load balancing can be used when "Oc4jSelectMethod metric
| metric:local
" is specified in mod_oc4j.conf
and the <
metric-collector
> element is configured in server.xml
.
If <metric-collector
> is not configured, then OC4J does not send any run time metrics to mod_oc4j
. mod_oc4j
then assumes that the missing value for OC4J is "50".
"Oc4jSelectMethod random:weighted
" is specified in mod_oc4j.conf
and the <metric-collector
> element is configured.
OC4J sends run time metrics to mod_oc4j
, but mod_oc4j
ignores it. It uses the Random using Routing Weight policy for each machine to perform load balancing. Weight is configured by Oc4jRoutingWeight
.
"Oc4jSelectMethod metric
" is specified in mod_oc4j.conf
and the <metric-collector
> element is not configured.
OC4J sends the default value of "50" as run time metrics to mod_oc4j
. mod_oc4j
treats every OC4J process equally, and randomly selects OC4J processes.
Optionally, you can have direct SSL support for communication between mod_oc4j
and OC4J. To do this, you have to enable SSL on the mod_oc4j
side as well as the OC4J side. Steps to dp this are discussed in the topics discussed below:
Add the following directives in mod_oc4j.conf
to enable SSL for mod_oc4
:
Indicates whether mod_oc4j
needs to use SSL when communicating with OC4J processes. It should not be configured to "on" if Oc4jiASPTActive
is configured to "On".
Category | Value |
---|---|
Parameter Name |
|
Parameter Type |
string |
Valid Values |
|
Default Value |
|
When Oc4jEnableSSL
is set to "On", this directive specifies the location of an Oracle Wallet file that contains SSL certificates that are used for SSL communication with OC4J processes.
When Oc4jEnableSSL
is set to "On", this value is the obfuscated password used for authentication when opening the wallet file. This value is obtained using the utility provided with the Oracle Wallet Manager.
To enable SSL communication between mod_oc4j
and OC4J, you have to enable SSL on the OC4J side too.
See Also:
"Enabling SSL for OC4J" for enabling SSL on the OC4J side. |
You can integrate generic Apache with Oracle Application Server, 10g (9.0.4). This enables you route requests from generic Apache to OC4J in the same manner as routing requests using Oracle HTTP Server and mod_oc4j
.
This module provides integration support with Oracle Notification Service (ONS) and OPMN (Oracle Process Manager and Notification Server).
mod_onsint
provides the following functionality:
mod_onsint
provides a single process that receives notification for all modules within an Oracle HTTP Server instance.
PROC_READY
ONS notifications so that other components such as OPMN and OC4J 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 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.
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.
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 allows 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 using the same algorithm that was use in Oracle HTTP Server in Oracle9i Application Server, Release 2 (9.0.2). 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
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. It does not log internal diagnostic requests such as OPMN pings and DMS metric requests from Oracle Enterprise Manager Application Server Control.
This Oracle module provides process management and load balancing services to JServ processes. It is provided for legacy users of JServ. JServ is disabled by default in the Oracle HTTP Server configuration. Oracle recommends using OC4J and mod_oc4j
(which are enabled by default).
The following sections explain how to configure mod_oprocmgr
. Terms used in these sections are defined below:
A module that starts, stops, and detects death of processes (starting new processes to replace them), and provides load balancing services to the processes. mod_oprocmgr
gets the topology management information through HTTP requests from JServ, and does its job based on this information.
A set of processes across which request traffic is distributed.
A JVM instance that runs a servlet engine, such as JServ.
mod_oprocmgr
provides infrastructure capabilities, such as automatic starting of processes, death detection and restart, and load balancing. These capabilities are enabled by a new mode, auto, for the ApJServManual
directive.
Based on the configuration information provided by mod_jserv
,
mod_oprocmgr
starts the specified number of JServ processes, managing them for the life of the servers.
Note:
You must have at least one non-https port enabled for Oracle HTTP Server in order to enable |
mod_oprocmgr
enhances the functionality and administration of JServ in several ways:
With ApJServManual
off
, only one JServ engine can be started and managed automatically. Additional servlet engines have to be manually started, monitored and stopped.
With ApJServManual
auto
, any number of JServ engines can be started automatically. The process manager continually monitors the health of these processes and kills and restarts them, if necessary. You can still start JServ processes manually, if you need to.
Configuring multiple JServ processes with ApJServManual
on/
ApJServManual off
is more complicated and error prone. For example, a 10 process "balance" configuration requires thirty two directives and ten jserv.properties
files.
Configuring multiple JServ processes with the new `auto' mode requires much less effort. For example, a ten process "balance" configuration requires only 3 directives.
If you are familiar with the configuration directives for mod_jserv
, the configuration process for mod_oprocmgr
is straightforward. The configuration files are listed below.
To use mod_oprocmgr
, include the directives below in the httpd.conf
file:
<IfModule mod_oprocmgr.c> ProcNode my-sun.us.oracle.com 7777 <IfDefine SSL> ProcNode my-sun.us.oracle.com 80 </IfDefine> <Location /oprocmgr-service> SetHandler oprocmgr-service </Location> </IfModule>
In addition, you must specify at least one non-SSL port. For a secure Web site (that is, one that only accepts SSL connections), you must provide an extra non- SSL port. To do this, add the directives shown below, substituting port and address values:
Listen <port> <VirtualHost _default_:port> SSLEngine Off <Location /> order deny, allow deny from all allow from <IP address 1 of local node> allow from <IP address 2 of local node> allow from <IP address 3 of local node> </Location> </VirtualHost>
In the LoadModule
section, ensure that mod_oprocmgr
is loaded after mod_osso
. The call back function of mod_oprocmgr
in the 'check usrid' stage must be invoked before that of mod_osso
.
In the file:
ORACLE_HOME
/Apache/Jserv/etc/jserv.properties
ORACLE_HOME
\Apache\Jserv\etc\jserv.properties
specify the ports to which JServ will bind, as shown in the example below.
port=8007
If no ports are specified, the JServ processes will choose their ports. If you want the JServ processes to choose their ports, enter the port directive as shown below. If you eliminate the directive entirely, an error will occur.
port=
You can specify multiple ports, and separate the values with commas as shown in the example below. Note that a range of ports (9000-9010) is a valid value.
port=8007,9000-9010,8010
To use mod_oprocmgr
with mod_jserv
, you must change the directives as indicated below in the JServ configuration file:
This directive accepts a mode, auto, which invokes the infrastructure functionality (in which mod_oprocmgr
manages processes). The syntax is:
ApJServManual auto
You can set the mode to "On" or "Off" to use the standard JServ functionality.
This directive defines groups for the process manager to manage for mod_jserv
. If you have worked with mod_jserv
, you will note that this directive replaces the ApJServBalance
, ApJServHost
, ApJServRoute
and ApJServShmFile
directives.
All JServ processes to be managed must belong to a group, and each group has its own ApJServGroup
directive. If you only have one JServ process, you must define a group with just that process in it. The processes in a group are identical except for their listening ports, so requests directed to the group are distributed evenly among the processes.
The ApJServGroup
directive takes four arguments: groupname, number of processes, node weight, and properties file. In the example below, the groupname is mygroup
, the number of processes is 1, the node weight is 1, and the full path of the properties file used to start the JServ processes is ORACLE_HOME
/Apache/JServ/etc/jserv.properties.
ApJServGroup mygroup 1 1 /private2/up_1022/Apache/Jserv/etc/jserv.properties
This directive defines a mount point and maps it to a process group and zone. In the example below, the mount point is /servlets
, the group is mygroup
, and the zone is root
. Note that the balance protocol is in use for routing, as in the standard JServ configuration.
ApJServGroupMount /servlets balance://mygroup/root
Place this directive after the ApJServGroup
directive in the configuration file.
This directive specifies the secret key that JServ needs to authenticate clients. It can be disabled, as shown below:
ApJServGroupSecretKey disabled
When activated, the directive takes one or two arguments. In the example below, with group and filename arguments, the filename mysecretkey
applies to the group mygroup
.
ApJServGroupSecretKey mygroup /usr/local/apache/jserv/mysecretkey
You can supply only the filename argument, as shown below. No group is named, so the secret key filename applies to all groups.
ApJServGroupSecretKey /usr/local/apache/jserv/mysecretkey
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'.
Place this directive after the ApJServGroup
directive in the configuration file.
This Oracle module (an OCI application written in C) that is an extended implementation of mod_dav
, and is integrated with the Oracle HTTP Server. mod_oradav
can read and write to local files or to an Oracle database. The Oracle database must have an OraDAV driver (a stored procedure package) that mod_oradav
calls to map WebDAV activity to database activity. Essentially, mod_oradav
enables WebDAV clients to connect to an Oracle database, read and write content, and query and lock documents in various schemas.
You can configure mod_oradav
to an Oracle database using standard Oracle HTTP Server directives. mod_oradav
can immediately leverage other module code (such as mime_magic
) in order to perform content management tasks. Most OraDAV processing activity involves streaming content to and from a content provider; and mod_oradav
uses OCI streaming logic directly within the Oracle HTTP Server.
To configure mod_oradav
, you enter parameters within a <Location>
container directive in httpd.conf
. The <
Location>
container directive specifies the DAV-enabled URL. The DAV
keyword is followed by a single value: On,
which tells mod_dav
to use the local file system for content.
The following example specifies that the directory myfiles
under the Web server documents directory (htdocs
by default) is to be DAV-enabled, along with all directories under myfiles
in the hierarchy. (Note that there must not be any symlinks defined on myfiles
or any of its subdirectories.)
<Location /myfiles> DAV On </Location>
See Also:
|
For information about using mod_oradav
to access database schemas for access by third-party tools (such as Adobe GoLive and Macromedia Dreamweaver) and Oracle interMedia, refer to the OraDAV information available on the Oracle Technology Network at
http://otn.oracle.com
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:
|
This Oracle module enables single sign-on for Oracle HTTP Server. mod_osso
examines incoming requests and determines whether the resource requested is protected, and if so, retrieves the Oracle HTTP Server cookie for you.
This module embeds the Perl interpreter into the Oracle HTTP Server. This eliminates start-up overhead and enables you to write modules in Perl.
See Also:
|
This section provides information for mod_perl
users working with databases. It explains how to test a local database connection and set character forms.
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 Application Server. 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:
httpd.conf
using a text editor.
PerlModule Apache:
:DBI
".
PerlModule Apache:
:DBI
".
Files must be copied to ORACLE_HOME
/Apache/Apache/cgi-bin
#!<ORACLE_HOME>perl/bin/perl -w use DBI; my $dataSource = "host=<hostname.domain>;sid=<orclsid>;port=1521"; my $userName = "scott"; my $password = "tiger"; my $dbhandle = DBI->connect("dbi:Oracle:$dataSource", $userName, $password) or die "Can't connect to the Oracle Database: $DBI::errstr\n"; print "Content-type: text/plain\n\n"; print "Database connection successful.\n"; ### Now disconnect from the database $dbhandle->disconnect or warn "Database disconnect failed; $DBI::errstr\n"; exit;
You can access the DBI scripts from the following locations:
http://<hostname.domain>:<port>/cgi-bin/<scriptname> http://<hostname.domain>:<port>/perl/<scriptname>
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>
.
Below 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.
##### 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 ######
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.
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:
# declare to use the constants for character forms
use DBD::Oracle qw(:ora_forms);
# connect to the database and get the database handle
$dbh = DBI->connect( ... );
# prepare the statement and get the statement handle
$sth = $dbh->prepare( 'SELECT * FROM TABLE_N WHERE NCOL1 = :nchar1' );
# bind the parameter of a NCHAR type
$sth->bind_param( ':nchar1', $param_1 );
# set the character form to NCHAR
$sth->func( { ':nchar1' => ORA_NCHAR } , 'set_form' );
$sth->execute;
As shown above, 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.
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
.
# 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 toNCHAR
$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' );
This function sets the default character form for a database handle.
$dbh->func( ORA_NCHAR , 'set_default_form' );
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.
If mod_plsql
is part of Oracle Application Server, it is recommended that you use Oracle Enterprise Manager Application Server Control to create a DAD.
If not, then perform the following steps to create a DAD:
ORACLE_HOME
/Apache/modplsql/conf/dads.conf
.
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/
.
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
Location
> directive. Typically, the following directives are used:
Order deny,allow Allow from all AllowOverride None
mod_plsql
specific directives. For example:
PlsqlDatabaseUsername scott PlsqlDatabasePassword tiger PlsqlDatabaseConnectString orcl PlsqlAuthenticationMode Basic
</Location>
directive which closes the group of directives for the named Location
, and defines a single DAD.
dadTool.pl
" script located in ORACLE_HOME
/Apache/modplsql/con
f.
"PlsqlDatabasePassword" for instructions on performing the obfuscation.
See Also:
mod_plsql
is part of Oracle Application Server, then issue the following command:
$ORACLE_HOME
/dcm/bin/dcmctl updateConfig -ct ohs
You can create additional DADs by defining other uniquely named Locations
in dads.conf
.
This section contains the following topics:
mod_plsql
configuration reside in the following three configuration files:
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
.
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.
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 Application Server 10g mod_plsql User's Guide for details on caching functionality in |
Table 8-4 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.
Configuration File | Parameters |
---|---|
dads.conf (continued) |
|
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 |
The following section discusses the following parameters that can be specified in plsql.conf
:
Enables Dynamic Monitoring Service (DMS) for mod_plsql
.
Category | Value |
---|---|
Syntax |
|
Default |
On |
Example |
|
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:
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.
Category | Value |
---|---|
Syntax |
PlsqlLogEnable |
Default |
Off |
Example |
PlsqlLogEnable Off |
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.
Category | Value |
---|---|
Syntax |
|
Default |
None |
Example |
|
Specifies the time (in minutes) in which the idle database sessions should be closed and cleaned by mod_plsql
.
This directive is used in conjunction with connection pooling of database connections and sessions in mod_plsql
. When a session is not used for the specified amount of time, it is closed, and freed. This is done so that unused sessions can be cleaned, and the memory is freed on the database side.
Setting this time to a low number helps in faster cleanup of unused database sessions. Be aware that if this number is too low, then this may adversely affect the performance benefits of connection pooling in mod_plsql
.
If the number of open database sessions is not a concern, you can increase the value of this parameter for best performance. In such a case, if the site is accessed frequently enough that the idle session cleanup interval is never reached for a session, then the DAD configuration parameter PlsqlMaxRequestsPerSession
can be modified so that it is guaranteed that a pooled database session gets recycled on a regular basis.
For most installations, the default parameter value should suffice.
Category | Value |
---|---|
Syntax |
|
Default |
15 (minutes) |
Example |
|
This file contains the configuration parameters for the PL/SQL Database Access Descriptor (DAD).
This section describes all the DAD level parameters that can be specified in the dads.conf
file. Besides these directives, you can also specify additional Oracle HTTP Server directives that can be specified in the context of a <Location
> directive, such as:
Order deny,allow AllowOverride None
The following parameters are discussed in detail in the subsequent sections:
PlsqlAfterProcedure
PlsqlAlwaysDescribeProcedure
PlsqlAuthenticationMode
PlsqlBeforeProcedure
PlsqlBindBucketLengths
PlsqlBindBucketWidths
PlsqlCGIEnvironmentList
PlsqlCompatibilityMode
PlsqlDatabaseConnectString
PlsqlDatabasePassword
PlsqlDatabaseUserName
PlsqlDefaultPage
PlsqlDocumentPath
PlsqlDocumentProcedure
PlsqlDocumentTablename
PlsqlErrorStyle
PlsqlExclusionList
PlsqlFetchBufferSize
PlsqlInfoLogging
PlsqlMaxRequestsPerSession
PlsqlNLSLanguage
PlsqlPathAlias
PlsqlPathAliasProcedure
PlsqlSessionCookieName
PlsqlSesssionStateManagement
PlsqlTransferMode
PlsqlUploadAsLongRaw
Specifies the procedure to be invoked after calling the requested procedure. This enables you to put a hook point after the requested procedure is called. This is useful in doing SQL*Traces/SQL Profiles while debugging a problem with the requested procedure. This is also useful when you want to ensure that a specific call be made after running every procedure.
Category | Value |
---|---|
Syntax |
|
Default |
None |
Example |
|
Notes:
after_proc
.
Specifies whether mod_plsql
should describe a procedure before trying to execute it. If this is set to "On", then mod_plsql
will always describe a procedure before invoking it. Otherwise, mod_plsql
will only describe a procedure when its internal heuristics have interpreted a parameter type incorrectly.
Category | Value |
---|---|
Syntax |
|
Default |
Off |
Example |
|
Notes:
always_desc
.
Specifies the authentication mode to use for allow access through this DAD.
Category | Value |
---|---|
Syntax |
|
Default |
Basic |
Example |
|
Notes:
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.
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.
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 |
Specifies the procedure to be invoked before calling the requested procedure. This enables you to put a hook point before the requested procedure is called. This is useful in doing SQL*Traces/SQL Profiles while debugging a problem with the requested procedure. This is also useful when you want to ensure that a specific call be made before running every procedure.
Category | Value |
---|---|
Syntax |
|
Default |
None |
Example |
|
Notes:
before_proc
.
Specifies the rounding size to use while binding the number of elements in a collection bind. While executing PL/SQL statements, the Oracle database maintains a cache of PL/SQL statements in the shared SQL area, and attempts to reuse the cached statement if the same statement is executed again. Oracle's matching criteria requires that the statement texts be identical, and that the bind variable data types match. Unfortunately, the type match for strings is sensitive to the exact byte size specified, and for collection bindings is also sensitive to the number of elements in the collection. Since mod_plsql
binds statements dynamically, the odds of hitting the shared cache are low, and it may fill up with near-duplicates and lead to contention for the latch on the shared area. This parameter reduces that effect by bucketing bind lengths to the nearest level.
All numbers specified should be in ascending order. After the last specified size, subsequent bucket sizes will be assumed to be twice the last one.
Category | Value |
---|---|
Syntax |
|
Default |
4,20,100,400 |
Example |
|
Notes:
bind_bucket_lengths
.
Specifies the rounding size to use while binding the number of elements in a collection bind. While executing PL/SQL statements, the Oracle database maintains a cache of PL/SQL statements in the shared SQL area, and attempts to reuse the cached statement if the same statement is executed again. Oracle's matching criteria requires that the statement texts be identical, and that the bind variable data types match. Unfortunately, the type match for strings is sensitive to the exact byte size specified, and for collection bindings is also sensitive to the number of elements in the collection. Since mod_plsql
binds statements dynamically, the odds of hitting the shared cache are low, and it may fill up with near-duplicates and lead to contention for the latch on the shared area. This parameter reduces that effect by bucketing bind widths to the nearest level.
All numbers specified should be in ascending order. After the last specified size, subsequent bucket sizes will be assumed to be twice the last one.
The last bucket width must be equal to or less than 4000. This is due to the restriction imposed by OCI where array bind widths cannot be greater than 4000.
Category | Value |
---|---|
Syntax |
|
Default |
|
Example |
|
Notes:
bind_bucket_widths
.
Specifies overrides and/or additions of CGI environment variables to the default set of environment variables passed down to a PL/SQL procedure. This is a multi-line directive of name-value pairs to be added, overridden or removed. You can only specify one environment variable for each directive.
You can add CGI environment variables from the Oracle HTTP Server environment by specifying the variable name. To remove a CGI environment variable, set it equal to nothing. To add your own name-value pair, use the syntax myname=myvalue.
Notes:
owa_util.get_cgi_env
.
cgi_env_list
.
Specifies the compatibility mode for running mod_plsql
. This parameter is supported only for Oracle Application Server releases, and is used when you are using mod_plsql
with an older version of Oracle Application Server Portal. In such situations, if you are running mod_plsql
against a pre-9.0.2 version of Oracle Application Server Portal, this should be set to 1.
Category | Value |
---|---|
Syntax |
|
Default |
0 |
Example |
|
Notes:
mod_plsql
in which mod_plsql
incorrectly converted the plus symbol (+
) to space characters for document downloads. Enabling the first bit in this flag will make it impossible to download documents that have a plus symbol (+)
in the document name.
Specifies the connection to an Oracle database.
Notes:
TWO_TASK"
is set (called "LOCAL"
on Windows NT), this parameter need not be specified.
tnsping <
string>
" and execute commands such as:
sqlplus DADUsername/DADPassword@<string>
TNS_ADMIN
is configured properly.
HOST:PORT:SERVICE_NAME
format makes the connection go through.
mod_plsql
perspective, TNSFormat
and NetServiceNameFormat
are synonymous and denote connect descriptors that are resolved by Net. The TNSFormat
is provided as a convenience so that end-users use this to signify that the name resolution happens through the local tnsnames.ora
. For situations where the resolution is through an LDAP lookup as configured in sqlnet.ora
, it is recommended that the format specifier of NetServiceNameFormat
be used.
If your database supports high availability, for example, RAC database, it is highly recommended that you use the NetServiceNameFormat
such that the resolution for the net service name is through LDAP. This enables you to add or remove RAC nodes accessible through mod_plsql
by just changing Oracle Internet Directory with the new/deleted node information. In such situations, hard-coding database listener HOST:PORT
information in dads.conf
or in the local tnsnames.ora
is not recommended.
connect_string
.
Specifies the password to use to log in to the database.
Category | Value |
---|---|
Syntax |
|
Default |
None |
Example |
|
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/con
f.
Following are the steps to obfuscate DAD passwords:
oracle
using the following command:
$su - oracle
ORACLE_HOME
environment variable to specify the path to the Oracle home directory for the current release and set the PATH
environment variable to include the directory containing the Perl executable and the location of the dadTool.pl
script.
On Bourne, Bash, or Korn Shell:
ORACLE_HOME=new_ORACLE_HOME_path
;export ORACLE_HOME PATH=ORACLE_HOME
/Apache/modplsql/conf:ORACLE_HOME
/perl/bin:PATH;export PATH
On C or tcsh Shell:
setenv ORACLE_HOMEnew_ORACLE_HOME_PATH
setenv PATHORACLE_HOME
/Apache/modplsql/conf:ORACLE_HOME
/perl/bin:PATH
On Windows:
set PATH=ORACLE_HOME
\Apache\modplsql\conf;ORACLE_HOME
\perl\5.6.1\bin\MSWin32-x86;%PATH
%
ORACLE_HOME
/lib
directory in your shared library path. Table 8-5 shows the appropriate environment variable for each platform.
Table 8-5 Platform Type and Corresponding Shared Library Path Environment Variable
Platform | Environment Variable |
---|---|
AIX |
|
HP-UX |
|
Linux, Solaris, and Tru64 UNIX |
|
For example, to set the SHLIB_PATH
environment in the Bourne shell on HP-UX systems, enter the following command:
$SHLIB_PATH
=$ORACLE_HOME
/lib:$SHLIB_PATH
;exportSHLIB_PATH
$
ORACLE_HOME
/bin
in your PATH
, for example:
set PATH=%ORACLE_HOME
%\bin;%PATH
%
mod_plsql
configuration directory for the current release of Oracle HTTP Server:
cd $ORACLE_HOME
/Apache/modplsql/conf
perl dadTool.pl -o
Notes:
PlsqlAuthenticationMode
to Basic
and uses dynamic authentication.
SingleSignOn
authentication, this parameter is the name of the schema owner.
password
.
Specifies the username to use to logon to the database.
Category | Value |
---|---|
Syntax |
|
Default |
None |
Example |
|
Notes:
PlsqlAuthenticationMode
to Basic
and uses dynamic authentication.
SingleSignOn
authentication, this parameter is the name of the schema owner.
username
.
Specifies the default procedure to call if none is specified in the URL.
Category | Value |
---|---|
Syntax |
|
Default |
None |
Example |
|
Notes:
default_page
.
Specifies a virtual path in the URL that initiates document download form the document table. For example, if this parameter is set to docs
, then the following URLs will start the document downloading process for URLs of the format:
/pls/dad/docs /pls/plsqlapp/docs
Category | Value |
---|---|
Syntax |
|
Default |
|
Example |
|
Notes:
document_path
.
Specifies the procedure to call when a document download is initiated. This procedure is called to process the download.
Category | Value |
---|---|
Syntax |
|
Default |
None |
Example |
|
Notes:
document_proc
.
Specifies the table in the database to which all documents are uploaded.
Category | Value |
---|---|
Syntax |
|
Default |
None |
Example |
|
Notes:
document_table
.
Specifies the Error Reporting Mode for mod_plsql
errors. This parameter accepts the following values:
mod_plsql
indicates to Oracle HTTP Server the HTTP error that was encountered. Oracle HTTP Server then generates the error page. This can be used with the Oracle HTTP Server ErrorDocument
directive to produce customized error messages.
mod_plsql
generates the error pages, usually a short message indicating the PL/SQL error that was encountered and PL/SQL exception stack, if any. For example:
scott.foo PROCEDURE NOT FOUND
ModplsqlStyle
. mod_plsql
provides more details about the URL, parameters and also produces server configuration information. This mode is for debugging purposes only. Do not use this in a production system, since displaying internal server variables could be a security risk.
Category | Value |
---|---|
Syntax |
|
Default |
|
Example |
|
In older versions of the product, this parameter was called error_style
.
Specifies a pattern for excluding certain procedures, packages, or schema names from being directly executed from a browser. This is a multi-line directive in which each pattern occupies one line. The pattern is case-insensitive and can accept simple wildcards such as *, ? and [a-z]. The default patterns excluded from direct URL access are: sys.*
, dbms_*
, utl_*
, owa_*
, owa.*
, htp.*
, htf.*
.
Setting this directive to "#NONE#"
will disable all protection. This is not recommended for a live site, however, it is sometimes used for debugging purposes.
If this parameter is overridden, the defaults are no longer in effect. In that case, you must explicitly add the default list to the list of excluded patterns.
Notes:
mod_plsql
also disallows any fully qualified procedure names which contain special characters like tabs, newlines, carriage-returns, single-quotes, the reverse slash, the form feed, the open parenthesis, close parenthesis, and space. This cannot be changed.
exclusion_list
.
Oracle Application Server 10g mod_plsql User's Guide for more information regarding security.
See Also:
Specifies the number of rows of content to fetch from the database for each trip, using either owa_util.get_page
or owa_util.get_page_raw
.
By default, mod_plsql
attempts to fetch 200 response lines of output where each line is of 255 bytes. In situations where the response bytes are single-bytes, the response buffer is populated to the maximum and can pack 255*200=51000 bytes for each round trip. However, for responses containing multi-byte data, the byte packing for each row could be less than ideal resulting in lesser bytes getting transferred for each round trip. If your application generates large pages frequently and the response does not fit in one round trip, then consider setting this parameter higher. However, the memory usage for mod_plsql
will increase.
Category | Value |
---|---|
Syntax |
PlsqlFetchBufferSize |
Default |
200 |
Example |
|
Notes:
mod_plsql
makes to the database to fetch the response.
get_page
or get_page_raw
fetching fewer bytes for each row (calculations in the OWA Web ToolKit are character-based and in the case of multi-byte characters, OWA packages assume a worst-case character byte size and do not attempt to pack each row to its maximum).
response_array_size
.
Specifies what mode mod_plsql
should use to do extra performance logging.
The mode is:
InfoDebug: This logs more information to the Apache's error_log
. This is used in conjunction with Apache's "info" logging level. If the Apache's logging level is not at least set to this high, this setting will be ignored.
Category | Value |
---|---|
Syntax |
|
Default |
Empty |
Example |
|
This logging setting is useful for debugging problems in your PL/SQL application.
Specifies the maximum number of requests a pooled database connection should service before it is closed and re-opened.
Category | Value |
---|---|
Syntax |
|
Default |
1000 |
Example |
|
Notes:
reuse
. Instead of taking a value of "Yes" or "No", the new parameter enables you to have finer control over the connection pool reuse in mod_plsql
.
Specifies the NLS_LANG
variable for this DAD. This parameter overrides the NLS_LANG
environment variable. When this parameter is set, the PL/SQL Gateway uses the specified NLS_LANG
to connect to the database. Once connected, an alter session command is issued to switch to the specified language and territory. If the middle tier character set matches that of the database, then no alter session call is issued by mod_plsql
.
Category | Value |
---|---|
Syntax |
|
Default |
None |
Example |
|
Notes:
PlsqlTransferMode
set to CHAR
which means that the character set in
PlsqlNLSLanguage
needs to match the character set of the database. In one special case, where the database and mod_plsql
are both using fixed-size character sets, and the character set width matches, the character set can be different. The response character set is always the mod_plsql
character set.
PlsqlTransferMode
is set to RAW
, then this parameter can be ignored.
nls_lang
.
Specifies a virtual path alias to map to a procedure call. This is application specific.
Category | Value |
---|---|
Syntax |
|
Default |
None |
Example |
|
Notes:
Oracle Application Server 10g mod_plsql User's Guide for more information about path aliasing functionality.
See Also:
pathalias
.
Specifies the procedure to call when the virtual path in the URL matches the path alias as configured by PlsqlPathAlias
.
Category | Value |
---|---|
Syntax |
|
Default |
None |
Example |
|
Notes:
Oracle Application Server 10g mod_plsql User's Guide for more information about path aliasing functionality.
See Also:
pathaliasproc
.
Specifies the cookie name when PlsqlAuthenticationMode is set to SingleSignOn
. This parameter is supported only for Oracle Application Server releases, and is used by the Oracle Application Server Portal and Oracle Application Server Single Sign-On.
Category | Value |
---|---|
Syntax |
|
Default |
Same as DAD name |
Example |
|
Notes:
SingleSignOn
authentication, this parameter can be omitted. In most other cases, the session cookie name should be omitted (and this parameter automatically defaults to the DAD name).
sncookiename
.
Specifies how package and session state should be cleaned up at the end of each mod_plsql
request.
StatelessWithResetPackageState
causes mod_plsql
to call dbms_session.reset_package_state
at the end of each mod_plsql
request.
StatelessWithPreservePackageState
causes mod_plsql
to call htp.init
at the end of each mod_plsql
request. This cleans up the state of session variables in the OWA Web ToolKit. The PL/SQL application is responsible for cleaning up its own session state. Failure to do so causes erratic behavior, in which a request starts recognizing or manipulating state modified in previous requests.
StatelessWithFastResetPackageState
causes mod_plsql
to call dbms_session.modify_package_state(dbms_session.reinitialize)
at the end of each mod_plsql
request. This API is a lot faster than the mode of StatelessWithResetPackageState
, and avoids some latch contention issues, but exists only in database versions 8.1.7.2 and higher. This mode uses up slightly more memory than the default mode.
Category | Value |
---|---|
Syntax |
|
Default |
|
Example |
|
Notes:
stateful
.
stateful=no
or stateful=STATELESS_RESET
corresponds to PlsqlSessionStateManagement StatelessWithResetPackageState
stateful=STATELESS_FAST_RESET
corresponds to PlsqlSessionStateManagement StatelessWithFastResetPackageState
stateful=STATELESS_PRESERVE
corresponds to PlsqlSessionStateManagement StatelessWithPreservePackageState
mod_plsql
does not support stateful mode of operation. To equip PL/SQL applications with stateful behavior, save state in cookies and/or in the database.
Specifies the transfer mode for data from the database back to mod_plsql
. Most applications use the default value of CHAR
.
Category | Value |
---|---|
Syntax |
|
Default |
|
Example |
|
Notes:
CHAR
mode is useless, since it always converts the response data from the database character set to the mod_plsql
character set.
RAW
transfer mode was not supported.
Specifies the extensions to be uploaded as LONGRAW
data type, as opposed to using the default BLOB
data type. The default can be overridden by specifying multi-line directives of file extensions for field. A value of '*' in this field causes all documents to be uploaded as LONGRAW
.
Category | Value |
---|---|
Syntax |
|
Default |
None |
Example |
|
Notes:
Oracle Application Server 10g mod_plsql User's Guide for more information about upload and download processes and the structure of the restrictions on the document table format.
See Also:
upload_as_log_raw
.
cache.conf file contains the cache settings for mod_plsql
. This file contains parameters which specify the characteristics of the mod_plsql
cache system.
See Also:
This file is relevant only if the PL/SQL Application uses the |
The following parameters are specified in cache.conf
file:
PlsqlCacheCleanupTime
PlsqlCacheDirectory
PlsqlCacheEnable
PlsqlCacheMaxAge
PlsqlCacheMaxSize
PlsqlCacheTotalSize
Specifies the time to start the cleanup of the cache storage.
This setting defines the exact day and time in which cleanup should occur. The frequency can be set as daily, weekly, and monthly.
Everyday
" is used. The cleanup starts everyday at the time defined. For example, Everyday 2:00
. This causes the cleanup to happen everyday at 2 AM (local time) in the morning.
Sunday
", "Monday
", "Tuesday
", and so on are used. For example, Wednesday 15:30
. This causes the cleanup to happen every Wednesday at 3:30 PM (local time) in the afternoon.
Everymonth
" is used. The cleanup starts at the Saturday of the month at the time defined. For example, Everymonth 23:00
. This causes the cleanup to happen the first Saturday of every month at 11:00 PM (local time) at night.
Category | Value |
---|---|
Syntax |
|
Default |
Saturday 23:00 |
Example |
|
Specifies the directory where cache files are written out by mod_plsql
. This directory must exist or else Oracle HTTP Server will not start.
On UNIX, this directory must have write permissions by the owner of the child httpd processes.
Category | Value |
---|---|
Syntax |
|
Default |
none |
Example |
|
In older versions, this parameter was called "cache_dir
" and resides in the "[PLSQL Cache]" section of ORACLE_HOME
/Apache/modplsql/cfg/cache.cfg
.
Enables mod_plsql
caching.
Category | Value |
---|---|
Syntax |
PlsqlCacheEnable |
Default |
Off |
Example |
PlsqlCacheEnable |
Notes:
OWA_CACHE
packages, in the PL/SQL Web Toolkit, then you can choose to disable caching. In such situations, there will be a very minor performance benefit.
ORACLE_HOME
/Apache/modplsql/cfg/cache.cfg
.
Specifies the maximum time, in days, a cache file can be allowed to reside in a file system cache, after which the cached file will be removed for cache maintenance.
This setting is to ensure that the cache system does not contain old content. This setting removes old cache files and makes space for new ones.
Category | Value |
---|---|
Syntax |
|
Default |
30 (30 days) |
Example |
|
Specifies the maximum possible size of a cache file.
This setting is to prevent the case in which one file can fill up the entire cache. In general, it is recommended that this be set to about 1-3 percent of the total cache size.
Category | Value |
---|---|
Syntax |
|
Default |
1048576 (1 MB) |
Example |
|
In older versions, this parameter was called "max_size
" and resided in the "[PLSQL Cache]" section of ORACLE_HOME
/Apache/modplsql/cfg/cache/cfg
.
Specifies the total size of the cache directory.
This setting limits the amount of space the cache is allowed to use. Both PLSQL cache and Session Cookie cache share this cache space. Note that this setting is not a hard limit. It might exceed the limit temporarily during normal processing. This is normal behavior.
The cleanup algorithm uses this setting to determine how much to reduce the cache files. Therefore, the real space limit is the physical storage's available size.
This parameter takes bytes as values;
Category | Value |
---|---|
Syntax |
|
Default |
20971520 (20 MB) |
Example |
|
In older versions, this parameter was called "total_size
" and resided in the "[PLSQL Cache]" section of ORACLE_HOME
/Apache/modplsql/cfg/cache/cfg
.
This module provides proxy capability for FTP
, CONNECT
(for SSL), HTTP/0.9, HTTP/1.0, and HTTP/1.1.
See Also:
|
Oracle HTTP Server provides mod_rewrite
as a tool for URL manipulation. A rewriting engine based on a regular-expression parser is used by mod_rewrite
to rewrite requested URLs. The granularity of URL manipulations can be affected by the formats of server variables, environment variables, HTTP headers, and time stamps.
This module operates on the full URLs (including the path-info part) both in per-server context (httpd.conf
) and per-directory context (
.htaccess
) and can generate query-string parts on result.
The following topics are discussed in sections below:
Apache processes HTTP in phases. A hook for each of these phases is provided by the Apache API. mod_rewrite
uses two of these hooks- the URL-to-filename translation hook which is used after the HTTP request has been read but before any authorization starts, and the Fixup hook which is triggered after the authorization phases and after the per-directory configuration files (.htaccess
) have been read, but before the content handler is activated.
mod_rewrite
reads the configured rulesets from its configuration structure. Server level rulesets are best configured at startup, while directory level rulesets are configured during the directory access of the kernel.
mod_rewrite
loops through the ruleset rule by rule (RewriteRule
directive) and when a particular rule matches, it loops through corresponding conditions (RewriteCond
directives). First the URL is matched against the Pattern
of each rule. When it fails, mod_rewrite
looks for corresponding rule conditions. If none are present, it just substitutes the URL with a new value which is constructed from the string Substitution
and goes on with its rule-looping. But if conditions exist, it starts an inner loop for processing them in the order that they are listed.
For conditions, a string TestString
is created by expanding variables, back-references map lookups, and then CondPattern
is matched against the expanded TestString
. If the pattern does not match, the complete set of conditions and the corresponding rule fails. If the pattern matches, then the next condition is processed until no more conditions are available. If all conditions match, processing is continued with substituting the URL using Substitution
.
When request seeks a URL with more than one slash (/), for example, http://
yourserver
//oldpath/rqstdrsrc
, the "//oldpath
" may bypass RewriteCond
and RewriteRule
directives if they are not correctly written.
For example, consider the following rule:
RewriteRule ^/oldpath(.*) /newpath$1 [R]
Requesting http://
yourserver
/oldpath/files
will redirect and return the page http://
yourserver
/newpath/files
as expected.
However, requesting http://
yourserver
//oldpath/files
will bypass this particular rule, potentially serving a page that you were not expecting it to. You can work around the problem by making sure that rules will capture more than one slash (/). To fix the example above, you should use this replacement:
RewriteRule ^/+somepath(.*) /otherpath$1 [R]
This section discusses the following mod_rewrite
directives:
Enables or disables the runtime rewriting engine. If it is set to "Off", this module does no runtime processing at all. Use this directive to disable the module instead of commenting out all the RewriteRule
directives.
Rewrite configurations are not inherited by default. This means that you need to have ReWriteEngine On
directive for each virtual host in which you want to use it.
By specifying RewriteOptions
'inherit', you can force the configuration of the parent by the children. In virtual-server context this means that the maps, conditions and rules of the main server are inherited. In directory context this means that conditions and rules of the .htaccess
configuration of the parent directory are inherited.
Sets the name of the file to which the server logs any rewriting action that it performs. If the name does not begin with a slash (/), then it is assumed to be relative to the Server Root
. To disable logging, either remove or comment out the RewriteLog
directive or use RewriteLogLevel 0
. Avoid setting the filename to /dev/null
to prevent logging. This can slow down the server with no advantage.
Sets the verbosity level of the rewriting log file. The default level 0 means no logging, while 9 or more means that practically all actions are logged.
Explicitly sets the base URL for pre-directory rewrites. Rewrite rule can be used in per-directory configuration (.htaccess
) files. When a substitution occurs for a new URL, the base URL should be added into the server processing. To be able to do this, the module needs to know what the corresponding URL-prefix or URL-base is. By default, this prefix is the corresponding file path itself. However, at most Web sites, URLs are not directly related to physical filename paths. In such cases, you have to use the RewriteBase
directives to specify the correct URL-prefix.
If the URLs of your Web server are not directly related to physical file paths, you have to use RewriteBase
in every .htaccess
files where you want to use RewriteRule
directives.
Assume the following per-directory configuration file:
## /abc/def/.htaccess - - per-dir config file for directory /abc/def # /abc/def is the physical path of /xyz, RewriteEngine On RewriteBase /xyz RewriteRule ^oldstuff\.html$ newstuff.html
In Example 8-12, a request to /xyz/oldstuff.html
gets correctly rewritten to the physical file /abc/def/newstff.html
.
Table 8-6 provide hints for using rewrite rules.
Value | Definition |
---|---|
. |
Any single character |
[char] |
Any character listed within a square bracket |
b* |
Any character b any number of times |
.* |
Any character any number of times |
For example, if you want to redirect requests from /demo1
, /demo2
, and /demo3
to /alldemos
, write the rewrite rule as one of the following:
RewriteRule /demo. /alldemos [R]
or,
RewriteRule /demo [123] /alldemos [R]
If you intend that /DemoA
, /DemoB
, and /DemoC
to be redirected to /alldemos
, add NC (no case) to the above rewrite rules, such as:
RewriteRule /demo [123] /alldemos [R, NC]
This rewrite rule will not work to redirect from /demonstration1
to /demos
, because "." works form one character only. To enable redirection of all URLs beginning with "demo", irrespective of subsequent characters, use the rewrite rule as follows:
RewriteRule ^/demo* /alldemos [R, NC]
In the above example, ^ means the beginning, * means any character after demo.
If there was a request for /demo1/not_just_index.html
, al the above rewrite rules would have redirected the request the request to /alldemos/index.html
, that may not be what you want. It is quite possible that you may want to redirect to the corresponding files in /alldemos
, as listed in Table 8-7.
Request for | Redirected to |
---|---|
|
|
|
|
|
|
Then you have to use substitution in your rewrite rule as follows:
RewriteRule ^/demos1(.*)$ //alldemos/$1 [R NC]
The explanation for this rule is:
Take the value of the expression, such as happy.html
, go.jpg
, and lucky.jpg
, that appears after demo1
as variables ($1) and substitute it after /alldemos/
.
See Also:
Module |
For redirecting requests from the DocumentRoot
to a directory called newroot
, set the following mod_rewrite
directives:
RewriteEngine On RewriteRule ^/(.*)$ /newroot/$1 [R]
For directing requested for files from one directory (olddir
) to another (newdir
), set the following directives:
RewriteEngine On RewriteRule ^/olddir(.*)$ /newdir/$1 [R]
In each of these cases, you should ensure that the requested resources are indeed available in the redirected location. The mod_rewrite
module does not ensure the existence of the requested resource in the new location.
For disabling all requests using the HTTP
TRACE
method, set the following mod_rewrite
directives:
RewriteEngine On RewriteCond %{REQUEST_METHOD} ^TRACE RewriteRule .* - [F]
This module enables you to set environment variables based on characteristics of a request.
See Also:
Module |
This module loads executable code and modules into the server at start-up time.
See Also:
Module |
This module attempts to correct misspelled or miscapitalized URLs.
See Also:
Module |
This module displays an HTML page of server activity and performance.
See Also:
Module |
This module creates a unique ID for each request.
See Also:
Module |
This module is available on UNIX systems only.
This module maps requests to user-specific directories.
See Also:
Module |
This module tracks user activity by creating a log.
See Also:
Module |
This module enables dynamically configured mass virtual hosting.
See Also:
Module |
|
![]() Copyright © 2002, 2003 Oracle Corporation. All Rights Reserved. |
|