Oracle® HTTP Server Administering a Standalone Deployment Based on Apache 2.0 10g (10.1.3.1.0) Part Number B28949-01 |
|
|
View PDF |
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.
Table 6-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.
Enables manipulation of URLs in processing requests. It provides mapping between URLs and file system paths, and URL redirection capabilities.
Enables anonymous user access to protected areas (similar to anonymous FTP, where the email addresses can be logged).
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.
Allows 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 is an Oracle module.
It also allows certain requests to be treated as HTTPS requests even though they are received through HTTP. This is done using the SimulateHttps
directive.
SimulateHttps
takes the container it is contained within, such as <VirtualHost>, <Location>, and so on, and treats all requests received for this container as if they were received through HTTPS, regardless of the real protocol that the request was received through.
Except for the optimizations and the additional ScriptSock
directive, this module functions similarly to mod_cgi. The ScriptSock
directive sets the name of the socket to use for communication with the CGI daemon. The socket will be opened using the permissions of the user who starts Apache (usually root).
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/
Enables you to control the environment for CGI scripts and SSI (Server Side Includes) pages by passing, setting, and unsetting environment variables.
ModifyEnv
appends or prepends a value to an existing ENV
variable's value, and passes it into the Oracle HTTP Server environment. The following is the usage:
Let $FOO
= "foo"
:
ModifyEnv FOO "bar" modifies the value of $FOO from "foo" to "foo:bar"
ModifyEnv FOO "+bar" modifies the value of $FOO from "foo" to "bar:foo"
Let $FOO
be undefined:
Modify Foo "bar" sets the value of $FOO to "bar"
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.
Supports the FastCGI protocol, which enables you to maintain a pool of running servers for CGI applications, thereby eliminating start-up and initialization overhead.
Provides techniques for caching frequently requested static files. This module should be used with care as you can easily create a broken site.
Provides a filter that processes documents for SSI (Server Side Includes) directives.
Summarizes the entire server configuration, including all installed modules and directive settings.
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.
Provides the logging of input and output numbers of bytes received and sent per request. The numbers reflect the actual bytes as received on the network, which then takes into account the headers and bodies of requests and responses.
Enables the server to determine the type of a file from its filename, and associate files with handlers for processing.
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.
Enables the server for content negotiation (selection of documents based on the client's capabilities).
Routes requests from the Oracle HTTP Server to Oracle Containers for J2EE (OC4J), through the AJP 1.3 protocol. It is an Oracle module and is enabled by default.
Each OC4J is assigned a routing ID from opmn.xml. Oracle Process Mangement and Notification Server (OPMN) sends notifications, for each OC4J, that contain the routing ID for that OC4J. Upon receiving the routing ID, mod_OC4J compares the OC4J routing ID to the OHS routing IDs and dynamically adds the OC4Js with matching routing IDs to its routing table.
After installation, by default OHS is configured to use the routing ID in opmn.xml
. The default routing ID is g_rt_id
. OHS routes to all the OC4Js in the newly installed ias-instance
because all the OC4Js have the same default routing ID. If the cluster contains more than one ias-instance
, OHS routes to all the OC4Js with the default routing id.
You can configure routing IDs for Oracle HTTP Server in either of the following configuration files:
ORACLE_HOME
/Apache/Apache/conf/mod_oc4j.conf
ORACLE_HOME
/opmn/conf/opmn.xml
Caution: Do not configure routing IDs for Oracle HTTP Server inopmn.xml and in mod-oc4j.conf . If Oracle HTTP Server is configured with routing IDs in both files, it is considered an error and Oracle HTTP Server will not start. |
To configure a routing ID in opmn.xml
, enter the following in the ias_component
section for Oracle HTTP Server:
<module_data>
<category id="start-parameters">
<data id="routing-id" value="my_id"/>
</category>
</module-data>
To configure routing IDs in mod_oc4j.conf
, see Oc4jRoutingID.
To specify the routing mode, see Oc4jRoutingMode.
For Oracle Application Server 10.1.3, routing IDs and mount point discovery are added so that routing relationships between OHS and OC4Js can be created or changed with minimal or no configuration changes.
OC4J instances are started and managed by Oracle Process Manager and Notification Server (OPMN).
See Also:
|
This section discusses the following topics:
The following sections describe all relevant directives in httpd.conf and mod_oc4j.conf. 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 following directive:
include "ORACLE_HOME/ohs/conf/mod_oc4j.conf"
The following directives are used to configure mod_oc4j
:
See Also: "Using SSL Configuration Directives" on page 9-3 |
Loads the mod_oc4j
module.
Category | Value |
---|---|
Syntax | LoadModule oc4j_module mod_oc4j shared library file |
Required | Yes |
Default |
|
Example |
|
Specifies the size of the OC4J connection cache.
Category | Value |
---|---|
Syntax | Oc4jCacheSize <size of connection cache> |
Required | No |
Default | This is a calculated value that depends on the platform (UNIX/WIN32), the version of Oracle HTTP Server and plugin, and other configuration settings. |
Example | Oc4jCacheSize 64 |
Usage | Specifies the number of concurrent OC4J connections that can be cached by each Oracle HTTP Server process. Setting this directive to "0" will disable persistent connections between mod_oc4j and the OC4J instances. |
Defines maximum idle time (in seconds) for unused connections.
Category | Value |
---|---|
Syntax | Oc4jConnTimeout <timeout value for AJP13 connections> |
Required | No |
Default | None |
Example | Oc4jConnTimeout 10 |
Usage | Useful for cases where there is a firewall between mod_oc4j and OC4J that times out connections. The value should be set to a value smaller than the timeout value used by the firewall. |
Directs mod_oc4j
to use JSESSIONID_<
cookie_name_extension
>
as OC4J's session identifier in the cookie.
Category | Value |
---|---|
Syntax | Oc4jCookieExtension < cookie_name_extension > |
Required | No |
Default | None |
Example | Oc4jCookieExtension MYEXT |
Usage | Directs mod_oc4j to use JSESSIONID_< cookie_name_extension > as OC4J's session identifier in the cookie, instead of JSESSIONID . In the preceding example, JSESSIONID_MYEXT is used as the OC4J's session identifier. |
Governs passing SSL environment variables.
Category | Value |
---|---|
Syntax | Oc4jExtractSSL On|Off |
Required | No |
Default | Off |
Example | Oc4jExtractSSL On |
Usage | Directs mod_oc4j to decide whether or not to pass three SSL environment variables, SSL_CLIENT_CERT , SSL_CIPHER , and SSL_SESSION_ID to OC4J. There is a performance cost associated with copying the SSL environment variables to OC4J, so set it to "On" only if the environment variables must be available to OC4J. |
Directs mod_oc4j
to pass some environment variables from Oracle HTTP Server to OC4J.
Category | Value |
---|---|
Syntax | Oc4jEnvVar environment variable name [environment variable default value] |
Required | No |
Default | None |
Example | Oc4jEnvVar MY_ENV1
|
Usage | For each OC4jEnvVar entry, you must also configure the Oracle HTTP Server directive, PassEnv , with the environment variable. Otherwise, mod_oc4j cannot acquire and pass the value.
Multiple entries are allowed. You could specify the default value for the environment variable as the second parameter, or leave it empty. If the environment variable's value is found in the Oracle HTTP Server environment, its value will be passed to OC4J. Otherwise, if the default value is set, the default value will be passed. If this environment variable's value is not found in the Oracle HTTP Server environment and the default value is not set, nothing is passed to OC4J. There is a performance degradation associated with |
For Oracle Application Server 10.1.3, OC4Js announce their mount points in ONS notifications. This allows mod_OC4J
to dynamically detect and update the mount points for OC4Js to which it is routing. This eliminates the need for static mount point configuration, and enables mod_OC4J
to update mount point configurations without stopping and restarting Oracle HTTP Server. If you want to use static mount points, you can use the following configuration information. You must also set Oc4jRoutingMode to static.
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.
Category | Value |
---|---|
Syntax | Oc4jMount path [destination]
where path is the context root. The path parameter must be the same as the application context root specified in the OC4J configuration file xxx <default-web-app application="default" name="defaultWebApp" root="/j2ee"/> and where destination is one of these types:
If destination is not specified, the default OC4J instance name of
provides the same result as:
|
Required | No |
Default | None |
Examples | Oc4jMount /app01/* ajp13://my-sun:8888
|
Usage | Examples are provided for each routing destination:
A request with the pattern specified in path is routed to an OC4J process listening on my-sun, port 8888 with the AJP 1.3 protocol. (my-sun and port 8888 are the AJP 1.3 protocol host and port specified in the OC4J configuration file xxx
A request with the pattern specified in path is load balanced to one or more of the OC4J processes specified. oc4j processes are separated by commas.
A request with the pattern specified in path is load balanced to one or more of the OC4J instances specified (instances are separated by commas). The Oracle Application Server Cluster Name is optional. If it is provided, the destination OC4J instance should be inside the named cluster. If none is provided, the destination OC4J instance should be inside the local Oracle Application Server cluster.
A request with the pattern specified in <path> is load balanced to one or more of the OC4J instances specified (instances are separated by commas). The host name is optional. If it is provided, the destination OC4J instance should be inside the Oracle Application Server instance residing on that host. If none is provided, the destination OC4J instance could be on any host. |
Copies mount points from the base server.
Category | Value |
---|---|
Syntax | Oc4jMountCopy On|Off |
Required | No |
Default | On |
Example | Oc4jMountCopy Off |
Usage | Directs mod_oc4j to decide whether to copy Oc4jMount points from the base server to the virtual host on which this directive is specified. If its value is On, all of the Oc4jMount points configured in the base server will be copied to the virtual host. If its value is Off , only the Oc4jMount points configured within the virtual host scope will be used. |
Oracle HTTP Server can be assigned one or more routing IDs using Oc4jRoutingID
. When mod_oc4j receives a notification from an OC4J containing a routing ID that matches one in Oc4jRoutingID
, mod_oc4j updates its routing table and begins routing to that OC4J.
Caution: It is possible to configure routing IDs for Oracle HTTP Server inopmn.xml and in mod-oc4j.conf . If Oracle HTTP Server is configured with routing IDs in both places, it is considered an error and Oracle HTTP Server will not start. |
Category | Value |
---|---|
Syntax | Oc4jRoutingID |
Parameter Type | string |
Default | None |
Allowable Values | comma delimited list of routing IDs |
Example | Oc4jRoutingID myroutingid1,myroutingid2, ... |
Specifies whether a virtual server overrides or combines its parents' routing ID lists with its list.
Category | Value |
---|---|
Parameter Name | Oc4jRoutingIDCopy |
Parameter Type | string |
Allowable Values | On/Off (On specifies that that the virtual server combines parents' routing ID list with its list. Off specifies that a virtual server's list overrides its parents' list.) |
Default Value | On |
Example | Oc4jRoutingIDCopy On |
Oc4jRoutingMode specifies the type of routing mode to use. The routing modes are:
Dynamic - specifies dynamic routing using routing IDs. Any static routing encountered is ignored.
Static - specifies static routing. Any dynamic routing encountered is ignored.
DynamicOverride - allows for dynamic or static routing. In case of a conflict, Oracle HTTP Server routes dynamically specified mount points.
StaticOverride - allows for both static and dynamic routing. In case of a conflict, Oracle HTTP Server routes to statically specified mount points.
Category | Value |
---|---|
Parameter Name | Oc4jRoutingMode |
Parameter Type | string |
Allowable Values | Dynamic, Static, DynamicOverride, StaticOverride |
Default Value | StaticOverride |
Example | Oc4jRoutingMode Dynamic |
Allows users to configure an error range using Oracle HTTP Server's error pages when errors in the range are returned from OC4J.
Category | Value |
---|---|
Syntax | Oc4jUseOHSErrors On|Off/min-max |
Required | No |
Default | off |
Example | Oc4jUseOHSErrors 400-410 |
Usage | Oc4jUseOHSErrors Off : This is the default value if Oc4jUseOHSErrors is not specified. OC4J error pages are passed back to the client for all error values.
|
This section provides some sample configurations for mod_oc4j
.
Example 6-1 Sample mod_oc4j configuration
This configuration mounts all requests starting with the URI /servlet/ to the default instance of OC4J processes.
Make this entry in the httpd.conf
file:
Oc4jMount /servlet/*
Example 6-2 Sample mod_oc4j configuration
This configuration performs the same work as the configuration in Example 6-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>
Note: This will only route requests to default the OC4J instance. |
Example 6-3 Sample mod_oc4j configuration
This configuration mounts all requests starting with the URI /servlet/
or /j2ee/
and all JSP pages to the default OC4J instance of OC4J processes.
Make these entries in the mod_oc4j.conf
file:
Oc4JMount /servlet/* Oc4JMount /*.jsp Oc4JMount /j2ee/*
All requests starting with the URI /applicationA/
and all JSP pages to oc4j_instance_A
, in which all OC4J processes are managed by OPMN.
All requests starting with the URI /applicationB/
to oc4j_instance_B
, in which all OC4J processes are managed by 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
mod_oc4j
load balancing, including metric based load balancing, is discussed in detail in Appendix A, "Load Balancing Using mod_oc4j".
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.
Add the following directives in mod_oc4j.conf
to enable SSL for mod_oc4j
:
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 | Oc4jEnableSSL |
Parameter Type | string |
Valid Values | On/Off |
Default Value | Off |
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.
Category | Value |
---|---|
Parameter Name | Oc4jSSLWalletFile |
Parameter Type | string |
Valid Values | Path to a wallet directory location that contains the SSL certificate to be used when establishing SSL connections to OC4J processes. |
Default Value | N/A |
When Oc4jEnableSSL is set to "On", this value is a clear-text password used for authentication when opening the wallet file. This value is obtained using the utility provided with the Oracle Wallet Manager.
Category | Value |
---|---|
Parameter Name | Oc4jSSLWalletPassword |
Parameter Type | string |
Valid Values | Clear-text password used for authentication when opening the wallet file specified by Oc4jSSLWalletFile. |
Default Value | N/A |
See Also:
|
Note: Wallet passwords have been deprecated. A warning message is generated in the Oracle HTTP Server log if this directive is used. For secure wallets, Oracle recommends that you get an auto-login wallet instead. |
Provides integration support with Oracle Notification Service (ONS) and Oracle Process Manager and Notification Server (OPMN). It is an Oracle module.
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 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.
Provides functionality that allows 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.
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 an optional directive called OpmnHostPort
that can be configured for mod_onsint
. This directive enables you to specify a hostname and port that OPMN should use for pinging the Oracle HTTP Server instance that mod_onsint
is running in. If OpmnHostPort
is not specified, mod_onsint
chooses an HTTP port automatically. In certain circumstances, you may want to choose a specific HTTP port and hostname that OPMN should use to ping the listener with.
OpmnHostPort
has the following syntax that specifies the values to pass to OPMN:
OpmnHostPort [<http> | <https>://]<host>:<port>
For example, the following line would specify that OPMN should use HTTP, the localhost interface and port 7778 to ping this listener:
OpmnHostPort http://localhost:7778
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.
Enables strong cryptography for Oracle HTTP Server. This Oracle module is a plug-in to Oracle HTTP Server that enables the server to use SSL. It is very similar to the OpenSSL module, mod_ssl
. 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:
|
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. It is an Oracle module.
See Also: Oracle Application Server Single Sign-On Administrator's Guide |
Embeds the Perl interpreter into the Oracle HTTP Server. This eliminates start-up overhead and enables you to write modules in Perl. Oracle Application Server uses Perl version 5.8.3.
See Also: mod_perl Guide |
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 Call Interface (OCI) to access the databases.
DBI must be enabled in httpd.conf for DBI to function. To do this, perform the following steps:
Edit httpd.conf
using a text editor.
Search for "PerlModule Apache::DBI"
.
Uncomment the line PerlModule Apache::DBI"
.
Restart Oracle HTTP Server using the following command:
ORACLE_HOME/opmn/bin> opmnctl [verbose] restartproc ias-component=HTTP_Server
Files must be copied to ORACLE_HOME
/ohs/cgi-bin
Example 6-5 Using Perl to Access the Database
#!<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>.
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 6-6 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 ######
SQL
NCHAR
datatypes have been refined since 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 aboutSQL NCHAR datatypes. |
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 6-7 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' ); # bind the parameter of a NCHAR type $sth->bind_param( ':nchar1', $param_1 ); # set the character form to NCHAR $sth->func( { ':nchar1' => ORA_NCHAR } , 'set_form' ); $sth->execute;
As shown in Example 6-7, 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 making this call, 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
.
Example 6-8 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' );
PHP (recursive acronym for "PHP: Hypertext Preprocessor") is an open source, widely-used, general-purpose, client-side scripting language, that is embedded in standard HTML. It is used to generate dynamic HTML pages. On Oracle HTTP Server, PHP support is provided through mod_php
and has Oracle database support enabled. It uses PHP version 4.3.9.
Note: phpinfo() prints out very sensitive information about the current state of PHP and Oracle HTTP Server intervals. Users new to PHP, or those who are unaware of phpinfo() should not inadvertantly leave a PHP script called phpinfo() publically accessible.
|
See Also:
|
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 subsequent sections:
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 precedingexample, 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.
Example 6-10 RewriteBase Directive
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 6-10, a request to /xyz/oldstuff.html
gets correctly rewritten to the physical file /abc/def/newstff.html
.
Table 6-2 provide hints for using rewrite rules.
Table 6-2 Rewrite Rules Hints
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 preceding 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 preceding example, ^ means the beginning, * means any character after demo.
If there was a request for /demo1/not_just_index.html
, all the preceding 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 6-3.
Table 6-3 Request Redirection
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/
.
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]
Increases Web application security by protecting Web application from known and unknown attacks.