Managing the Oracle HTTP Server

Oracle HTTP Server (OHS) takes the Apache Web Server and significantly extends it. This article, the first of a five-part series, introduces you to the server. It is excerpted from chapter five of the book Oracle 10g Application Server Exam Guide, written by Sam Alapati (McGraw-Hill, 2006; ISBN: 0072262710).

CERTIFICATION OBJECTIVE 5.01

Introduction to the Oracle HTTP Server

Oracle HTTP Server (OHS) is OracleAS 10g’s Web Server component and is based on the Apache 1.3 Web server. OHS handles client HTTP requests and can serve static and dynamic content in response. OHS supports Server Side Includes as well as providing load-balancing capabilities. As you probably know, the Apache Web server is the most popular Web server today on the Internet, hosting more Web sites than any other Web server. OHS extends the highly flexible, stable, and highly scalable Apache with several custom modules or "mods" in order to provide specialized Oracle functionality in addition to a high availability infrastructure that helps to manage process, death detection, and failover. You can also use the OHS to access several Oracle components such as Forms, Reports, and the OracleAS Portal via the Web. You can also access Oracle stored procedures through the OHS.

In the OHS directories, you’ll often see a reference to Apache files. In fact, the base directory for the OHS is named $ORACLE_HOME/Apache/Apache directory. This is so because OHS is built from the basic Apache Web server, specifically, the Apache version 1.3.

Here are some of the salient features of OHS in relation to OracleAS 10g:

  1. OHS supports SSL encryption based on industry standard algorithms. The SSL capability is special to the Oracle HTTP Server and isn’t a part of the standard Apache Web server’s capabilities.
  2. OHS supports both standard authentication features of HTTP servers, storing credentials in 
    flat files; it also supports the OracleAS Single Sign-On feature, with the help of the Oracle-supplied mod_osso module.
  3. Using the virtual host feature, OHS can service multiple domain names over a single IP address. Virtual hosting capability is part of the core Apache Web server features.
  4. OHJS provides support for distributed authoring and versioning (DAV), with the help of WebDav. Oracle’s mod_oradav module provides support for this.
  5. OHS supports URL rewriting so users don’t have to change bookmarks in order to change URLs. The support for reverse proxy capabilities makes content provided by multiple servers appear as though it were coming from the same server. URL rewriting is a part of the Apache Web server’s basic features.

Important OHS Components

OHS consists of the following important components:  

  • HTTP Listener    This is based on the Apache HTTP listener; it listens to and handles incoming connection requests.
  • Modules (mods)    The OHS modules extend the functionality of the OHS Server. There are two types of modules: standard Apache modules and OracleAS-specific modules. In addition, OHS offers enhanced versions of the standard HTTP server (Apache) modules.
  • Perl Interpreter    The final OHS component is a persistent PERL runtime environment, enabled by the mod_perl Apache module.

Oracle HTTP Server Modules

The Apache HTTP Server contains a core set of features, which are extended by the use of dynamic shared objects called modules. Modules are loaded into the HTTP Server when the server starts, and are used for extending the basic capabilities of the Apache server. Oracle HTTP Server includes the basic Apache HTTP server modules and additionally provides specialized Oracle-specific modules. These Oracle modules enhance the HTTP server’s capabilities and enable its integration with other OracleAS components. Heres a brief description of the important Oracle-provided OHS modules:

  • mod_certheaders enables reverse proxy servers such as the OracleAS Web Cache to transfer SSL connection information to OHS, using HTTP headers. The information is transferred to the standard CGI environment variables from the certificate headers. Using certain mod_certheader directives, some HTTP requests can be treated as HTTPS requests.
  • mod_dms enables performance monitoring of various components using Oracle’s Dynamic Monitoring Service (DMS).
  • mod_oc4j routes requests from the Oracle HTTP Server to the Oracle Application Server Containers for J2EE (OC4J).
  • mod_onsint provides integration support with Oracle Notification Service (ONS) and Oracle Process Manager and Notification Server (OPMN).
  • mod_oradav enables WebDAV clients to connect to an Oracle database and process information in various schemas. Mod_oradav is based on Apache’s mod_dav module, which is how Apache implements the WebDAV specification. The WebDAV protocol helps multiple authors to work with Web content by letting them share and edit common files.
  • mod_ossl enables the OHS to use Secure Socket Layers (SSL), which enables the use of strong cryptography.
  • mod_osso supports the OracleAS Single Sign-On feature.
  • mod_plsql enables the Oracle HTTP Server to connect to an Oracle database and enables Web applications to use Oracle stored procedures, using the PL /SQL Gateway.
  • mod_wchandshake enables the OracleAS Web Cache to automatically discover the Oracle HTTP Server.

on the job:  OHS doesn’t load all the modules in the httpd.conf file automatically upon a start or restart. It dynamically loads the modules as and when they are needed.

{mospagebreak title=The Oracle HTTP Server Processing Model}

Once you start the Oracle HTTP server, it listens for connection requests and passes them on to the appropriate service. The spawning of these listener processes differs in UNIX and Windows servers. In a UNIX /Linux system, the OHS control process launches several copies of itself, known as child processes, to listen to user’s requests. The main process runs as the root user and the child processes under a less privileged user account, usually a UNIX user named "nobody. " Each child process is another instance of the httpd program, as you can see from the output below.

[] $root 12928 1 0 Apr 11 ? 36:06 /opt/hpws/apache/bin/httpd -d
/opt/hpws/apache -k start

awuser

 7898

22238

0

May 16

?

 0:14

/opt/apache/bin/httpd

-DSSL

awuser

12653

22238

0

May 19

?

 0:12

/opt/apache/bin/httpd

-DSSL

awuser

22249

22238

0

May 16

?

 0:14

/opt/apache/bin/httpd

-DSSL

awuser

22248

22238

0

May 16

?

 0:15

/opt/apache/bin/httpd

-DSSL

awuser

22250

22238

0

May 16

?

 0:15

/opt/apache/bin/httpd

-DSSL

  root

22238

    1

0

May 16

?

18:55

/opt/apache/bin/httpd

-DSSL

$

On a Windows server, there is a multithreaded implementation of the HTTP server process, which involves a single control process and just one child process; it creates multiple threads to listen to connection requests. Thus, the child processes actually aren’t separate processes but threads within a single child process.

Under both UNIX and Windows systems, the httpd.pid
file, located in the $ORACLE_HOME/Apache/Apache/logs directory, contains the process ID of the original OHS process.

Starting and Stopping the Oracle HTTP Server

You start and stop the OHS with the help of the opmnctl tool, which was explained in Chapter 3. When you use the startall command, all OracleAS components, including the OHS, are started by OPMN. Similarly, by using the stopall command, you can stop all the OracleAS processes. You can also start just the OHS server itself using the following command:

  $ opmnctl startproc ias-component=HTTP_Server

You stop the OHS component by using the following opmnctl command:

  $ opmnctl stopproc ias-component=HTTP_Server

Although you can start and stop the OHS processes with the opmcntl command as shown here, it’s best to start OHS as part of the entire component stack of the OracleAS instance, because OHS is a key component of the OracleAS instance and you may run into problems by starting and stopping just the OHS by itself. You may also reconfigure, start, and stop the OHS server from the Application Server control console.

on the job:  You mustn’t use the apachectl script, traditionally used to start up the Apache Web server, to start the OHS.

{mospagebreak title=Oracle HTTP Server Installation and Configuration}

By default, Oracle HTTP Server is installed in the $ORACLE_HOME /Apache directory on UNIX and the $ORACLE_HOME /Apache directory on Windows. The Apache directory contains subdirectories for
configuring various modules. There’s a subdirectory that’s also named Apache under the main Apache directory, and this is the base directory of Oracle HTTP Server ($ORACLE_HOME/Apache/Apache). Each of the OHS modules such as mod_oradav, for example, has its own directory under the OHS home directory, which is the $ORACLE_HOME /Apache directory. Here are the important subdirectories under the $ORACLE_HOME/Apache/Apache directory:

  • bin contains OHS binaries or executables.
  • cgi-bin contains the CGI scripts that the OHS executes on behalf of various clients. This is the default location for the CGI scripts, but in fact, you can store them anywhere on the server.
  • logs contains both OHS access logs and the error logs.
  • conf contains the configuration files.
  • htdocs contains the HTML scripts. Note that this is also just a default directory from which OHS serves all its static Web documents. Because these are easily accessible by outsiders, you must use alternative locations for storing the Web documents.

on the job:  Because the htdocs directory allows access to anyone on the Web, you must keep only publicly available information in this directory.

  • include contains header files for creating custom modules.
  • PHP contains sample code for mod_php and the PHP executables.

The main Oracle HTTP Server configuration file is called httpd.conf and is located in the ORACLE_HOME/Apache/Apache/conf directory in UNIX and Linux based systems and the ORACLE_HOMEApacheApacheconf directory in a Windows system. You can manually edit the httpd.conf file to reconfigure the HTTP server, but Oracle recommends against your doing so. The preferred method to make configuration changes is by accessing the httpd.conf file using the Application Server Control Console. You must go to the Advanced Server page from the OHS home page and click the httpd.conf file. You can then view and edit the configuration file. Figure 5-1 shows the httpd.conf file in the Application Server Control Console. Note that the httpd.conf is only the main configuration file for OHS. However, you may include pointers to other configuration files such as the oracle_apache.conf file, which is used to load specified Oracle-related modules and is usually included as a
file inside the httpd.conf file.

Remember that the recommended way to modify the OHS configuration is through the Application Server Control Console. This way, the metadata repository information will be updated automatically, unlike the case with the manual modification of the httpd.conf file.

Here are some important things to remember about the configuration files:

  • There’s one directive per line.
  • Directives are case insensitive.


    Figure 5-1.   The httpd.conf Configuration File

  • Arguments to the directives are case sensitive.
  • You can’t include comments after a directive, but you can include comments on their own line by prefixing the pound (#) sign.
  • Any blank lines or white spaces in between lines are ignored.

exam watch:  You configure the Oracle HTTP Server with directives.

Other Server Configuration Files

The httpd.conf file, as mentioned, is the primary
configuration file for the Oracle HTTP Server. This file contains directives as well as pointers to other
configuration files. Here’s a brief summary of the other configuration files:

  • mod_oc4j.conf   This file helps you configure the mod_oc4j module, which carries requests from the HTTP Server to OC4J.
  • mime.types   The mime.types file contains extra Internet media types to be sent to clients so they can handle file contents. You can also include the AddType directive in this file. 
  • oracle_apache.conf   This is the main file for storing configuration files of all supported modules such as moddav and plsql . Here are the typical contents of the oracle_apache.conf file:

    # Advanced Queuing-AQ XML
    include "C:OraHome_2rdbmsdemoaqxml.conf"
    # Directives needed for OraDAV module include "C:OraHome_2Apacheoradavconfmoddav.conf" include "C:OraHome_2Apachejspconfojsp.conf"
    include "C:OraHome_2Apachemodplsqlconfplsql.conf"
    # Oracle uix
    include "C:OraHome_2uixuix.conf" #OiD DAS module
    include "C:OraHome_2ldapdasoiddas.conf"
    #Directives needed for SSO module include "C:OraHome_2ssoconfsso_apache.conf"
    #Directives needed for OCM module include "C:OraHome_2ApacheApacheconfocm_apache.conf"

Note that some of the minor configuration files can be read each time a related file or directory is requested by a client. Some files, on the other hand, are read only once, when the OHS instance is started. These
files, like the main configuration file httpd.conf file, are called server-wide configuration files.

{mospagebreak title=OHS Directives}

Directives are configuration instructions that govern the behavior of the OHS Server, and there is one directive per line in the OHS configuration files. OHS directives let you customize the Web server for your organization’s needs. All you have to do to configure OHS is to simply make changes to the httpd.conf file. Throughout this chapter, the various OHS
configuration directives are explained in detail. In fact, most of this chapter is devoted to the explanation of various OHS configuration directives. A given
configuration directive can’t arbitrarily be used anywhere you want. You can use each directive in a specific context. There are four contexts in which the configuration directives can be applied:

  • Server config    A directive is said to have a server config context if it can be used only in the main server configuration file ( httpd.conf ) and not inside any scope-limiting containers such as <Directory> and <VirtualHost>. You can’t use these directives in . htaccess files either.
  • virtual host   A directive that has a virtual host context can be placed only within the <VirtualHost> containers in the server
    configuration files.
  1. directory   A directive in the directory context can be used in the main server configuration file, but only within the <Directory>, <Location>, and <Files> containers.
  2. htaccess   A directory that’s valid in the . htaccess context, can be placed only inside the per-directory .htaccess files. Of course, depending on the override settings, the file itself may or may not be processed.

Depending on the context in which the server issues a directive, there are three classes of directives, as described in the following paragraphs.

Global    Global directives belong to the server
configuration context
and apply to the entire OHS server. All directives inside the httpd.conf file are global directives, except the so-called container directives (more on this later), which limit the scope of a directive to only a certain area of the OHS. For example, you may want directives in the httpd.conf file not to apply to the entire server but to be restricted only to particular files and directories, or only to certain hosts and URLs. You can then use the various available OHS containers such as <Files>, <Directories>, and <VirtualHost>, to limit the scope of these configuration directives. As another example, the virtual host container limits the directives inside it only to virtual hosts and not the main server. Container directives are always enclosed in start and end tags (e.g., <Virtual Host> and </VirtualHost>).

Per Server    The per-server class of directives can have a server configuration or a virtual host context. In the httpd.conf file, all directives outside the <VirtualHost> container are the per-server class directive for the main server and are in the server
configuration context. Similarly, all directives inside the <VirtualHost> container are directives in the virtual host context and apply only to virtual hosts and not to the main server.

exam watch:   A container allows youto limit the scope of the configuration directives only to a specific area instead of the entire server. OHS applies any directives within a container to the area specified by the container.

Per Directory    The per-directory class directives can belong to any of the four contexts: server
configuration, virtual host, directory, or . htaccess . You can use these directives anywhere.

exam watch:  Directives are alwaysapplied hierarchically, with a directive overriding all directives in the tiers that are above it.

Here’s the syntax for specifying a configuration directive (server level) in the httpd.conf file:

   KeepAlive ON

The KeepAlive directive, which is discussed in more detail later on, enables the OHS to maintain persistent connections to the client instead of automatically closing a connection after each request by the client.

Please check back next week for the continuation of this article.

[gp-comments width="770" linklove="off" ]

antalya escort bayan antalya escort bayan Antalya escort diyarbakir escort