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.2) 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.

Note:

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

1.2 Oracle HTTP Server 12c (12.1.2) 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.2 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. The major implementations, or "topologies," are described in Table 1-1.

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, through 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 key features of Oracle HTTP Server:

1.3.1 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.

See Also:

Securing Applications with Oracle Platform Security Services

1.3.2 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.

See Also:

Securing Applications with Oracle Platform Security Services

1.3.3 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.4 PL/SQL Server Pages

PL/SQL Server Pages are similar in concept to the JavaServer Pages. The mod_plsql module enables PL/SQL to be used as the scripting language within an HTML page. PL/SQL Server Pages get translated into a stored procedure, which then uses the module to send the output to the browser.

1.3.5 Server-Side Includes

Server-Side Includes provide an easy way of adding dynamic or uniform static content across all pages on a site. It is typically used for header and footer information. Oracle HTTP Server supports special directives to enable these only for certain types of files, or for specified virtual hosts.

1.3.6 Perl

Perl is a scripting language often used to provide dynamic content. Perl scripts can either be called as a CGI program, or directly through the mod_perl module. Oracle Fusion Middleware uses Perl version 5.10.

See Also:

Section 2.7, "mod_perl"

1.3.7 Dynamic Scripting Languages

Dynamic Scripting languages, for example Ruby, PHP, Python, which capable of being embedded in HTML, making them well-suited for Web development. Their scripts can be executed within Oracle HTTP Server through the built-in CGI or FastCGI modules.

1.3.8 C / C++ (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.3.9 Load Balancing

Oracle HTTP Server includes the mod_wl_ohs module, which routes requests to Oracle WebLogic Server. The mod_wl_ohs module provides the same load balancing functionality as the Oracle WebLogic Server plug-in for Apache HTTP Server (mod_wl).

See Also:

"The Dynamic Server List" in Using Oracle WebLogic Server Proxy Plug-Ins 12.1.2.

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.

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".

    Note:

    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 to front an Fusion Middleware 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 the 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.

1.6.1 Staging and Run-time Configuration Directories

Two configuration directories exist for each Oracle HTTP Server instance:

  • Staging directory

    DOMAIN_HOME/config/fmwconfig/components/OHS/componentName

  • * Run-time directory

    DOMAIN_HOME/config/fmwconfig/components/OHS/instances/componentName

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

Modifications to the configuration are made in the staging directory. (See Section 1.6.2, "Editing the Configuration") These modifications are automatically propagated to the run-time directory during the following operations:

  • 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.

Note:

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.

DOMAIN_HOME/config/fmwconfig/components/OHS/componentName/keystores

Wallets must then be created within that keystores directory.

1.6.2 Editing the Configuration

For instances that are part of a WebLogic Server Domain, the Oracle HTTP Server configuration is managed by Fusion Middleware Control and the management infrastructure. 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 inactive. When the administration server is subsequently 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.

1.6.3 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:

http://httpd.apache.org/docs/2.2/mod/core.html#include)

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.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 it is suspected that the non-Oracle-provided modules are 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.