8 Managing Oracle HTTP Server Logs

This chapter describes how to manage Oracle HTTP Server logs. It describes how to configure server logs, how to find information about the cause of an error and its corrective action, to view and manage log files to assist in monitoring system activity and to diagnose problems

Oracle HTTP Server generates log files containing messages that record all types of events, including startup and shutdown information, errors, warning messages, access information on HTTP requests, and additional information.

This chapter includes the following sections:

8.1 Overview of Server Logs

You can view Oracle Fusion Middleware log files using either Fusion Middleware Control or a text editor. The log files for Oracle HTTP Server are located in the following directory:

ORACLE_HOME/user_projects/domains/base_domain/servers/componentName/logs

Oracle HTTP Server has two types of logs:

  • Error logs, which record server problems.

  • Access logs, which record which components and applications are being accessed and by whom.

This section contains the following topics:

8.1.1 About Error Logs

Oracle HTTP Server enables you to choose the format in which you want to generate log messages. You can choose to generate log messages in the legacy Apache HTTP Server message format, or use Oracle Diagnostic Logging (ODL) to generate log messages in text or XML-formatted logs, which complies with Oracle standards for generating error log messages.

By default, Oracle HTTP Server error logs use ODL for generating diagnostic messages. It provides a common format for all diagnostic messages and log files, and a mechanism for correlating the diagnostic messages from various components across Oracle Fusion Middleware.

The default name of the error log file is instance_name.log.

8.1.2 About Access Logs

Access logs record all requests processed by the server. The logs contain basic information about every HTTP transaction handled by the server. The access log contains the following information:

  • Host name

  • Remote log name

  • Remote user and time

  • Request

  • Response code

  • Number of transferred bytes

The default name of the access log file is access_log.

Access Log Format

You can specify the information to include in the access log, and the manner in which it is written. The default format is the Common Log Format (CLF).

The CLF format contains the following fields:

host ident authuser date request status bytes

  • host: This is the client domain name or its IP number. Use %h to specify the host field in the log.

  • ident: If IdentityCheck is enabled and the client system runs identd, this is the client identity information. Use %i to specify the client identity field in the log.

  • authuser: This is the user ID for the authorized user. Use %a to specify the authorized user field in the log.

  • date: This is the date and time of the request in the day/month/year:hour:minute:second format. Use %t to specify date and time in the log.

  • request: This is the request line, in double quotes, from the client. Use %r to specify request in the log.

  • status: This is the three-digit status code returned to the client. Use %s to specify the status in the log. If the request will be forwarded from another server, use %>s to specify the last server in the log.

  • bytes: This is the number of bytes, excluding headers, returned to the client. Use %b to specify number of bytes in the log. Use %i to include the header in the log.

See Also:

Access Log in the Apache HTTP Server documentation.

8.1.3 Log Rotation

Oracle HTTP Server supports two types of log rotation policies: size-based and time-based. You can configure the Oracle HTTP Server logs to use either of the two rotation polices, by using odl_rotatelogs in ORACLE_HOME/ohs/bin. By default, Oracle HTTP Server uses odl_rotatelogs for both error and access logs.

odl_rotatelogs supports all the features of Apache HTTP Server's rotatelogs and the additional feature of log retention.

You can find information about the features and options provided by rotatelogs at the following URL:

http://httpd.apache.org/docs/2.2/programs/rotatelogs.html

The following is the general syntax of the odl_rotatelogs:

odl_rotatelogs [-u:offset] logfile {size-|time-based-rotation-options}

odl_rotatelogs is meant to be used with the piped logfile feature. This feature allows error and access log files to be written through a pipe to another process, rather than directly to a file. This increases the flexibility of logging, without adding code to the main server. To write logs to a pipe, replace the filename with the pipe character "|", followed by the name of the executable which should accept log entries on its standard input. For more information on the piped logfile feature, see the following URL:

http://httpd.apache.org/docs/2.2/logs.html#piped

Used with the piped logfile feature, the syntax of the odl_rotatelogs becomes the following:

CustomLog " |${PRODUCT_HOME}/bin/odl_rotatelogs [-u:offset] logfile {size-|time-based-rotation-options}” log_format

Whenever there is an input to odl_rotatelogs, it checks if the specified condition for rotation has been met. If so, it rotates the file. Otherwise it simply writes the content. If no input is provided, then it will do nothing.

Table 8-1 describes the size- and time-based rotation options for odl_rotatelogs:

Table 8-1 Options for odl_rotatelogs

Option Description

-u

The time (in seconds) to offset from UTC.

logfile

The path and name of the log file, followed by a hyphen (-) and then the timestamp format.

The following are the common timestamp format strings:

  • %m: Month as a two-digit decimal number (01-12)

  • %d: Day of month as a two-digit decimal number (01-31)

  • %Y: Year as a four-digit decimal number

  • %H: Hour of the day as a two-digit decimal number (00-23)

  • %M: Minute as a two-digit decimal number (00-59)

  • %S: Second as a two-digit decimal number (00-59)

It should not include formats that expand to include slashes.

frequency

The time (in seconds) between log file rotations.

retentionTime

The maximum time for which the rotated log files are retained.

startTime

The time when time-based rotation should start.

maxFileSize

The maximum size (in MB) of log files.

allFileSize

The total size (in MB) of files retained.

With time-based rotation, log rotation of Oracle HTTP Server using odl_rotatelogs is calculated by default according to UTC time. For example, setting log rotation to 86400 (24 hours) rotates the logs every 12:00 midnight, UTC. If Oracle HTTP Server is running on a server in IST (Indian Standard Time) which is UTC+05:30, then the logs are rotated at 05:30 a.m.

As an alternative to using the -u option with the UTC offset, you can use the -l option provided by Apache. This option causes Oracle HTTP Server to use local time as the base for the interval. Using the-l option in an environment which changes the UTC offset (such as British Standard Time (BST) or Daylight Savings Time (DST)) can lead to unpredictable results.

Syntax and Examples for Time- and Size-Based Rotation

  • Time-based rotation

    Syntax:

    odl_rotatelogs u:offset logfile frequency retentionTime startTime

    Example:

    CustomLog "| odl_rotatelogs u:-18000 /varlog/error.log-%Y-%m-%d 21600 172800 2014-03-10T08:30:00" common

    This configures log rotation to be performed for a location UTC-05:00 (18000 seconds, such as New York). The rotation will be performed every 21600 seconds (6 hours) starting from 8:30 a.m. on March 10, 2014, and it specifies that the rotated log files should be retained for 172800 seconds (2 days). The log format is common.

    Syntax:

    odl_rotatelogs logfile frequency retentionTime startTime

    Example:

    CustomLog "| odl_rotatelogs /varlog/error.log-%Y-%m-%d 21600 172800 2014-03-10T08:30:00" common

    This configures log rotation to be performed every 21600 seconds (6 hours) starting from 8:30 a.m. on March 10, 2014, and it specifies that the rotated log files should be retained for 172800 seconds (2 days). The log format is common.

  • Size-based rotation

    Syntax:

    odl_rotatelogs logfile maxFileSize allFileSize

    Example:

    This configures log rotation to be performed when the size of the log file reaches 10 MB, and it specifies the maximum size of all the rotated log files as 70 MB (up to 7 log files (=70/10) will be retained). The log format is common.

    CustomLog "| odl_rotatelogs /var/log/error.log-%Y-%m-%d 10M 70M" common

8.2 Configuring Oracle HTTP Server Logs

You can use Fusion Middleware Control to configure error and access logs. The following logging tasks can be set from the Log Configuration page:

8.2.1 Using Fusion Middleware Control to Configure Error Logs

To configure an error log for Oracle HTTP Server using Fusion Middleware Control, do the following:

  1. Navigate to the Oracle HTTP Server home page.

  2. Select Log Configuration from the Administration menu.

    The Log Configuration page is displayed, as shown in the following figure.

    Description of log_config_12c.gif follows
    Description of the illustration ''log_config_12c.gif''

  3. The following error log configuration tasks can be set from this page:

8.2.1.1 Configuring the Error Log Format and Location

Oracle HTTP Server by default uses ODL-Text as the error log format and creates the log file with the name component_name.log under the DOMAIN_HOME/servers/component_name/logs directory. To use a different format or log location, do the following:

  1. From the Log Configuration page, navigate to the General section under the Error Log section.

  2. Select the desired file format. Although both ODL-Text and ODL-XML formats provide the same information, the ODL-XML file includes XML elements and wrappers, and so may be easier to read.

    • ODL-Text: the format of the diagnostic messages conform to an Oracle standard and are written in text format.

    • ODL-XML: the format of the diagnostic messages conform to an Oracle standard and are written in XML format.

    • Apache: the format of the diagnostic messages conform to the legacy Apache HTTP Server message format.

  3. Enter a path for the error log in the Log File/Directory field. This directory must exist before you enter it here.

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

  5. Restart Oracle HTTP Server. See Section 4.3.4.

8.2.1.2 Configuring the Error Log Level

You can configure the amount and type of information written to log files by specifying the message type and level. Error log level for Oracle HTTP Server by default is configured to WARNING:32. To use a different error log level do the following:

  1. From the Log Configuration page, navigate to the General section under the Error Log section.

  2. Select a level for the logging from the Level menu. The higher the log level, the more information that is included in the log.

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

  4. Restart Oracle HTTP Server. See Section 4.3.4.

Note:

The log levels are different for the Apache HTTP Server log format from ODL-Text and the ODL-XML log format.

8.2.1.3 Configuring Error Log Rotation Policy

Log rotation policy for error logs can either be time-based, such as once a week, or sized-based, such as 120MB. By default, the error log file is rotated when it reaches 10 MB and a maximum of 7 error log files will be retained. To use a different rotation policy, do the following:

  1. From the Log Configuration page, navigate to the General section under the Error Log section.

  2. Select a rotation policy.

    • No Rotation: if you do not want to have the log file rotated ever.

    • Size Based: rotate the log file whenever it reaches a configured size. Set the maximum size for the log file in Maximum Log File Size (MB) field and the maximum number of error log files to retain in Maximum Files to Retain field.

    • Time Based: rotate the log file whenever configured time is reached. Set the start time, rotation frequency, and retention period.

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

  4. Restart Oracle HTTP Server. See Section 4.3.4.

8.2.2 Configuring Access Logs by Using Fusion Middleware Control

To configure an access log for Oracle HTTP Server using Fusion Middleware Control, do the following:

  1. Navigate to the Oracle HTTP Server home page.

  2. Select Log Configuration from the Administration menu.

The following access log configuration tasks can be set from this page:

8.2.2.1 Configuring the Access Log Format

Log format specifies the information included in the access log file and the manner in which it is written. To add a new access log format or to edit or remove an existing format, do the following:

  1. From the Log Configuration page, navigate to the Access Log section.

  2. Click Manage Log Formats.

    The Manage Custom Access Log Formats page is displayed, as shown in the following figure.

    Description of log_format_12c.gif follows
    Description of the illustration ''log_format_12c.gif''

  3. Select an existing format to change or remove, or click Add Row to create a new format.

  4. If you choose to create a new format, then enter the new log format in the Log Format Name field and the log format in the Log Format Pattern field.

    See Also:

    Refer to the Apache HTTP Server documentation for information about log format directives.

  5. Click OK to save the new format.

8.2.2.2 Configuring the Access Log File

To configure an access log for file Oracle HTTP Server, do the following:

  1. From the Log Configuration page, navigate to the Access Log section.

  2. Click Create to create a new access log, or select a row from the table and click Edit button to edit an existing access log file.

    The Create or Edit Access Log page is displayed.

    Description of log_access.gif follows
    Description of the illustration ''log_access.gif''

  3. Enter the path for the access log in the Log File Path field. This directory must exist before you enter it.

  4. Select an existing access log format from the Log Format menu.

  5. Select a rotation policy.

    • No Rotation: if you do not want to have the log file rotated ever.

    • Size Based: rotate the log file whenever it reaches a configured size. Set the maximum size for the log file in Maximum Log File Size (MB) field and the maximum number of error log files to retain in Maximum Files to Retain field.

    • Time Based: rotate the log file whenever configured time is reached. Set the start time, rotation frequency, and retention period.

  6. Click OK to continue.

    You can create multiple access log files.

8.3 Log Directives for Oracle HTTP Server

This section discuss Oracle HTTP Server error and access log-related directives in the httpd.conf file. The directives discussed are:

8.3.1 Oracle Diagnostic Logging Directives

Oracle HTTP Server by default uses Oracle Diagnostic Logging (ODL) for generating diagnostic messages. The following directives are used to set up logging using ODL:

8.3.1.1 OraLogMode

Enables you to choose the format in which you want to generate log messages. You can choose to generate log messages in the legacy Apache HTTP Server, ODL text, or ODL XML format.

OraLogMode Apache | ODL-Text | ODL-XML

Default value: ODL-Text

For example: OraLogMode ODL-XML

Note:

The Apache HTTP Server log directives ErrorLog and LogLevel are only effective when OraLogMode is set to Apache. When OraLogMode is set to either ODL-Text or ODL-XML, the ErrorLog and LogLevel directives are ignored.

8.3.1.2 OraLogDir

Specifies the path to the directory that contains all log files. This directory must exist.

This directive is used only when OraLogMode is set to either ODL-Text or ODL-XML. When OraLogMode is set to Apache, OraLogDir is ignored and ErrorLog is used instead.

OraLogDir <path>

Default value: ORACLE_INSTANCE/servers/componentName/logs

For example: OraLogDir /tmp/logs

8.3.1.3 OraLogSeverity

Enables you to set message severity. The message severity specified with this directive is interpreted as the lowest desired message severity, and all messages of that severity level and higher are logged.

This directive is used only when OraLogMode is set to either ODL-Text or ODL-XML. When OraLogMode is set to Apache, OraLogSeverity is ignored and LogLevel is used instead.

OraLogSeverity <msg_type>[:msg_level]

Default value: WARNING:32

For example: OraLogSeverity NOTIFICATION:16

msg_type

Message types can be specified in upper or lowercase, but appear in the message output in upper case. This parameter must be of one of the following values:

  • INCIDENT_ERROR

  • ERROR

  • WARNING

  • NOTIFICATION

  • TRACE

msg_level

This parameter must be an integer in the range of 1–32, where 1 is the most severe, and 32 is the least severe. Using level 1 will result in fewer messages than using level 32.

8.3.1.4 OraLogRotationParams

Enables you to choose the rotation policy for an error log file. This directive is used only when OraLogMode is set to either ODL-Text or ODL-XML. When OraLogMode is set to Apache, OraLogRotationParams is ignored.

OraLogRotationParams <rotation_type> <rotation_policy>

Default value: S 10:70

For example: OraLogRotationParams T 43200:604800 2009-05-08T10:53:29

rotation_type

This parameter can either be S (for sized-based rotation) or T (for time-based rotation).

rotation_policy

When rotation_type is set to S (sized-based), set the rotation_policy parameter to:

maxFileSize:allFilesSize (in MB)

For example, when configured as 10:70, the error log file is rotated whenever it reaches 10MB and a total of 70MB is allowed for all error log files (a maximum of 70/10=7 error log files will be retained).

When rotation_type is set to T (time-based), set the rotation_policy parameter to:

frequency(in sec) retentionTime(in sec) startTime(in YYYY-MM-DDThh:mm:ss)

For example, when configured as 43200:604800 2009-05-08T10:53:29, the error log is rotated every 43200 seconds (that is, 12 hours), rotated log files are retained for maximum of 604800 seconds (7 days) starting from May 5, 2009 at 10:53:29.

8.3.2 Apache HTTP Server Log Directives

Although Oracle HTTP Server uses ODL by default for error logs, you can configure the OraLogMode directive to Apache to generate error log messages in the legacy Apache HTTP Server message format. The following directives are discussed in this section:

8.3.2.1 ErrorLog

The ErrorLog directive sets the name of the file where the server logs any errors it encounters. If the filepath is not absolute then it is assumed to be relative to the ServerRoot.

This directive is used only when OraLogMode is set to Apache. When OraLogMode is set to either ODL-Text or ODL-XML, ErrorLog is ignored and OraLogDir is used instead.

See Also:

For information about the Apache ErrorLog directive, see:

http://httpd.apache.org/docs/current/mod/core.html#errorlog

8.3.2.2 LogLevel

The LogLevel directive adjusts the verbosity of the messages recorded in the error logs.

This directive is used only when 3 is set to Apache. When OraLogMode is set to either ODL-Text or ODL-XML, LogLevel is ignored and OraLogSeverity is used instead.

See Also:

For information about the Apache HTTP Server LogLevel directive see:

http://httpd.apache.org/docs/current/mod/core.html#loglevel

8.3.2.3 LogFormat

The LogFormat directive specifies the format of the access log file. By default, Oracle HTTP Server comes with the following four access log formats defined:

LogFormat "%h %l %u %t \"%r\" %>s %b" common
LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined
LogFormat "%{Referer}i -> %U" referer
LogFormat "%{User-agent}i" agent

See Also:

For information about the Apache HTTP Server LogFormat directive, see:

http://httpd.apache.org/docs/current/mod/mod_log_config.html#logformat

8.3.2.4 CustomLog

The CustomLog directive is used to log requests to the server. A log format is specified and the logging can optionally be made conditional on request characteristics using environment variables. By default, the access log file is configured to use the common log format.

See Also:

For information about the Apache CustomLog directive, see:

http://httpd.apache.org/docs/current/mod/mod_log_config.html#customlog

8.4 Viewing Oracle HTTP Server Logs

As discussed in Section 8.1, "Overview of Server Logs", there are mainly two types of log files for Oracle HTTP Server: error logs and access logs. The error log file is an important source of information for maintaining a well-performing server. The error log records all of the information about problem situations so that the system administrator can easily diagnose and fix the problems. The access log file contains basic information about every HTTP transaction that the server handles. This information can be used to generate statistical reports about the server's usage patterns.

The three methods for viewing Oracle HTTP Server logs are:

8.4.1 Viewing Logs In Fusion Middleware Control

For information about searching and viewing log files by using Oracle Fusion MiddlewareFusion Middleware Control, see Administering Oracle Fusion Middleware.

8.4.2 Viewing Logs from the Command Line

To obtain and view server logs from the command line, you need to connect to Node Manager and issue the appropriate WebLogic Scripting Tool (WLST) command. These commands allow you to perform any of these functions:

  • List server logs.

  • Display the content of a specific log.

Note:

For more information on using WLST, see Understanding the WebLogic Scripting Tool.

Before attempting this procedure:

Before attempting to access server metrics from the command line, ensure the following:

  • The domain exists.

  • The instance you want to start exists.

  • Node Manager is running on the instance machine.

To use this procedure, the instance and Administration server can be running but do not need to be.

To view metrics from the command line:

Note:

For managed domains, this procedure will work on an Administration server running on either the Administration machine or on a remote machine, whether the instance is in a running state or a shutdown state. For standalone domains, the procedure will work only on a local machine; however the instance can be either in a running or shutdown state.

  1. Launch WLST:

    From Linux:

    $ORACLE_HOME/ohs/common/bin/wlst.sh

    From Windows:

    C:\\ORACLE_HOME\ohs\common\bin\wlst.cmd

  2. From the selected domain directory (for example, ORACLE_HOME/user_projects/domains/domainName), connect to Node Manager:

    nmConnect('username', 'password', nm_host, nm_port, domainName, domainDir)

  3. Enter one of the following WLST commands, depending on what task you want to accomplish:

    • listLogs(nmConnected=1, ...)

    • displayLogs(nmConnected=1, ...)

    For example:

    listLogs(nmConnected=1, target='ohs1')
displayLogs(nmConnected=1, target='ohs1', tail=5)

8.4.3 Viewing Logs in a Text Editor

You can also use the text editor of your choice to view Oracle HTTP Server log files directly from the DOMAIN_HOME directory. By default, Oracle HTTP Server log files are located in the DOMAIN_HOME/servers/component_name/logs directory. Downloading a log file to your local client and view the log files using another tool.

8.5 Recording ECID Information

This section describes how to configure Oracle HTTP Server to record Execution Context ID (ECID) information in error logs and access logs.

8.5.1 About ECID Information

An ECID is a globally unique ID that can be attached to requests between Oracle components. The ECID enables you to track log messages pertaining to the same request when multiple requests are processed in parallel.

The Oracle HTTP Server module mod_context scans each incoming request for an ECID-Context key in the URI or cookie, or for the ECID-Context header. If found, then the value is used as the execution context if it is valid. If it is not, then mod_context creates a new execution context for the request and adds it as the value of the ECID-Context header.

8.5.2 Configuring Error Logs for ECID Information

ECID information is recorded as part of Oracle Diagnostic Logging (ODL). ODL is a method for reporting diagnostic messages which presents a common format for diagnostic messages and log files, and a method for correlating all diagnostic messages from various components.

To configure Oracle HTTP Server error logs to record ECID information, ensure that the OraLogMode directive in the httpd.conf file is set to the default value, odl. The odl value specifies standard Apache log format and ECID information for log records specifically associated with a request.

For more information on OraLogMode and other possible values for this directive, see Section 8.3.1.1, "OraLogMode."

Note:

Oracle recommends that you enter the directives before any modules are loaded (LoadModule directive) in the httpd.conf file so that module-specific logging severities are in effect before modules have the opportunity to perform any logging.

8.5.3 Configuring Access Logs for ECID Information

To configure Oracle HTTP Server access logs to record ECID information, you must manually edit the Oracle HTTP Server access log to include the following string:

LogFormat "%h %l %u %t \"%r\" %>s %b \"%{X-ORACLE-DMS-ECID}o\" %D"

This directive will direct the access log to capture the ECID information along with the response time measured in microseconds.

8.6 Terminating SSL Requests

This section describes how to terminate SSL before or within Oracle HTTP Server, where the mod_wl_ohs module is used to forward requests to WebLogic Server. Whether you terminate SSL before the request reaches Oracle HTTP Server or when the request is in the server, depends on your topology. A common reason to terminate SSL is for performance considerations when an internal network is otherwise protected with no risk of a third-party intercepting data within the communication. Another reason is when WebLogic Server is not configured to accept HTTPS requests.

8.6.1 Terminating SSL Before Oracle HTTP Server

If you are using another device such as a load balancer or a reverse proxy which terminates requests using SSL before reaching Oracle HTTP Server, then you must configure the server to treat the requests as if they were received through HTTPS. The server must also be configured to send HTTPS responses back to the client.

Figure 8-1 illustrates an example where the request transmitted from the browser through HTTPS to WebLogic Server. The load balancer terminates SSL and transmits the request as HTTP. Oracle HTTP Server must be configured to treat the request as if it was received through HTTPS.

Figure 8-1 Terminating SSL Before Oracle HTTP Server

Description of Figure 8-1 follows
Description of ''Figure 8-1 Terminating SSL Before Oracle HTTP Server''

To instruct the Oracle HTTP Server to treat requests as if they were received through HTTPS, configure the httpd.conf file with the SimulateHttps directive in the mod_certheaders module.

For more information on mod_certheaders module, see Section F.2, "mod_certheaders Module."

Note:

This procedure is not necessary if SSL is configured on Oracle HTTP Server (that is, if you are directly accessing Oracle HTTP Server using HTTPS).

  1. Configure the httpd.conf configuration file with the external name of the server and its port number, for example:

    ServerName <www.company.com:port>

  2. Configure the httpd.conf configuration file to load the mod_certheaders module, for example:

    • On UNIX:

      LoadModule certheaders_module libexec/mod_certheaders.so

    • On Windows:

      LoadModule certheaders_module modules/ApacheModuleCertHeaders.dll
AddModule mod_certheaders.c

      Note:

      Oracle recommends that the AddModule line should be included with other AddModule directives.

  3. Configure the SimulateHttps directive at the bottom of the httpd.conf file to send HTTPS responses back to the client, for example:

    # For use with other load balancers and front-end devices:
SimulateHttps On

  4. Restart Oracle HTTP Server and test access to the server. Especially, test whether you can access static pages such as https://host:port/index.html

    Test your configuration as a basic setup. If you are having issues, then you should troubleshoot from here to avoid overlapping with other potential issues, such as with virtual hosting.

  5. Ideally, you may want to configure a VirtualHost in the httpd.conf file to handle all HTTPS requests. This separates the HTTPS requests from the HTTP requests as a more scalable approach. This may be more desirable in a multi-purpose site or if a load balancer or other device is in front of Oracle HTTP Server which is also handling both HTTP and HTTPS requests.

    The following sample instructions load the mod_certheaders module, then creates a virtual host to handle only HTTPS requests.

    # Load correct module here or where other LoadModule lines exist:
LoadModule certheaders_module libexec/mod_certheaders.so
# This only handles https requests:
NameVirtualHost <name>:<port>
   <VirtualHost <name>:<port>
       # Use name and port used in url:
       ServerName <www.company.com:port>
       SimulateHttps On
       # The rest of your desired configuration for this VirtualHost goes here
   </VirtualHost>

  6. Restart Oracle HTTP Server and test access to the server, First test a static page such as https://host:port/index.html and then your test your application.

8.6.2 Terminating SSL at Oracle HTTP Server

If SSL is configured in Oracle HTTP Server but not on WebLogic Server, then you can terminate SSL for requests sent by Oracle HTTP Server.

The following figures illustrate request flows, showing where HTTPS stops. In Figure 8-2, an HTTPS request is sent from the browser. The load balancer transmits the HTTPS request to Oracle HTTP Server. SSL is terminated in Oracle HTTP Server and the HTTP request is sent to WebLogic Server.

Figure 8-2 Terminating SSL at Oracle HTTP Server—With Load Balancer

Description of Figure 8-2 follows
Description of ''Figure 8-2 Terminating SSL at Oracle HTTP Server—With Load Balancer''

In Figure 8-3, there is no load balancer and the HTTPS request is sent directly to Oracle HTTP Server. Again, SSL is terminated in Oracle HTTP Server and the HTTP request is sent to WebLogic Server.

Figure 8-3 Terminating SSL at Oracle HTTP Server—Without Load Balancer

Description of Figure 8-3 follows
Description of ''Figure 8-3 Terminating SSL at Oracle HTTP Server—Without Load Balancer''

  1. Configure the mod_wl_ohs.conf file to add the WLSProxySSL directive for the location of your non-SSL configured managed servers, for example:

    WLProxySSL ON

  2. If using a load balancer or other device in front of Oracle HTTP Server (which is also using SSL), you might need to configure the WLProxySSLPassThrough directive instead, depending on if it already sets WL-Proxy-SSL, for example:

    WLProxySSLPassThrough ON

    For more information, see your load balancer documentation. For more information on WLProxySSLPassThrough, see "Parameters for Web Server Plug-Ins" in Using Oracle WebLogic Server Proxy Plug-Ins 12.1.3.

  3. Ensure that the SecureProxy directive is not configured, as it will interfere with the intended communication between the components. This directive is to be used only when SSL is used throughout. The SecureProxy directive is commented out in the following example:

    # To configure SSL throughout (all the way to WLS):
# SecureProxy ON
# WLSSLWallet  "<Path to Wallet>"

  4. Restart Oracle HTTP Server and test access to a Java application, for example: https://host:port/path/application_name.