This chapter introduces 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:
Oracle HTTP Server 12c (12.2.1) is based on Apache HTTP Server 2.4 infrastructure (with critical bug fixes from higher versions) and includes additional 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:
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.
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.
Note: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 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-Ins 12c (12.2.1) 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."
|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 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-2 illustrates the high-availability implementation, with two separate hosts for Oracle HTTP Server on a Web Tier, managed by FMW Control.
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.
See Also:"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 (12.2.1) 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.2.1
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 Section 5.3.7, "About Configuring mod_proxy_fcgi." For information on migrating from the mod_fastcgi module to mod_proxy_fcgi, see Appendix B, "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:
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 as collocated with Oracle WebLogic Server, called a WebLogic Server Domain, in full or Restricted-JRF mode. The server can also be installed 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.
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 Fusion Middleware infrastructure before you install Oracle HTTP Server.
For more information on installing a WebLogic Server Domain, see Installing and Configuring the Oracle Fusion Middleware Infrastructure.
For information on installing Oracle HTTP Server either as part of a 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 these tools:
The WebLogic Scripting Tool (WLST) commands, including:
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.
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.
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.
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:
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:
Warning: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.
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, 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 Appendix E, "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. For more information, see Section 5.1, "About Editing Configuration Files."
Note: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.
Follow the instructions in Upgrading with the Upgrade Assistant to upgrade Fusion Middleware and Oracle HTTP Server from an earlier release to 12c (12.2.1).
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.
Start the Administration Server (WebLogic) of the upgraded domain, for example
Start the version of WLST that resides in the Middleware Home of your 12c (12.2.1) installation, for example:
Linux or UNIX:
Connect to the Administration Server of the upgraded domain, for example:
> connect('loginID', 'password', '<adminHost>:<adminPort>')
ohs_postUpgrade() WLST custom command, for example:
For more information on the
ohs_postUpgrade WLST custom command, see Section 5.3.4, "Importing Wallets to the KSS Database after an Upgrade Using WLST" and Section A.3.6, "ohs_postUpgrade."
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.