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.

Note:

ODL error logging cannot have separate log files for each virtual host. It can only be configured globally for all virtual hosts.

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

LogFormat "%h %l %u %t %E \"%r\" %>s %b" common

The CLF format contains the following fields:

host ident remote_logname remote_usre date  ECID request authuser 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.

  • remote_logname: Remote log name (from identd, if supplied). Use %l to specify the remote log name in the log.

  • remote_user: Remote user if the request was authenticated. Use %u to specify the remote user 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.

  • ECID: Capture ECID information. Use %E to capture ECID in the log. See also Section 8.6.3, "Configuring Access Logs for ECID Information."

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

  • authuser: This is the user ID for the authorized user. Use %a to specify the authorized user field 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 Configuring 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.4/programs/rotatelogs.html

The following is the general syntax of 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.4/logs.html#piped

Used with the piped logfile feature, the syntax of 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:

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

8.1.3.1 Syntax and Examples for Time- and Size-Based Log Rotation

The following examples demonstrate the odl_rotatelogs syntax to set time- and size-based log 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 sections describe logging tasks that can be set from the Log Configuration page:

8.2.1 Configuring Error Logs Using Fusion Middleware Control

You configure error logs on the Fusion Middleware Control Log Configuration page. 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.png follows
    Description of the illustration ''log_config_12c.png''

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

8.2.1.1 Configuring the Error Log Format and Location

You can change the error log format and location on the Fusion Middleware Control Log Configuration page. By default, Oracle HTTP Server 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.

    • ODL-Text: the format of the diagnostic messages conform to an Oracle standard and are written in text 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.5.

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

Note:

The log levels are different for the Apache HTTP Server log format and ODL-Text 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.5.

8.2.2 Configuring Access Logs Using Fusion Middleware Control

You can configure an access log format and rotation policy for Oracle HTTP Server from the Fusion Middleware Control Log Configuration page.

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. Navigate to the Oracle HTTP Server home page.

  2. Select Log Configuration from the Administration menu.

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

  4. Click Manage Log Formats.

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

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

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

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

  7. Click OK to save the new format.

8.2.2.2 Configuring the Access Log File

You can configure rotation policy for the access log on the Fusion Middleware Control Create or Edit Access Log page. To configure an access log for file Oracle HTTP Server, do the following:

  1. Navigate to the Oracle HTTP Server home page.

  2. Select Log Configuration from the Administration menu.

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

  4. 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_create.png follows
    Description of the illustration ''log_access_create.png''

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

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

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

  8. Click OK to continue.

    You can create multiple access log files.

8.2.3 Configuring the Log File Creation Mode (umask) (UNIX/Linux Only)

Set the value of default file mode creation mask (umask) before starting the Oracle HTTP Server instance. The value that you set for umask determines the file permissions for the files created by Oracle HTTP Server instance such as the error log, access log, and so on. If umask is not set explicitly, then a value of 0027 is used by default.

This section contains the following information:

8.2.3.1 Configure umask for an Oracle HTTP Server Instance in a Standalone Domain

To configure the default file mode creation mask in a standalone domain, set the umask property in the ohs.plugins.nodemanager.properties file under the staging location:

DOMAIN_HOME/config/fmwconfig/components/OHS/instanceName/ohs.plugins.nodemanager.properties

8.2.3.2 Configure umask for an Oracle HTTP Server Instance in a WebLogic Server Managed Domain

To configure the default file mode creation mask in a WebLogic Server (either Full-JRF or Restricted-JRF) domain, follow these steps:

  1. Start the AdminServer and NodeManager for the domain, for example:

    <Domain_HOME>/bin/startWebLogic.sh &
<DOMAIN_HOME>/bin/startNodeManager.sh &

  2. Start WLST and connect to the AdminServer.

    <ORACLE_HOME>/oracle_common/bin/wlst.sh
connect('<userName', <'password'>, <'adminServerURL'>

  3. Navigate to the following MBean. Note that the ObjectName for this MBean is dependent on the name of Oracle HTTP Server instance. In this example, the name of Oracle HTTP Server instance is ohs1

    editCustom()
cd('oracle.ohs')
cd('oracle.ohs:OHSInstance=ohs1,component=OHS,type=OHSInstance.NMProp')

  4. Set the value of umask to the desired value.

    startEdit()
set('Umask','0022')

  5. Save and activate the changes.

    save()
activate()

8.3 Configuring the Log Level Using WLST

You can use WLST commands to set the LogLevel directive, which controls the verbosity of the error log.

Note:

For more information on the LogLevel directive, see the Apache documentation: http://httpd.apache.org/docs/current/mod/core.html#loglevel

Follow these steps to set the LogLevel directive using WLST commands.

  1. Launch WLST.

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

  2. Connect to Administration Server.

    connect('<user-name>', '<password>','<host>:<port>')

  3. Use the editCustom() command to navigate to the root of the oracle.ohs MBean. You can use the editCustom() command only when WLST is connected to the Administration Server. Use cd to navigate the hierarchy of management objects, in this case, ohs1 under oracle.ohs. Use the startEdit() command to start an edit session.

    editCustom()
cd('oracle.ohs')
cd('oracle.ohs:type=OHSInstance,name=ohs1')
startEdit()

  4. Use the set command to set the value of the log level attribute. The following example sets the global log level to trace7, the module status log level to error, and the module env log level to warn (warning).

    set('LogLevel','trace7 status:error env:warn')

  5. Save, then activate your changes. The edit lock associated with this edit session is released once the activation is completed.

    save()
activate()

8.4 Log Directives for Oracle HTTP Server

The following sections describe Oracle HTTP Server error and access log-related directives in the httpd.conf file.

8.4.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.4.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 or ODL text format.

OraLogMode Apache | ODL-Text

Default value: ODL-Text

For example: OraLogMode ODL-Text

Note:

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

8.4.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 ODL-Text. 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.4.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 ODL-Text. When OraLogMode is set to Apache, OraLogSeverity is ignored and LogLevel is used instead. In the following syntax, short_module_identifierName is the module name with the trailing _module omitted.

OraLogSeverity [short_module_identifierName] <msg_type>[:msg_level]

Default value: WARNING:32

For example: OraLogSeverity mime NOTIFICATION:32

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.4.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 ODL-Text. 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.4.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.4.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 ODL-Text, 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.4.2.2 LogLevel

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

This directive is used only when OraLogMode is set to Apache. When OraLogMode is set to ODL-Text, 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.4.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 %E \"%r\" %>s %b" commonLogFormat "%h %l %u %t %E \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combinedLogFormat "%h %l %u %t %E \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\" %I %O" combinedio

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.4.2.4 CustomLog

Use the CustomLog directive 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.5 Viewing Oracle HTTP 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. You can use this information to generate statistical reports about the server's usage patterns.

See Section 8.1, "Overview of Server Logs" for more information on error logs and access logs.

The methods for viewing Oracle HTTP Server logs are:

8.5.1 Viewing Logs Using Fusion Middleware Control

To access the log messages for an Oracle HTTP Server instance:

  1. Navigate to the Oracle HTTP Server home page.

  2. Select the server instance for which you want to view log messages.

  3. From the Oracle HTTP Server drop-down list, select Logs, then View Log Messages.

    The Log Messages page opens.

For information about searching and viewing log files, see "Viewing Log Files and Their Messages Using Fusion Middleware Control" in Administering Oracle Fusion Middleware.

8.5.2 Viewing Logs Using WLST

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 using WLST:

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 or UNIX:

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

    From Windows:

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

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

    nmConnect('username', 'pwd', localhost, 5556, domainName)

  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.5.3 Viewing Logs in a Text Editor

You can also use a text editor 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. Download a log file to your local client and view the log files using another tool.

8.6 Recording ECID Information

The following sections describe how to configure Oracle HTTP Server to record Execution Context ID (ECID) information in error logs and access logs.

8.6.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.6.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.4.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.6.3 Configuring Access Logs for ECID Information

By default, the LogFormat directive in the httpd.conf file is configured to capture ECID information:

LogFormat "%h %l %u %t %E \"%r\" %>s %b" common

If you want to add response time measured in microseconds, then add %D as follows:

LogFormat "%h %l %u %t %E %D \"%r\" %>s %b" common

If you want to suppress the capture of ECID information, then remove %E from the LogFormat directive:

LogFormat "%h %l %u %t \"%r\" %>s %b" common

8.7 Terminating SSL Requests

The following sections describe how to terminate requests using SSL before or within Oracle HTTP Server, where the mod_wl_ohs module forwards 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.7.1 About Terminating SSL at the Load Balancer

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''

8.7.1.1 Terminating SSL at the Load Balancer

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 2.1.1, "mod_certheaders Module—Enables Reverse Proxies."

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:
   <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.7.2 About Terminating SSL at Oracle HTTP Server

If SSL is configured in Oracle HTTP Server but not on Oracle 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''

8.7.2.1 Terminating SSL at Oracle HTTP Server

To instruct the Oracle HTTP Server to treat requests as if they were received through HTTPS, configure the WLSProxySSL directive in the mod_wl_ohs.conf file and ensure that the SecureProxy directive is not configured.

  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 Oracle WebLogic Server Proxy Plug-Ins" in Using Oracle WebLogic Server Proxy Plug-Ins 12.2.1.

  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.