Oracle HTTP Server is the web server component for Oracle Fusion Middleware, and provides a listener for Oracle WebLogic Server and the framework for hosting static pages, dynamic pages, and applications over the web.
This chapter introduces the Oracle HTTP Server (OHS). It describes key features of Oracle HTTP Server, and its place within the Oracle Fusion Middleware Web Tier and also provides information about the Oracle HTTP Server directory structure, the Oracle HTTP Server configuration files, and how to obtain Oracle HTTP Server support.
This chapter includes the following sections:
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, which allows Oracle HTTP Server to be set up as a reverse proxy through the fcgi protocol to a persistent Perl runtime environment using mod_proxy_fcgi.
Although Oracle HTTP Server contains a Perl interpreter, it is internal to the product. You cannot use this interpreter for hosting Perl under a FastCGI environment. You must provide your own Perl environment.
Oracle WebLogic Server Proxy Plug-In, which enables Oracle HTTP Server to front-end WebLogic Servers and other Fusion Middleware-based applications.
Oracle HTTP Server enables developers to program their site in a variety of languages and technologies, such as:
Perl (through mod_proxy_fcgi, CGI and FastCGI)
C and C++ (through mod_proxy_fcgi, CGI and FastCGI)
Java, Ruby and Python (through mod_proxy_fcgi, CGI and FastCGI)
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.
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 other Fusion Middleware components. 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-Ins to route dynamic content requests to Managed Server instances.
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 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-1.
To obtain this topology, install Oracle HTTP Server in standalone mode. Can be paired with Oracle HTTP Server Collocated mode by using the Pack or UnPack commands.
See Standard Installation Topology for Oracle HTTP Server in a Standalone Domain in Installing and Configuring Oracle HTTP Server.
Standard Installation Topology for Oracle HTTP Server in a WebLogic Server Domain (Restricted-JRF)
This topology is similar to the Full-JRF (Java Required Files) topology, except that it does not require a backing database. The Restricted-JRF mode offers all of the functionality as the Full-JRF mode, except cross component wiring is not available.
To obtain this topology, install Oracle HTTP Server in Collocated mode, then choose the Oracle HTTP Server Restricted-JRF domain template for provisioning this domain. This topology handles most use cases except for cross-component wiring.
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 WebLogic Server Domain (Full-JRF)
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-2.
To obtain this topology, install Oracle HTTP Server in Collocated mode, then choose the Oracle HTTP Server Full-JRF domain template. Note that this topology, requires a database in back-end and can support cross-component wiring.
See Standard Installation Topology for Oracle HTTP Server in a WebLogic Server Domain in Installing and Configuring Oracle HTTP Server.
Figure 1-1 illustrates the standard Installation Topology for Oracle HTTP Server in a Standalone Domain.
Figure 1-1 Standard Installation Topology for Oracle HTTP Server in a Standalone Domain
Figure 1-2 illustrates the high-availability implementation, with two separate hosts for Oracle HTTP Server on a Web Tier, managed by FMW Control.
Figure 1-2 Standard Installation Topology for Oracle HTTP Server in a WebLogic Server Domain
Oracle HTTP Server includes a web server proxy plug-in for Oracle WebLogic Server, components for boosting web application performance, an installation mode that does not require a database connection, multiple security configuration options, and more.
The following sections describe some key features of Oracle HTTP Server:
Oracle HTTP Server12c (12.2.1) introduces the Restricted-JRF mode. If you choose to install Oracle HTTP Server in a Oracle WebLogic Server domain in this mode, then a connection to an external database is not required. All of the Oracle HTTP Server functionality through Fusion MiddleWare Control and WLST described in this documentation is still available, with the exception of cross component wiring.
Lack of support for cross component wiring means that:
There are changes to the Fusion MiddleWare Control menu options: some of the menu options which support cross component wiring are removed or disabled.
Any database dependencies are completely removed.
Wiring Components to Work Together in Administering Oracle Fusion Middleware.
The management of keys and certificates for an Oracle HTTP Server instance in a Restricted-JRF domain continue to be keystore services (KSS). In a Restricted-JRF domain, the database persistency of KSS is replaced with file persistency. To an end user, there are no visible change in basic KSS APIs to manage keys or certificates.
Oracle HTTP Server continues to support multiple Oracle wallets for complex virtual server configurations both in Restricted-JRF and full JRF mode.
The Oracle WebLogic Server Proxy Plug-In (mod_wl_ohs) enables requests to be proxied from Oracle HTTP Server12c 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 the J2EE dynamic pages such as Servlets, Java Server Pages (JSPs), and Enterprise Java Bean (EJB).
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 by using the mod_proxy_fcgi module.
The mod_proxy_fcgi module is the Oracle replacement for the deprecated mod_fastcgi module. The mod_proxy_fcgi module requires the service of the mod_proxy module and provides support for the FastCGI protocol.
For information on configuring the mod_proxy_fcgi module, see About Configuring mod_proxy_fcgi. For information on migrating from the mod_fastcgi module to mod_proxy_fcgi, see Migrating to the mod_proxy_fcgi and mod_authnz_fcgi Modules.
Oracle HTTP Server employs many security features. Key among them are:
The mod_ossl module, the Oracle Secure Sockets Layer (SSL) implementation used in 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. The mod_ossl module supports TLS version 1.0, 1.1 and 1.2.
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.
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.
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.
You can install Oracle HTTP Server on two types of domains: WebLogic Server domain and standalone domain. In the WebLogic Server domain, Oracle HTTP Server can be collocated with Oracle WebLogic Server in full or Restricted-JRF mode. Standalone domain has restricted functionality.
You can select which environment you want to use during server configuration.
A WebLogic Server Domain in Full-JRF mode 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 Oracle Fusion Middleware infrastructure before you install Oracle HTTP Server.
For more information about installing a WebLogic Server Domain, see Installing and Configuring the Oracle Fusion Middleware Infrastructure.
For information about installing Oracle HTTP Server either as part of a Oracle Fusion Middleware infrastructure or as standalone component, see Installing and Configuring Oracle HTTP Server.
The Weblogic Server Domain in Restricted-JRF mode is similar in architecture and functionality to Weblogic Server Domain in Full mode, except it does not define a connection to an external database. There are no database dependencies in Restricted-JRF mode.
This lack of a backing database means that cross component wiring is not supported by Oracle HTTP Server in a Restricted-JRF domain; this is the major differentiating factor between a Full JRF- and a Restricted-JRF-based domain.
Like the Full -JRF domain, the management of keys and certificates of an Oracle HTTP Server instance in a Restricted-JRF domain continues to be keystore service (KSS). In a Restricted-JRF domain, the database persistency of KSS is replaced with file persistency, although to an end user there is no visible change in basic KSS APIs to manage keys and certificates.
Like the Full -JRF domain, Oracle HTTP Server in a Restricted-JRF domain supports multiple Oracle wallets for complex virtual server configurations.
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 the following tools:
The WebLogic Scripting Tool (WLST) commands, including:
nmStop() that start and stop Oracle HTTP Server instance.
nmConnect() to connect to 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 or stop purposes. You can also do this by using a command-line script.
Pack or 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 Oracle 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.
When Oracle HTTP Server is installed in a domain, a directory tree is created that contains the files that are required by Oracle HTTP server to support that domain type.
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 Understanding the Directory Structures in Installing and Configuring Oracle HTTP Server.
Oracle HTTP Server contains several configuration files that are similar to those used in Apache HTTP Server. Most of these files end with the
.conf file type.
The following topics explain the layout of the configuration file directories, mechanisms for editing the files, and more about the files themselves.
Two configuration directories are associated with each Oracle HTTP Server instance: a staging directory and a run-time directory.
Each of the configuration directories contain the complete Oracle HTTP Server 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 manually (that is, without using Fusion Middleware Control or WLST), 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 Oracle HTTP Server 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, the user must create a keystores directory within the staging directory.
Wallets must then be created within that keystores directory.
The default Oracle HTTP Server configuration contains the files described in 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.
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 (with start or restart), the results of any manual edits will be replicated to the run-time directory on the node of the managed instance. See About Editing Configuration Files.
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.
You can use the Upgrade Assistant to upgrade and configure supported Fusion Middleware and Oracle HTTP Server domains from an earlier release to 12c (22.214.171.124.0) and perform a readiness check prior to an upgrade.
To upgrade Oracle HTTP Server, see Upgrading with the Upgrade Assistant.
If you are upgrading a collocated Oracle HTTP Server setup (not a standalone installation), then you must perform the following manual steps after you complete the Upgrade Assistant.
Linux or UNIX:
> connect('loginID', 'password', '<adminHost>:<adminPort>')
ohs_postUpgrade()WLST custom command, for example:
For more information about the
ohs_postUpgrade WLST custom command, see Importing Wallets to the KSS Database after an Upgrade Using WLST and ohs_postUpgrade.
Oracle provides technical support for Oracle HTTP Server features.
The following Oracle HTTP Server features and conditions are supported:
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.