1 Introduction to Oracle HTTP Server

This chapter serves as an introduction to the Oracle HTTP Server (OHS). It describes key features of OHS and its place within the Oracle Fusion Middleware Web Tier and also provides information on the OHS directory structure, the OHS configuration files, and how to obtain OHS support.

Oracle HTTP Server is the web server component for Oracle Fusion Middleware. It provides a listener for Oracle WebLogic Server and the framework for hosting static pages, dynamic pages, and applications over the Web.

This chapter includes the following sections:

1.1 What is Oracle HTTP Server?

Oracle HTTP Server 12c (12.1.3) is based on Apache HTTP Server 2.2.22 infrastructure (with critical bug fixes from higher versions) and includes modules developed specifically by Oracle. The features of single sign-on, clustered deployment, and high availability enhance the operation of the Oracle HTTP Server. Oracle HTTP Server has the following components to handle client requests:

  • HTTP listener, to handle incoming requests and route them to the appropriate processing utility.

  • Modules (mods), to implement and extend the basic functionality of Oracle HTTP Server. Many of the standard Apache HTTP Server modules are included with Oracle HTTP Server. Oracle also includes several modules that are specific to Oracle Fusion Middleware to support integration between Oracle HTTP Server and other Oracle Fusion Middleware components.

  • Perl interpreter, a persistent Perl runtime environment embedded in Oracle HTTP Server through mod_perl.

Oracle HTTP Server enables developers to program their site in a variety of languages and technologies, such as:

  • Perl (through mod_perl, CGI and FastCGI)

  • C and C++ (through CGI and FastCGI)

  • PHP, Ruby and Python (through CGI and FastCGI)

  • Oracle PL/SQL

Oracle HTTP Server can also be a proxy server, both forward and reverse. A reverse proxy enables content served by different servers to appear as if coming from one server.


For more information about Fusion Middleware concepts, see Understanding Oracle Fusion Middleware.

1.2 Oracle HTTP Server 12c (12.1.3) Topologies

Oracle HTTP Server leverages the WebLogic Management Framework to provide a simple, consistent and distributed environment for administering Oracle HTTP Server, Oracle WebLogic Server, and the rest of the Fusion Middleware stack. It acts as the HTTP front-end by hosting the static content from within and by leveraging its built-in Oracle WebLogic Server Proxy Plug-In 12.1.3 to route dynamic content requests to WebLogic-managed servers. In such cases, there are multiple ways of implementing Oracle HTTP Server, depending on your requirements. Table 1-1 describes the major implementations, or "topologies".

Table 1-1 Oracle HTTP Server Topologies

Topology Description For More Information

Standard Installation Topology for Oracle HTTP Server in a WebLogic Server Domain

This topology provides enhanced management capabilities through the Fusion Middleware Control and WebLogic Management Framework. A WebLogic Server domain can be scaled out to multiple physical machines and be centrally managed by the administration server. This topology is depicted in Figure 1-1.

See "Standard Installation Topology for Oracle HTTP Server in a WebLogic Server Domain" in Installing and Configuring Oracle HTTP Server.

Standard Installation Topology for Oracle HTTP Server in a Standalone Domain

This topology is similar to an Oracle WebLogic Server Domain topology, but does not provide an administration server or managed servers. It is useful when you do not want your Oracle HTTP Server implementation to front a Fusion Middleware domain and do not need the management functionality provided by Fusion Middleware Control. This topology is depicted in Figure 1-2.

See "Standard Installation Topology for Oracle HTTP Server in a Standalone Domain" in Installing and Configuring Oracle HTTP Server.

High availability implementation, with two separate hosts for Oracle HTTP Server on a Web Tier, managed by FMW Control

This topology provides a highly available Oracle Fusion Middleware deployment where each pair of components (Oracle HTTP Server and Web Logic Managed Servers) exist on different host computers. You access the system from the client tier and requests are routed, by using a load balancer, to Web servers running Oracle HTTP Servers in the web tier. This topology is depicted in Figure 1-1.

See "Understanding the Oracle Fusion Middleware Standard HA Topology" in the High Availability Guide.

Managed Oracle HTTP Server Test Domain

This topology provides a single machine WebLogic Server Domain with an Oracle HTTP Server instance and is geared toward testing. It provides all the administrative capabilities of a full production domain but does not require an external database. The test domain cannot be scaled out to other machines and is not certified to be used in production.

See "createOHSTestDomain()" in the WLST Command Reference for Infrastructure Components.

Figure 1-1 Standard Installation Topology for OHS in a WebLogic Server Domain

Description of Figure 1-1 follows
Description of ''Figure 1-1 Standard Installation Topology for OHS in a WebLogic Server Domain''

Figure 1-2 Standard Installation Topology for OHS in a Standalone Domain

Description of Figure 1-2 follows
Description of ''Figure 1-2 Standard Installation Topology for OHS in a Standalone Domain''

1.3 Key Features of Oracle HTTP Server

The following sections describe some of the key features of Oracle HTTP Server:

1.3.1 Oracle WebLogic Server Proxy Plug-In (mod_wl_ohs)

The Oracle WebLogic Server Proxy Plug-In (mod_wl_ohs) enables requests to be proxied from Oracle HTTP Server 12c (12.1.3) to Oracle WebLogic Server. This plug-in enhances an Oracle HTTP server installation by allowing Oracle WebLogic Server to handle requests that require dynamic functionality. In other words, you typically use a plug-in where the HTTP server serves static pages such as HTML pages, while Oracle WebLogic Server serves dynamic pages such as HTTP Servlets and Java Server Pages (JSPs).

For more information on the Oracle WebLogic Server Proxy Plug-In, see "Configuring the Plug-In for Oracle HTTP Server" in Using Oracle WebLogic Server Proxy Plug-Ins 12.1.3

1.3.2 mod_plsql

mod_plsql connects Oracle HTTP Server to an Oracle database, enabling you to create Web applications by using Oracle stored procedures. For more information on mod_plsql, see Section 2.8, "mod_plsql".

1.3.3 Security Features

Oracle HTTP Server employs many security features. Key among them are: Oracle Secure Sockets Layer (mod_ossl)

mod_ossl, the Oracle Secure Sockets Layer (SSL) implementation in use with the Oracle database, enables strong cryptography for Oracle HTTP Server. It is a plug-in to Oracle HTTP Server that enables the server to use SSL and is very similar to the OpenSSL module, mod_ssl. mod_ossl supports TLS version 1.1 and 1.2.. Security: Encryption with Secure Sockets Layer

Secure Sockets Layer (SSL) is required to run any website securely. Oracle HTTP Server supports SSL encryption based on patented, industry standard, algorithms. SSL works seamlessly with commonly-supported Internet browsers. Security features include the following:

  • SSL hardware acceleration support uses dedicated hardware for SSL. Hardware encryption is faster than software encryption.

  • Variable security per directory allows individual directories to be protected by different strength encryption.

  • Oracle HTTP Server and Oracle WebLogic Server communicate using the HTTP protocol to provide both encryption and authentication. You can also enable HTTP tunneling for the T3 or IIOP protocols to provide non-browser clients access to WebLogic Server services. Security: Single Sign-On with WebGate

WebGate enables single sign-on (SSO) for Oracle HTTP Server. WebGate examines incoming requests and determines whether the requested resource is protected, and if so, retrieves the session information for the user. Through WebGate, Oracle HTTP Server becomes an SSO partner application enabled to use SSO to authenticate users, obtain their identity by using Oracle Single Sign-On, and to make user identities available to web applications accessed through Oracle HTTP Server.

1.3.4 URL Rewriting and Proxy Server Capabilities

Active websites usually update their web pages and directory contents often, and possibly their URLs as well. Oracle HTTP Server makes it easy to accommodate the changes by including an engine that supports URL rewriting so end users do not have to change their bookmarks.

Oracle HTTP Server also supports reverse proxy capabilities, making it easier to make content served by different servers to appear from one single server.

1.3.5 CGI and FastCGI

CGI programs are commonly used to program Web applications. Oracle HTTP Server enhances the programs by providing a mechanism to keep them active beyond the request lifecycle.

1.4 Domain Types

You can install Oracle HTTP Server either collocated with Oracle WebLogic Server, called a WebLogic Server Domain or as a standalone domain. You can select which environment you want to use during server configuration. Be aware that certain functionality will not be available to standalone domains.

1.4.1 WebLogic Server Domain

A WebLogic Server Domain is one configured with an administration server and managed servers. A WebLogic Server Domain contains a WebLogic Administration Server, zero or more WebLogic Managed Servers, and zero or more System Component Instances (for example, an Oracle HTTP Server instance). This type of domain provides enhanced management capabilities through the Fusion Middleware Control and WebLogic Management Framework present throughout the system. A WebLogic Server Domain can span multiple physical machines, and it is centrally managed by the administration server. Because of these properties, a WebLogic Server Domain provides the best integration between your System Components and Java EE Components.

WebLogic Server Domains support all WebLogic Management Framework tools.

Because Fusion Middleware Control provides advanced management capabilities, Oracle recommends using WebLogic Server Domain, which requires installing a complete Fusion Middleware infrastructure before you install Oracle HTTP Server.

1.4.2 Standalone Domain

A standalone domain is a container for system components, such as Oracle HTTP Server. It has a directory structure similar to an Oracle WebLogic Server Domain, but it does not contain an Administration Server or Managed Servers. It can contain one or more instances of system components of the same type, such as Oracle HTTP Server, or a mix of system component types.

For standalone domains, the WebLogic Management Framework supports these tools:

  • Node Manager

  • The WebLogic Scripting Tool (WLST) commands, including:

    • nmStart(), nmStop(), nmSoftRestart(), and nmKill() that start and stop Oracle HTTP Server instance

    • nmConnect() to connect to the node manager

    • nmLog() to get the node manager log information

    For a complete list of supported WLST Node Manager commands, see "Node Manager Commands" in "WLST Command Reference for WebLogic Server".


    If you have a remote Oracle HTTP Server in a managed mode and another in standalone with the remote administration mode enabled, you can use WLST to perform management tasks such as SSL configuration. A vanilla Oracle HTTP Server in a standalone domain can be used only as a WebLogic Server Node Manager and for Oracle HTTP Server start/stop purposes. You can also do this by using a command-line script.
  • Config Wizard

  • Pack/Unpack

Generally, you would use a standalone domain when you do not want your Oracle HTTP Server implementation installed with a WebLogic Server domain and do not need the management functionality provided by Fusion Middleware Control. Nor would you use it when you want to keep Oracle HTTP Server in a "demilitarized zone" (DMZ; that is, the zone between the internal and external firewalls) and you do not want to open management ports used by Node Manager.

1.5 Understanding Oracle HTTP Server Directory Structure

As described in Section 1.4, "Domain Types", Oracle HTTP Server domains can be either WebLogic Server or standalone. When installed, each domain has its own directory structure that contains files necessary to implement the domain type. For a complete file structure topology, see Appendix A "Understanding the Oracle HTTP Server Directory Structures" in Installing and Configuring Oracle HTTP Server.

1.6 Understanding Configuration Files

The Oracle HTTP Server configuration is specified through configuration files of several types, notably .conf files, similar to those used in Apache HTTP Server. This section explains the layout of the configuration file directories, mechanisms for editing the files, and more about the files themselves.

This section contains the following topics:

1.6.1 Staging and Run-time Configuration Directories

Two configuration directories exist for each Oracle HTTP Server instance:

  • Staging directory


  • Run-time directory


Each of the configuration directories will contain the complete OHS configuration -- httpd.conf, admin.conf, auditconfig.xml, and so on.

Modifications to the configuration are made in the staging directory. These modifications are automatically propagated to the run-time directory during the following operations:


Before making any changes to files in the staging directory, stop the Administration Server.
  • Oracle HTTP Server instances which are part of a WebLogic Server Domain

    Modifications are replicated to the run-time directory on the node with the managed OHS instance after changes are activated from within Fusion Middleware Control, or when the administration server initializes and prior changes need to be replicated. If communication with node manager is broken at the time of the action, replication will occur at a later time when communication has been restored.

  • Standalone Oracle HTTP Server instances

    Modifications are synchronized with the run-time directory when a start, restart, or stop action is initiated. Some changes might be written to the run-time directory during domain update, but the changes will be finalized during synchronization.

Any modifications to the configuration within the run-time directory will be lost during replication or synchronization.


When a standalone instance is created, the keystores directory containing a demo wallet is created only in the run-time directory.

Before creating the first new wallet for the instance, you must create a keystores directory within the staging directory.


Wallets must then be created within that keystores directory.

1.6.2 Configuration Files

The default Oracle HTTP Server configuration contains the files described in Appendix D, "Configuration Files".

Additional files can be added to the configuration and included in the top-level .conf file httpd.conf using the Include directive. For information on how to use this directive, see the Include directive documentation, at:


The default configuration provides an Include directive which includes all .conf files in the moduleconf/ directory within the configuration.

An Include directive should be added to an existing .conf file, usually httpd.conf, for .conf files which are not stored in the moduleconf/ directory. This may be required if the new .conf file must be included at a different configuration scope, such as within an existing virtual host definition.

1.6.3 Modifying a Configuration File


Fusion Middleware Control and other Oracle software that manage the Oracle HTTP Server configuration might save these files in a different, equivalent format. After using the software to make a configuration change, multiple configuration files might be rewritten.

For instances that are part of a WebLogic Server Domain, Fusion Middleware Control and the management infrastructure manages the Oracle HTTP Server configuration. Direct editing of the configuration in the staging directory is subject to being overwritten after subsequent management operations, including modifying the configuration in Fusion Middleware Control. For such instances, direct editing should only be performed when the administration server is stopped. When the administration server is subsequently started (and with started), the results of any manual edits will be replicated to the run-time directory on the node of the managed instance.

For standalone instances, the configuration can be edited directly within the staging directory at any time. The configuration will be activated during start, restart, or stop. As with a WebLogic domain, whenever you modify a file that resides in the staging directory, you must first stop the administration server.

To modify an Oracle HTTP Server configuration file by using Fusion Middleware Control, do the following:

  1. Select Administration from the HTTP Server menu.

  2. Select Advanced Configuration from the Administration menu item. The Advanced Server Configuration page appears.

  3. Select the configuration file from the list, such as the httpd.conf file.

  4. Edit the file, as needed.

  5. Review the settings. If the settings are correct, click Apply to apply the changes. If the settings are incorrect, or you decide to not apply the changes, click Revert to return to the original settings.

  6. Restart Oracle HTTP Server as described in Section 4.3.4, "Restarting Oracle HTTP Server Instances".

The file is saved and shown on the Advanced Server Configuration page.

1.7 Oracle HTTP Server Support

Oracle provides technical support for the following Oracle HTTP Server features and conditions:

  • Modules included in the Oracle distribution. Oracle does not support modules obtained from any other source, including the Apache Software Foundation. Oracle HTTP Server will still be supported when non-Oracle-provided modules are included. If non-Oracle-provided modules are suspect of contributing to reported problems, customers may be requested to reproduce the problems without including those modules.

  • Problems that can be reproduced within an Oracle HTTP Server configuration consisting only of supported Oracle HTTP Server modules.

  • Use of the included Perl interpreter with the supported Oracle HTTP Server configuration.