Configuring Web Server Functionality

2 Configuring Web Server Functionality

Learn how to configure a Jakarta EE Web application hosted on Oracle WebLogic Server to function as a standard HTTP Web server hosting static content. Web applications also can host dynamic content such as JSPs and servlets.

See Developing Web Applications, Servlets, and JSPs for Oracle WebLogic Server.

Overview of Configuring Web Server Components
In addition to hosting dynamic Java-based distributed applications, WebLogic Server functions as a Web server that handles high-volume Web sites, serving static files such as HTML files and image files, as well as servlets and JavaServer Pages (JSP).
Configuring the Server
You can specify the port that each WebLogic Server listens on for HTTP requests. Although you can specify any valid port number, if you specify port 80, you can omit the port number from the HTTP request used to access resources over HTTP. For example, if you define port 80 as the listen port, you can use the form http://hostname/myfile.html instead of http://hostname:portnumber/myfile.html.
Web Applications
HTTP and Web applications are deployed according to the Jakarta Servlet 4.0 and JSP 2.3 specifications, which describe Web Applications as a standard for grouping the components of a Web-based application. These components include JSP pages, HTTP servlets, and static resources such as HTML pages or image files. In addition, a Web application can access external resources such as EJBs and JSP tag libraries. Each server can host any number of Web applications. You typically use the name of the Web application as part of the URI you use to request resources from the Web application.
Configuring Virtual Hosting
Virtual hosting allows you to define host names that servers or clusters respond to. When you use virtual hosting, you use DNS to specify one or more host names that map to the IP address of a WebLogic Server instance or cluster, and you specify which Web applications are served by the virtual host. When used in a cluster, load balancing allows the most efficient use of your hardware, even if one of the DNS host names processes more requests than the others.
How WebLogic Server Resolves HTTP Requests
When WebLogic Server receives an HTTP request, it resolves the request by parsing the various parts of the URL and using that information to determine which Web application and/or server should handle the request.
Health Score-Based Intelligent Routing
Health score-based intelligent routing lets you manage system optimization, avoid overload, and deal with unhealthy servers.
Setting Up HTTP Access Logs
WebLogic Server can keep a log of all HTTP transactions in a text file, in either common log format or extended log format.
Preventing POST Denial-of-Service Attacks
A Denial-of-Service attack is a malicious attempt to overload a server with phony requests. One common type of attack is to send huge amounts of data in an HTTP POST method. You can set three attributes in WebLogic Server that help prevent this type of attack. These attributes are set in the Remote Console, under Servers: Protocols: HTTP or Virtual Hosts: HTTP. If you define these attributes for a virtual host, the values set for the virtual host override those set under Servers.
Setting Up WebLogic Server for HTTP Tunneling
HTTP tunneling provides a way to simulate a stateful socket connection between WebLogic Server and a Jakarta client when your only option is to use the HTTP protocol.
Using Native I/O for Serving Static Files (Windows Only)
When running WebLogic Server on Windows NT/2000/XP you can specify that WebLogic Server use the native operating system call TransmitFile instead of using Java methods to serve static files such as HTML files, text files, and image files. Using native I/O can provide performance improvements when serving larger static files.

Overview of Configuring Web Server Components

In addition to hosting dynamic Java-based distributed applications, WebLogic Server functions as a Web server that handles high-volume Web sites, serving static files such as HTML files and image files, as well as servlets and JavaServer Pages (JSP).

WebLogic Server supports the HTTP 1.1 standard.

Parent topic: Configuring Web Server Functionality

Configuring the Server

You can specify the port that each WebLogic Server listens on for HTTP requests. Although you can specify any valid port number, if you specify port 80, you can omit the port number from the HTTP request used to access resources over HTTP. For example, if you define port 80 as the listen port, you can use the form http://hostname/myfile.html instead of http://hostname:portnumber/myfile.html.

On UNIX systems, binding a process to a port lower than 1025 must be done from the account of a privileged user, usually root. Consequently, if you want WebLogic Server to listen on port 80, you must start WebLogic Server as a privileged user; yet it is undesirable from a security standpoint to allow long-running processes like WebLogic Server to run with more privileges than necessary. WebLogic Server needs root privileges only until the port is bound.

WebLogic Server provides capabilities to switch its UNIX user ID (UID) and/or UNIX group ID (GID) after it binds to port 80. You can change the UID (or GID) either through the WebLogic Remote Console (see Configuring the Listen Port) or by accessing UnixMachineMBean using WLST. Use UnixMachineMBbean.setPostBindUID() to set the UID and enable the switch by setting UnixMachineMBean.setPostBindUIDEnabled() to true. Similarly, the GID can be changed using methods UnixMachineMBean.setPostBindGID() and UnixMachineMBean.setPostBindGIDEnabled().

You can switch to the UNIX account "nobody," which is the least privileged user on most UNIX systems. If desired, you may create a UNIX user account expressly for running WebLogic Server. Make sure that files needed by WebLogic Server, such as log files and the WebLogic classes, are accessible by the non-privileged user. Once ownership of the WebLogic process has switched to the non-privileged user, WebLogic will have the same read, write, and execute permissions as the non-privileged user.

You define a separate listen port for non-SSL and secure (using SSL) requests. For additional information on configuring listen ports, see Understanding Network Channels.

Configuring the Listen Port

Parent topic: Configuring Web Server Functionality

Configuring the Listen Port

Use the WebLogic Remote Console to set the listen port to port 80. See Specify Listen Ports.
If the machine hosting WebLogic Server is running Windows, skip to step 8.
Use the WebLogic Remote Console to create a new Unix Machine. See Configure Machines.
Select the Enable Post-Bind UID field.
Enter the user name you want WebLogic Server to run as in the Enable Post-Bind UID field.
Select the Enable Post-Bind GID fields.
Enter the group name you want WebLogic Server to run as in the Enable Post-Bind GID field.
Click Save.

Parent topic: Configuring the Server

Web Applications

HTTP and Web applications are deployed according to the Jakarta Servlet 4.0 and JSP 2.3 specifications, which describe Web Applications as a standard for grouping the components of a Web-based application. These components include JSP pages, HTTP servlets, and static resources such as HTML pages or image files. In addition, a Web application can access external resources such as EJBs and JSP tag libraries. Each server can host any number of Web applications. You typically use the name of the Web application as part of the URI you use to request resources from the Web application.

See Developing Web Applications, Servlets, and JSPs for Oracle WebLogic Server.

Web Applications and Clustering

Parent topic: Configuring Web Server Functionality

Web Applications and Clustering

Web applications can be deployed to a WebLogic Server cluster. When a user requests a resource from a Web application, the request is routed to one of the servers in the cluster that host the Web application. If an application uses a session object, then sessions must be replicated across the nodes of the cluster. Several methods of replicating sessions are provided.

See Administering Clusters for Oracle WebLogic Server.

Parent topic: Web Applications

Configuring Virtual Hosting

Virtual hosting allows you to define host names that servers or clusters respond to. When you use virtual hosting, you use DNS to specify one or more host names that map to the IP address of a WebLogic Server instance or cluster, and you specify which Web applications are served by the virtual host. When used in a cluster, load balancing allows the most efficient use of your hardware, even if one of the DNS host names processes more requests than the others.

For example, you can specify that a Web application called books responds to requests for the virtual host name www.books.com, and that these requests are targeted to WebLogic Servers A,B, and C, while a Web application called cars responds to the virtual host name www.autos.com and these requests are targeted to WebLogic Servers D and E. You can configure a variety of combinations of virtual host, WebLogic Server instances, clusters, and Web applications, depending on your application and Web server requirements.

For each virtual host that you define you can also separately define HTTP parameters and HTTP access logs. The HTTP parameters and access logs set for a virtual host override those set for a server. You may specify any number of virtual hosts.

You activate virtual hosting by targeting the virtual host to a server or cluster of servers. Virtual hosting targeted to a cluster will be applied to all servers in the cluster.

Parent topic: Configuring Web Server Functionality

Virtual Hosting and the Default Web Application

You can also designate a default Web Application for each virtual host. The default Web application for a virtual host responds to all requests that cannot be resolved to other Web applications deployed on the same server or cluster as the virtual host.

Unlike other Web applications, a default Web application does not use the Web application name (also called the context path) as part of the URI used to access resources in the default Web application.

For example, if you defined virtual host name www.mystore.com and targeted it to a server on which you deployed a Web application called shopping, you would access a JSP called cart.jsp from the shopping Web application with the following URI:

http://www.mystore.com/shopping/cart.jsp

If, however, you declared shopping as the default Web application for the virtual host www.mystore.com, you would access cart.jsp with the following URI:

http://www.mystore.com/cart.jsp

See How WebLogic Server Resolves HTTP Requests.

When using multiple Virtual Hosts with different default Web applications, you can not use single sign-on, as each Web application will overwrite the JSESSIONID cookies set by the previous Web application. This will occur even if the CookieName, CookiePath, and CookieDomain are identical in each of the default Web applications.

Parent topic: Configuring Virtual Hosting

Setting Up a Virtual Host

Use the Remote Console to define a virtual host in the Edit Tree, under Environment: Virtual Hosts.
1. Create a new virtual host.
2. Configure General virtual host properties.
3. Configure HTTP Logging settings for a virtual host.
4. Configure HTTP for a virtual host.
5. Target the virtual host to servers.
Add a line naming the virtual host to the etc/hosts file on your server to ensure that the virtual host name can be resolved.

Parent topic: Configuring Virtual Hosting

How WebLogic Server Resolves HTTP Requests

When WebLogic Server receives an HTTP request, it resolves the request by parsing the various parts of the URL and using that information to determine which Web application and/or server should handle the request.

Table 2-1 demonstrates various combinations of requests for Web applications, virtual hosts, servlets, JSPs, and static files and the resulting response.

Note:

If you package your Web application as part of an Enterprise application, you can provide an alternate name for a Web application that is used to resolve requests to the Web application. See Developing Web Applications, Servlets, and JSPs for Oracle WebLogic Server.

Table 2-1 provides some sample URLs and the file that is served by WebLogic Server. The Index Directories Checked column refers to the Index Directories attribute that controls whether or not a directory listing is served if no file is specifically requested.

Table 2-1 Examples of How WebLogic Server Resolves URLs

URL	Index Directories Checked?	This file is served in response
`http://host:port/apples`	No	Welcome file* defined in the `apples` Web application.
`http://host:port/apples`	Yes	Directory listing of the top-level directory of the `apples` Web application.
`http://host:port/oranges/naval`	Does not matter	Servlet mapped with `<url-pattern>` of `/naval` in the `oranges` Web application. There are additional considerations for servlet mappings. See Configuring Servlets in Developing Web Applications, Servlets, and JSPs for Oracle WebLogic Server.
`http://host:port/naval`	Does not matter	Servlet mapped with `<url-pattern>` of `/naval` in the `oranges` Web application and `oranges` is defined as the default Web application. See Configuring Servlets in Developing Web Applications, Servlets, and JSPs for Oracle WebLogic Server.
`http://host:port/apples/pie.jsp`	Does not matter	`pie.jsp`, from the top-level directory of the `apples` Web application.
`http://host:port`	Yes	Directory listing of the top-level directory of the default Web application
`http://host:port`	No	Welcome file* from the default Web application.
`http://host:port/apples/myfile.html`	Does not matter	`myfile.html`, from the top-level directory of the `apples` Web application.
`http://host:port/myfile.html`	Does not matter	`myfile.html`, from the top-level directory of the default Web application.
`http://host:port/apples/images/red.gif`	Does not matter	`red.gif`, from the images subdirectory of the top-level directory of the `apples` Web application.
`http://host:port/myFile.html` Where `myfile.html` does not exist in the `apples` Web application and a default servlet has not been defined.	Does not matter	Error 404
`http://www.fruit.com/`	No	Welcome file from the default Web application for a virtual host with a host name of `www.fruit.com`.
`http://www.fruit.com/`	Yes	Directory listing of the top-level directory of the `default` Web application for a virtual host with a host name of `www.fruit.com`.
`http://www.fruit.com/oranges/myfile.html`	Does not matter	`myfile.html`, from the `oranges` Web application that is targeted to a virtual host with host name `www.fruit.com`.

Parent topic: Configuring Web Server Functionality

Health Score-Based Intelligent Routing

Health score-based intelligent routing lets you manage system optimization, avoid overload, and deal with unhealthy servers.

WebLogic Server supports intelligent load balancing, which lets Oracle HTTP Server (OHS) distribute traffic more evenly across a pool of servers according to their actual capacity. For each Managed Server in a cluster, WebLogic Server provides a default health score calculation. This health score is calculated individually, by each Managed Server instance, based on metrics and MBeans that are available locally, and then returned to OHS when requested. OHS then routes requests to the healthiest server instance. For detailed OHS information, see Support for Intelligent Load Balancing in Using Oracle WebLogic Server Proxy Plug-Ins.

How It Works

Each WebLogic Server instance computes its own health using a service provider plug-in. The WebLogic Health Service periodically invokes the plug-in to obtain the most current health value at a defined query interval, for example, every five seconds. OHS sends a request header, X-WebLogic-Request-Server-Health-Score, to each individual Managed Server instance requesting its health score. Each server's health score is sent to the OHS plug-in using a predefined HTTP response header, X-WebLogic-Server-Health-Score.

Default Health Score Plug-In
WebLogic Server provides a default plug-in implementation, which is used if a custom plug-in is not defined.
Custom Plug-In Implementation
WebLogic Server has defined the following interface that lets a service provider, define a custom plug-in implementation for calculating the health score of a clustered Managed Server instance.

Parent topic: Configuring Web Server Functionality

Default Health Score Plug-In

WebLogic Server provides a default plug-in implementation, which is used if a custom plug-in is not defined.

The WebLogic Server provided plug-in calculates a server's health score based on:

CPU load
Heap usage
Work Manager stuck threads count
Data source pending connection request counts
Health State

The default health score calculation will first check the server's health state. After this, an algorithm will consider a set of metrics. For each metric, the algorithm will calculate a "health score reduction" which is the amount that the health will be reduced because of this metric. The health score is just 100 minus the health score reduction. The metric causing the single largest health score reduction is used to arrive at the final health score, which will be 100 minus this health score reduction value.

Health State

If the server health state is HEALTH_FAILED, then the health score is 0.
If the server health state is HEALTH_OVERLOADED, then the health score reduction is 50.
For any other health state, the health state value does not affect the health score.

Note:

The inclusion of HEALTH_OVERLOADED means that you can additionally configure health thresholds using the OverloadProtectionMBean.

Parent topic: Health Score-Based Intelligent Routing

Custom Plug-In Implementation

WebLogic Server has defined the following interface that lets a service provider, define a custom plug-in implementation for calculating the health score of a clustered Managed Server instance.

Use the Health Service Provider Interface (SPI) for calculating the health score for each Managed Server in a cluster. Using the health service provider interface, you can implement a custom algorithm, based on metrics related to the overall health of the Managed Server instance. The plug-in implementation should be configured on every clustered Managed Server instance for which OHS is interested in routing requests based on the health score.

/**
* Plugin interface for calculating health score.
*/
public interface HealthScore {
  int calculateHealthScore();
}

Parent topic: Health Score-Based Intelligent Routing

Example Custom Health Score Plug-In Implementation

The following example plug-in implementation illustrates:

Looking up the reference to the local MBeanServer through JNDI.
Retrieving the relevant runtime MBeans.
Calculating a health score based on the relevant metrics.

package com.oracle.weblogic;
 
public class HealthScorePlugin implements HealthScore {
 
  // public default constructor needed for instantiation
  public HealthScorePlugin() { }
 
  @Override
  public int calculateHealthScore() {
    try {
      // Lookup local MBeanServer from JNDI.
      InitialContext ctx = new InitialContext();
      MBeanServer mbeanServer = (MBeanServer) ctx.lookup("java:comp/jmx/runtime");
       
 
      // Example of how to retrieve runtime mbeans.
      ObjectName objectName = new ObjectName("com.bea:Name=RuntimeService,Type=weblogic.management.mbeanservers.runtime.RuntimeServiceMBean");
      ObjectName serverRuntime = (ObjectName) mbeanServer.getAttribute(objectName, "ServerRuntime");
      ObjectName jvmRuntime = (ObjectName) mbeanServer.getAttribute(serverRuntime, "JVMRuntime");
      ObjectName threadPoolRuntime = (ObjectName) mbeanServer.getAttribute(serverRuntime, "ThreadPoolRuntime");
      ObjectName jdbcServiceRuntime = (ObjectName) mbeanServer.getAttribute(serverRuntime, "JDBCServiceRuntime");
 
      return getHeapFreeHealthScore(mbeanServer, jvmRuntime);
 
    } catch (Exception e) {
      throw new RuntimeException(e);
    }
  }
 
  /**
   * Example of how to retrieve "HeapFreePercent" attribute from JVMRuntime MBean and calculate related health score.
  */
  private int getHeapFreeHealthScore(MBeanServer mbeanServer, ObjectName jvmRuntime) throws ReflectionException, AttributeNotFoundException,       
        InstanceNotFoundException, MBeanException {
 
    int heapFreePercent = (int) mbeanServer.getAttribute(jvmRuntime, "HeapFreePercent");
    System.out.println("heapFreePercent: " + heapFreePercent);
    return 100 - heapFreePercent;
  }
}

Parent topic: Custom Plug-In Implementation

Configuring the Health Score

Note:

The WebLogic Health Score Service is disabled by default.

The health score configuration and plug-in registration of service providers can be defined using a HealthScoreMBean at both the domain and server level.

Configuring the health score at the domain level (using the DomainMBean) will apply to all Managed Servers defined in the WebLogic domain.
You can configure individual health scores at the server level, which will override any domain level configuration.
To make the service provider plug-in class implementation available, add it to the WebLogic Server system classpath.

See the following example health score configuration at WebLogic domain level.

<domain>
... 
  <health-score>
    <enabled>true</enabled>
    <plugin-class-name>com.oracle.weblogic.HealthScorePlugin</plugin-class-name>
    <calculate-interval-secs>10</calculate-interval-secs>
  </health-score>
</domain>

WLST Example

The following WLST examples illustrate how to enable the health score service and how to define a health score configuration at the domain level. When configured at the domain level, the HealthScoreMBean configuration applies to all the Managed Servers in the domain.

This example enables the health score service.

# Connect to the AdminServer.
connect(adminUsername, adminPassword, adminURL)
 
edit()
startEdit()
 
# Navigate to Health Score at Domain.
cd('HealthScore/your_domain')
cmo.setEnabled(true)

save()
activate()
 
disconnect()

This example defines a health score with these custom values:

PluginClassName - The class name of the custom health score plug-in to be instantiated and used by the health score service to calculate the health score of the server.
CalculateIntervalSecs - The interval (time in seconds) at which WebLogic Server will call the health score plug-in for calculating the server's health score.

# Connect to the AdminServer.
connect(adminUsername, adminPassword, adminURL)
 
edit()
startEdit()
 
# Navigate to Health Score at Domain.
cd('HealthScore/your_domain')
cmo.setPluginClassName('weblogic.health.HealthScorePlugin')
com.setCalculateIntervalSecs(10)


save()
activate()
 
disconnect()

Parent topic: Custom Plug-In Implementation

Setting Up HTTP Access Logs

WebLogic Server can keep a log of all HTTP transactions in a text file, in either common log format or extended log format.

Common log format is the default. Extended log format allows you to customize the information that is recorded. You can set the attributes that define the behavior of HTTP access logs for each server instance or for each virtual host that you define.

To set up HTTP logging for a server or a virtual host, in the Remote Console, in the Edit Tree:

For servers, go to Environment: Servers: myServer. Enable and configure HTTP access logs on the Logging: HTTP subtab.
For virtual hosts, go to Environment: Virtual Hosts: myVirtualHost. Specify the HTTP log file settings on the Logging page.

Parent topic: Configuring Web Server Functionality

Log Rotation

You can rotate the log file based on either the size of the file or after a specified amount of time has passed. When either criterion is met, the current access log file is closed and a new access log file is started. If you do not configure log rotation, the HTTP access log file grows indefinitely. You can configure the name of the access log file to include a time and date stamp that indicates when the file was rotated. If you do not configure a time stamp, each rotated file name includes a numeric portion that is incremented upon each rotation. Separate HTTP access logs are kept for each Virtual Host you have defined.

Parent topic: Setting Up HTTP Access Logs

Common Log Format

The default format for logged HTTP information is the common log format. See http://www.w3.org/Daemon/User/Config/Logging.html#common-logfile-format.

This standard format follows the pattern:

host RFC931 auth_user [day/month/year:hour:minute:second
  UTC_offset] "request" status bytes

where:

host: Either the DNS name or the IP number of the remote client
RFC931: Any information returned by IDENTD for the remote client; WebLogic Server does not support user identification
auth_user: If the remote client user sent a userid for authentication, the user name; otherwise "-"
day/month/year:hour:minute:second UTC_offset: Day, calendar month, year and time of day (24-hour format) with the hours difference between local time and GMT, enclosed in square brackets
"request": First line of the HTTP request submitted by the remote client enclosed in double quotes
status: HTTP status code returned by the server, if available; otherwise "-"
bytes: Number of bytes listed as the content-length in the HTTP header, not including the HTTP header, if known; otherwise "-"

Parent topic: Setting Up HTTP Access Logs

Setting Up HTTP Access Logs by Using Extended Log Format

WebLogic Server also supports extended log file format, version 1.0, an emerging standard defined by the draft specification from the W3C at http://www.w3.org/TR/WD-logfile.html. The current definitive reference is on the W3C Technical Reports and Publications page at http://www.w3.org/TR/.

The extended log format allows you to specify the type and order of information recorded about each HTTP communication. To enable this format in the WebLogic Remote Console:

In the Edit Tree, go to Environment: Servers: myServer.
Then, navigate to the Logging: HTTP subtab.
Make sure that HTTP access log file enabled option is on.
Click Show Advanced Fields.
In the field labeled Format, select Extended.

In the field labeled Extended Logging Format Fields, you can select one or more of the fields described in Supported Field Identifiers. If you want to add custom fields to an HTTP access log file, see Creating Custom Field Identifiers for details.

You specify the information that should be recorded in the log file with directives, included in the actual log file itself. A directive begins on a new line and starts with a pound sign (#). If the log file does not exist, a new log file is created with default directives. However, if the log file already exists when the server starts, it must contain valid directives at the head of the file.

Parent topic: Setting Up HTTP Access Logs

Creating the Fields Directive

The first line of your log file must contain a directive stating the version number of the log file format. You must also include a Fields directive near the beginning of the file:

#Version: 1.0
#Fields: xxxx xxxx xxxx ...

Where each xxxx describes the data fields to be recorded. Field types are specified as either simple identifiers, or may take a prefix-identifier format, as defined in the W3C specification. For example:

#Fields: date time cs-method cs-uri

This identifier instructs the server to record the date and time of the transaction, the request method that the client used, and the URI of the request for each HTTP access. Each field is separated by white space, and each record is written to a new line, appended to the log file.

Note:

The #Fields directive must be followed by a new line in the log file, so that the first log message is not appended to the same line.

Parent topic: Setting Up HTTP Access Logs by Using Extended Log Format

Supported Field Identifiers

The following identifiers are supported, and do not require a prefix.

date

Date at which transaction completed, field has type <date>, as defined in the W3C specification.

time

Time at which transaction completed, field has type <time>, as defined in the W3C specification.

time-taken

Time taken for transaction to complete in seconds, field has type <fixed>, as defined in the W3C specification.

bytes

Number of bytes transferred, field has type <integer>.

Note that the cached field defined in the W3C specification is not supported in WebLogic Server.

The following identifiers require prefixes, and cannot be used alone. The supported prefix combinations are explained individually.

Parent topic: Setting Up HTTP Access Logs by Using Extended Log Format

IP Address Related Fields

These fields give the IP address and port of either the requesting client, or the responding server. These fields have type <address>, as defined in the W3C specification. The supported fields are:

c-ip: The IP address of the client.
s-ip: The IP address of the server.

Parent topic: Supported Field Identifiers

DNS Related Fields

These fields give the domain names of the client or the server and have type <name>, as defined in the W3C specification. The supported fields are:

c-dns

The domain name of the requesting client.

s-dns

The domain name of the requested server.

sc-status

Status code of the response, for example (404) indicating a "File not found" status. This field has type <integer>, as defined in the W3C specification.

sc-comment

The comment returned with status code, for instance "File not found". This field has type <text>.

cs-method

The request method, for example GET or POST. This field has type <name>, as defined in the W3C specification.

cs-uri

The full requested URI. This field has type <uri>, as defined in the W3C specification.

Note:

When extended log format is enabled, the logged URI is truncated if its length exceeds 256 characters, which is the default limit. You can increase the maximum URI length by specifying it in following argument to the command that starts WebLogic Server:

-Dweblogic.servlet.maxLoggingURILength=length

cs-uri-stem

Only the stem portion of URI (omitting query). This field has type <uri>, as defined in the W3C specification.

cs-uri-query

Only the query portion of the URI. This field has type <uri>, as defined in the W3C specification.

Parent topic: Supported Field Identifiers

Diagnostic Message Correlation Fields

These fields give message correlation information for diagnostic messages, helping you to determine relationships between messages across components. These fields are logged if the diagnostic context is present and populated for the executed request. The diagnostic context may be present if it is propagated into the server with the incoming request, or it may be created for the request by WebLogic Server if the diagnostic context is enabled. The supported fields are:

ctx-ecid: The Execution Context ID (ECID). The ECID is a globally unique identifier associated with the execution of a particular request.
ctx-rid: The Relationship ID (RID). The RID distinguishes the work done in one thread on one process, from work done by any other threads on this and other processes on behalf of the same request.

If the diagnostic context does not exist, or the values of the ECID and RID are not available in the diagnostic context, a hyphen (-) is logged as their values. For more information about the ECID and RID, see Correlating Messages Across Log Files and Components in Administering Oracle Fusion Middleware.

Parent topic: Supported Field Identifiers

Creating Custom Field Identifiers

You can also create user-defined fields for inclusion in an HTTP access log file that uses the extended log format (ELF). To create a custom field, you identify the field in the ELF log file using the Fields directive and then you create a matching Java class that generates the desired output. You can create a separate Java class for each field, or the Java class can output multiple fields. For a sample of the Java source for such a class, see Example 2-1.

To create a custom field:

Include the field name in the Fields directive, using the form:
```
x-myCustomField.
```
Where myCustomField is a fully-qualified class name.

See Creating the Fields Directive.
Create a Java class with the same fully-qualified class name as the custom field you defined with the Fields directive (for example myCustomField). This class defines the information you want logged in your custom field. The Java class must implement the following interface:
```
weblogic.servlet.logging.CustomELFLogger
```
In your Java class, you must implement the logField() method, which takes a HttpAccountingInfo object and FormatStringBuffer object as its arguments:
- Use the HttpAccountingInfo object to access HTTP request and response data that you can output in your custom field. Getter methods are provided to access this information. For a complete listing of these get methods, see Get Methods of the HttpAccountingInfo Object.
- Use the FormatStringBuffer class to create the contents of your custom field. Methods are provided to create suitable output.
Compile the Java class and add the class to the CLASSPATH statement used to start WebLogic Server. You will probably need to modify the CLASSPATH statements in the scripts that you use to start WebLogic Server.

Note:

Do not place this class inside of a Web application or Enterprise application in exploded or jar format.
Configure WebLogic Server to use the extended log format. See Setting Up HTTP Access Logs by Using Extended Log Format.

Note:

When writing the Java class that defines your custom field, do not execute any code that is likely to slow down the system (For instance, accessing a DBMS or executing significant I/O or networking calls.) Remember, an HTTP access log file entry is created for every HTTP request.

Note:

If you want to output more than one field, delimit the fields with a tab character. For more information on delimiting fields and other ELF formatting issues, see "Extended Log Format" at http://www.w3.org/TR/WD-logfile-960221.html.

Get Methods of the HttpAccountingInfo Object

Parent topic: Setting Up HTTP Access Logs by Using Extended Log Format

Get Methods of the HttpAccountingInfo Object

The following methods return various data regarding the HTTP request. These methods are similar to various methods of javax.servlet.ServletRequest, javax.servlet.http.Http.ServletRequest, and javax.servlet.http.HttpServletResponse.

The Javadoc for these interfaces is available at the following locations:

For details about these methods, see the corresponding methods in the Java interfaces listed in the following table, or refer to the specific information contained in this table.

Table 2-2 Getter Methods of HttpAccountingInfo

HttpAccountingInfo Methods	Method Information
`Object getAttribute(String name);`	`javax.servlet.ServletRequest`
`Enumeration getAttributeNames();`	`javax.servlet.ServletRequest`
`String getCharacterEncoding();`	`javax.servlet.ServletRequest`
`int getResponseContentLength();`	`javax.servlet.ServletResponse.setContentLength()` This method gets the content length of the response, as set with the `setContentLength()` method.
`String getContentType();`	`javax.servlet.ServletRequest`
`Locale getLocale();`	`javax.servlet.ServletRequest`
`Enumeration getLocales();`	`javax.servlet.ServletRequest`
`String getParameter(String name);`	`javax.servlet.ServletRequest`
`Enumeration getParameterNames();`	`javax.servlet.ServletRequest`
`String[] getParameterValues(String name);`	`javax.servlet.ServletRequest`
`String getProtocol();`	`javax.servlet.ServletRequest`
`String getRemoteAddr();`	`javax.servlet.ServletRequest`
`String getRemoteHost();`	`javax.servlet.ServletRequest`
`String getScheme();`	`javax.servlet.ServletRequest`
`String getServerName();`	`javax.servlet.ServletRequest`
`int getServerPort();`	`javax.servlet.ServletRequest`
`boolean isSecure();`	`javax.servlet.ServletRequest`
`String getAuthType();`	`javax.servlet.http.HttpServletRequest`
`String getContextPath();`	`javax.servlet.http.HttpServletRequest`
`Cookie[] getCookies();`	`javax.servlet.http.HttpServletRequest`
`long getDateHeader(String name);`	`javax.servlet.http.HttpServletRequest`
`String getHeader(String name);`	`javax.servlet.http.HttpServletRequest`
`Enumeration getHeaderNames();`	`javax.servlet.http.HttpServletRequest`
`Enumeration getHeaders(String name);`	`javax.servlet.http.HttpServletRequest`
`int getIntHeader(String name);`	`javax.servlet.http.HttpServletRequest`
`String getMethod();`	`javax.servlet.http.HttpServletRequest`
`String getPathInfo();`	`javax.servlet.http.HttpServletRequest`
`String getPathTranslated();`	`javax.servlet.http.HttpServletRequest`
`String getQueryString();`	`javax.servlet.http.HttpServletRequest`
`String getRemoteUser();`	`javax.servlet.http.HttpServletRequest`
`String getRequestURI();`	`javax.servlet.http.HttpServletRequest`
`String getRequestedSessionId();`	`javax.servlet.http.HttpServletRequest`
`String getServletPath();`	`javax.servlet.http.HttpServletRequest`
`Principal getUserPrincipal();`	`javax.servlet.http.HttpServletRequest`
`boolean isRequestedSessionIdFromCookie();`	`javax.servlet.http.HttpServletRequest`
`boolean isRequestedSessionIdFromURL();`	`javax.servlet.http.HttpServletRequest`
`boolean isRequestedSessionIdFromUrl();`	`javax.servlet.http.HttpServletRequest`
`boolean isRequestedSessionIdValid();`	`javax.servlet.http.HttpServletRequest`
`byte[] getURIAsBytes();`	Returns the URI of the HTTP request as byte array. For example, If `GET /index.html HTTP/1.0` is the first line of an HTTP Request, `/index.html` is returned as an array of bytes.
`long getInvokeTime();`	Returns the starting time of `currentTimeMillis()`. To get the length of time taken by the servlet to send the response to the client, use the following code: `long milsec = System.currentTimeMillis() - metrics.getInvokeTime();` `Float sec = new Float(milsec / 1000.0);`
`int getResponseStatusCode();`	`javax.servlet.http.HttpServletResponse`
`String getResponseHeader(String name);`	`javax.servlet.http.HttpServletResponse`

Example 2-1 Java Class for Creating a Custom ELF Field

import weblogic.servlet.logging.CustomELFLogger;
import weblogic.servlet.logging.FormatStringBuffer;
import weblogic.servlet.logging.HttpAccountingInfo;
/* This example outputs the User-Agent field into a
 custom field called MyCustomField
*/
public class MyCustomField implements CustomELFLogger{
public void logField(HttpAccountingInfo metrics,
  FormatStringBuffer buff) {
  buff.appendValueOrDash(metrics.getHeader("User-Agent"));
  }
}

Parent topic: Creating Custom Field Identifiers

Preventing POST Denial-of-Service Attacks

A Denial-of-Service attack is a malicious attempt to overload a server with phony requests. One common type of attack is to send huge amounts of data in an HTTP POST method. You can set three attributes in WebLogic Server that help prevent this type of attack. These attributes are set in the Remote Console, under Servers: Protocols: HTTP or Virtual Hosts: HTTP. If you define these attributes for a virtual host, the values set for the virtual host override those set under Servers.

PostTimeout

Amount of time that WebLogic Server waits between receiving chunks of data in an HTTP POST.

The default value for PostTimeout is 30 seconds.

MaxPostTime

Maximum time that WebLogic Server spends receiving post data. If this limit is triggered, a PostTimeoutException is thrown and the following message is sent to the server log:

Post time exceeded MaxPostTime.

The default value for MaxPostTime is 30 seconds.

MaxPostSize

Maximum number of bytes of data received from a single request. The configuration controls both POST and PUT requests. If the requested data exceeds the MaxPostSize, the system throws MaxPostSizeExceeded exception and sends the following message to the server log:

POST size exceeded the parameter MaxPostSize.

If the request contains chunked transfer encoding and the requested data exceeds the MaxPostSize, MaxPostSizeException is thrown.
If the request comprises of content-length set and the requested data exceeds the MaxPostSize, the message POST size exceeded the parameter MaxPostSize. is written to server log and an HTTP error code 413 (Request Entity Too Large) is sent back to the client.

The default value for MaxPostSize is -1.

Parent topic: Configuring Web Server Functionality

Setting Up WebLogic Server for HTTP Tunneling

HTTP tunneling provides a way to simulate a stateful socket connection between WebLogic Server and a Jakarta client when your only option is to use the HTTP protocol. It is generally used to tunnel through an HTTP port in a security firewall. HTTP is a stateless protocol, but WebLogic Server provides tunneling functionality to make the connection appear to be a regular T3Connection. However, you can expect some performance loss in comparison to a normal socket connection.

Note:

Oracle does not recommend enabling tunneling on channels that are available external to the firewall.

Parent topic: Configuring Web Server Functionality

Configuring the HTTP Tunneling Connection

Under the HTTP protocol, a client may only make a request, and then accept a reply from a server. The server may not voluntarily communicate with the client, and the protocol is stateless, meaning that a continuous two-way connection is not possible.

WebLogic HTTP tunneling simulates a T3Connection via the HTTP protocol, overcoming these limitations. There are attributes that you can configure in the WebLogic Remote Console to tune a tunneled connection for performance. It is advised that you leave them at their default settings unless you experience connection problems. These properties are used by the server to determine whether the client connection is still valid, or whether the client is still alive.

Enable Tunneling

Enables or disables HTTP tunneling. HTTP tunneling is disabled by default.

Note that the server must also support both the HTTP and T3 protocols in order to use HTTP tunneling.

Tunneling Client Ping

The interval (in seconds) at which to check a tunneled client to see if it is still alive.

Default is 45 seconds; valid range is 20 to 900 seconds.

Tunneling Client Timeout

If the number of seconds set in this attribute have elapsed since the client last sent a request to the server (in response to a reply), then the server regards the client as dead, and terminates the HTTP tunnel connection. The server checks the elapsed time at the interval specified by this attribute, when it would otherwise respond to the client's request.

Default is 40 seconds; valid range is 10 to 900 seconds.

Parent topic: Setting Up WebLogic Server for HTTP Tunneling

Connecting to WebLogic Server from the Client

When your client requests a connection with WebLogic Server, all you need to do in order to use HTTP tunneling is specify the HTTP protocol in the URL. For example:

Hashtable env = new Hashtable();
env.put(Context.PROVIDER_URL, "http://wlhost:80");
Context ctx = new InitialContext(env);

On the client side, a special tag is appended to the http protocol, so that WebLogic Server knows this is a tunneling connection, instead of a regular HTTP request. Your application code does not need to do any extra work to make this happen.

The client must specify the port in the URL, even if the port is 80. You can set up your WebLogic Server instance to listen for HTTP requests on any port, although the most common choice is port 80 since requests to port 80 are customarily allowed through a firewall.

See Specify Listen Ports in the Oracle WebLogic Remote Console Online Help.

Parent topic: Setting Up WebLogic Server for HTTP Tunneling

Using Native I/O for Serving Static Files (Windows Only)

When running WebLogic Server on Windows NT/2000/XP you can specify that WebLogic Server use the native operating system call TransmitFile instead of using Java methods to serve static files such as HTML files, text files, and image files. Using native I/O can provide performance improvements when serving larger static files.

To use native I/O, add two parameters to the web.xml deployment descriptor of a Web application containing the files to be served using native I/O. The first parameter, weblogic.http.nativeIOEnabled should be set to TRUE to enable native I/O file serving. The second parameter, weblogic.http.minimumNativeFileSize sets the minimum file size for using native I/O. If the file being served is larger than this value, native I/O is used. If you do not specify this parameter, a value of 4K is used by default.

Generally, native I/O provides greater performance gains when serving larger files. However, as the load on the machine running WebLogic Server increases, these gains diminish. You may need to experiment to find the correct value for weblogic.http.minimumNativeFileSize.

The following example shows the complete entries that should be added to the web.xml deployment descriptor. These entries must be placed in the web.xml file after the <distributable> element and before the <servlet> element.

<context-param>
  <param-name>weblogic.http.nativeIOEnabled</param-name>
  <param-value>TRUE</param-value>
</context-param>
<context-param>
  <param-name>weblogic.http.minimumNativeFileSize</param-name>
  <param-value>500</param-value>
</context-param>

weblogic.http.nativeIOEnabled can also be set as a context parameter in the FileServlet.

Parent topic: Configuring Web Server Functionality