Oracle® HTTP Server Administering a Standalone Deployment Based on Apache 2.0
10g Release 2 (10.1.2) B14009-02 |
|
Previous |
Next |
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.
Note: Readers using this guide in PDF or hard copy formats will be unable to access third-party documentation, which Oracle provides in HTML format only. To access the third-party documentation referenced in this guide, use the HTML version of this guide and click the hyperlinks. |
Table 7-1 lists all the Oracle HTTP Server modules discussed in this chapter.
Controls access to the server based on characteristics of a request, such as hostname or IP address.
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, such as OracleAS 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 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
and AddCertHeader
directives.
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.
AddCertHeader
is specifically for use with OracleAS Web Cache. For OracleAS Web Cache, it adds a special header that indicates to Oracle HTTP Server which requests OracleAS Web Cache received through HTTPS. mod_certheaders
triggers Oracle HTTP Server to only treat those cases where OracleAS Web Cache received the request as HTTPS as if Oracle HTTP Server received it through HTTPS.
Perform the following steps to configure mod_certheaders
:
Configure Oracle HTTP Server to load mod_certheaders
. To do this, add a LoadModule
directive to httpd.conf
file:
UNIX: LoadModule certheaders_module libexec/mod_certheaders.so
Windows: LoadModule certheaders_module modules/ApacheModuleCertHeaders.dll
Specify which headers should be translated to CGI environment variables. This can be achieved by using the AddCertHeader
directive. This directive takes a single argument, which is the CGI environment variable that should be populated from a HTTP header on incoming requests. For example, to populate the SSL_CLIENT_CERT
CGI environment variable, add the following line to httpd.conf
:
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 7-2 lists all the supported CGI environment variables with their corresponding HTTP header names.
Table 7-2 CGI Environment Variables with Corresponding Header Names
CGI Variable | Header Name | CGI Variable | Header Name |
---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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 OracleAS 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/
.
Edit the $ORACLE_HOME/sso/conf/sso_apache.conf, and comment out the following line:
#SSLOptions +ExportCertData +StdEnvVars
Runthe following command:
dcmctl updateconfig -ct ohs
Run the following command:
opmnctl restartproc type=ohs
Test that the SSO server can be logged into with client authentication.
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 Application Server Containers for J2EE (OC4J), through the AJP 1.3 protocol. It is an Oracle module.
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:
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
:
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 |
|
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 |
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 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.
|
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 7-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 7-2 Sample mod_oc4j configuration
This configuration performs the same work as the configuration in Example 7-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 7-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 the obfuscated 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 | Obfuscated password used for authentication when opening the wallet file specified by Oc4jSSLWalletFile. |
Default Value | N/A |
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 a SSO wallet instead. |
To enable SSL communication between mod_oc4j
and OC4J, you have to enable SSL on the OC4J side too.
See Also: Oracle Application Server Containers for J2EE Security Guide for enabling SSL on the OC4J side. |
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
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.
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.
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.
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.
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:
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:
UNIX: ORACLE_HOME
/opmn/bin> opmnctl
[verbose]
restartproc ias-component=HTTP_Server
Windows: ORACLE_HOME
\opmn\bin> opmnctl
[verbose]
restartproc ias-component=HTTP_Server
Files must be copied to ORACLE_HOME
/ohs/cgi-bin
Example 7-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 7-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 7-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 7-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 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
.
Example 7-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:
|
Orovides proxy capability for FTP
, CONNECT
(for SSL), HTTP/0.9, HTTP/1.0, and HTTP/1.1.
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 7-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 7-10, a request to /xyz/oldstuff.html
gets correctly rewritten to the physical file /abc/def/newstff.html
.
Table 7-3 provide hints for using rewrite rules.
Table 7-3 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
, al 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 7-4.
Table 7-4 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]