BEA Home | Events | Solutions | Partners | Products | Services | Download | Developer Center | WebSUPPORT
| WebLogic Server Doc Home | Administration Guide | Previous Topic | Next Topic | Contents | Index | View as PDF

Configuring WebLogic Server Web Components

The following sections discuss how to configure WebLogic Server Web components:

- Overview

- HTTP Parameters

- Configuring the Listen Port

- Web Applications

- Configuring Virtual Hosting

- How WebLogic Server Resolves HTTP Requests

- Setting Up HTTP Access Logs

- Preventing POST Denial-of-Service Attacks

- Setting Up WebLogic Server for HTTP Tunneling

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

Overview

In addition to its ability to host dynamic Java-based distributed applications, WebLogic Server is also a fully functional Web server that can handle 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.

HTTP Parameters

You can configure the HTTP operating parameters using the Administration Console for each Server or Virtual Host.

Attribute | Description | Range of Values | Default Value
--- | --- | --- | ---
FrontendHost | When WebLogic Server redirects a request, it sets the host name returned in the HTTP response header with the string specified with Default Server Name. Useful when using firewalls or load balancers and you want the redirected request from the browser to reference the same host name that was sent in the original request. | String | Null
FrontendHTTPPort | The frontend HTTP Port is set when the Port information coming from the URL may be inaccurate due to the presence of a firewall or proxy. If this parameter is set, the HOST header is ignored and this value is always used. | Valid Listen Port | null
FrontendHTTPSPort | The frontend HTTPS Port is set when the Port information coming from the URL may be inaccurate due to the presence of a firewall or proxy. If this parameter is set, the HOST header is ignored and this value is always used. | Valid Listen Port | null
Enable Keepalives | This attribute sets whether or not HTTP keep-alive is enabled | Boolean True = enabled False = not enabled | True
Send Server Header | If set to false, the server name is not sent with the HTTP response. Useful for wireless applications where there is limited space for headers. | Boolean True = enabled False = not enabled | True
Duration (labeled Keep Alive Secs on the Virtual Host panel) | The number of seconds that WebLogic Server waits before closing an inactive HTTP connection. | Integer | 30
HTTPS Duration (labeled Https Keep Alive Secs on the Virtual Host panel) | The number of seconds that WebLogic Server waits before closing an inactive HTTPS connection. | Integer | 60
WAP Enabled | When selected, the session ID no longer includes JVM information. This may be necessary when using URL rewriting with WAP devices that limit the size of the URL to 128 characters. Selecting WAP Enabled may affect the use of replicated sessions in a cluster. | Enabled Disabled | Disabled
Post Timeout Secs | This attribute sets the timeout (in seconds) that WebLogic Server waits between receiving chunks of data in an HTTP POST data. Used to prevent denial-of-service attacks that attempt to overload the server with POST data. | Integer | 30
Max Post Time | This attribute sets the time (in seconds) that WebLogic Server waits for chunks of data in an HTTP POST data. | Integer | -1
Max Post Size | This attribute sets the size of the maximum chunks of data in an HTTP POST data. | Integer | -1
External DNS Address | If your system includes an address translation firewall that sits between the clustered WebLogic Servers and a plug-in to a web server front-end, such as the Netscape (proxy) plug-in, set this attribute to the address used by the plug-in to talk to this server. |  |

Configuring the Listen Port

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

You define a separate listen port for regular and secure (using SSL) requests. You define the regular listen port on the Servers node in the Administration Console, under the Configuration/General tab, and you define the SSL listen port under the Configuration/SSL tab.

Web Applications

HTTP and Web services are deployed according to the Servlet 2.3 specification from Sun Microsystems, which describes the use of Web Applications as a standardized way of grouping together 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 normally use the name of the Web Application as part of the URI you use to request resources from the Web Application.

For more information, see Assembling and Configuring Web Applications.

Web Applications and Clustering

Web Applications can be deployed in a cluster of WebLogic Servers. When a user requests a resource from a Web Application, the request is routed to one of the servers of 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.

For more information, see Using WebLogic Server Clusters.

Designating a Default Web Application

Every server and virtual host in your domain can declare a default Web Application. The default Web Application responds to any HTTP request that cannot be resolved to another deployed Web Application. In contrast to all other Web Applications, the default Web Application does not use the Web Application name as part of the URI. Any Web Application targeted to a server or virtual host can be declared as the default Web Application. (Targeting a Web Application is discussed later in this section. For more information about virtual hosts, see Configuring Virtual Hosting).

The default domain and the examples domain that are shipped with Weblogic Server each have a default Web Application already configured. The default Web Application in these domains is named `DefaultWebApp` and is located in the `applications` directory of each domain.

If you declare a default Web Application that fails to deploy correctly, an error is logged and users attempting to access the failed default Web Application receive an HTTP `400` error message.

For example, if your Web Application is called `shopping`, you would use the following URL to access a JSP called `cart.jsp` from the Web Application:

`http://host:port/shopping/cart.jsp`

If, however, you declared `shopping` as the default Web Application, you would access `cart.jsp` with the following URL:

`http://host:port/cart.jsp`

(Where `host` is the host name of the machine running WebLogic Server and `port` is the port number where the WebLogic Server is listening for requests.)

To designate a default Web Application for a server or virtual host, use the Administration Console:

1. In the left pane, expand the Web Application node

2. Select your Web Application

3. In the right pane, select the Targets tab.

4. Select the Servers tab and move the server (or virtual host) to the chosen column. (You can also target all the servers in a cluster by selecting the Clusters tab and moving the cluster to the Chosen column.)

5. Click Apply.

6. Expand the Servers (or virtual host) node in the left pane.

7. Select the appropriate server or virtual host.

8. In the right pane, select the General tab

9. Select the HTTP tab (If you are configuring a virtual host, select the General tab instead.)

10. Select a Web Application from the drop-down list labeled Default Web Application.

11. Click Apply.

12. If you are declaring a default Web Application for one or more managed servers, repeat these procedures for each managed server.

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

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

For more information, see How WebLogic Server Resolves HTTP Requests.

Setting Up a Virtual Host

To define a virtual host, use the Administration Console to:

1. Create a new Virtual Host.

   1. Expand the Services node in the left pane. The node expands and displays a list of services.

   2. Click on the virtual hosts node. If any virtual hosts are defined, the node expands and displays a list of virtual hosts.

   3. Click on Create a New Virtual Host in the right pane.

   4. Enter a name to represent this virtual host.

   5. Enter the virtual host names, one per line. Only requests matching one of these virtual host names will be handled by the WebLogic Server or cluster targeted by this virtual host.

   6. (Optional) Assign a default Web Application to this virtual host.

   7. Click Create.

2. Define logging and HTTP parameters:

   1. (Optional) Click on the Logging tab and fill in HTTP access log attributes (For more information, see Setting Up HTTP Access Logs.)

   2. Select the HTTP tab and fill in the HTTP Parameters.

3. Define the servers that will respond to this virtual host.

   1. Select the Targets tab.

   2. Select the Servers tab. You will see a list of available servers.

   3. Select a server in the available column and use the right arrow button to move the server to the chosen column.

4. Define the clusters that will respond to this virtual host (optional). You must have previously defined a WebLogic Cluster. For more information, see Using WebLogic Server Clusters.

   1. Select the Targets tab.

   2. Select the Clusters tab. You will see a list of available servers.

   3. Select a cluster in the available column and use the right arrow button to move the cluster to the chosen column. The virtual host is targeted on all of the servers of the cluster.

5. Target Web Applications to the virtual host.

   1. Click the Web Applications node in the left panel.

   2. Select the Web Application you want to target.

   3. Select the Targets tab in the right panel.

   4. Select the Virtual Hosts tab.

   5. Select Virtual Host in the available column and use the right arrow button to move the Virtual Host to the chosen column.

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

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. The examples below demonstrate 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. For more information, see Deploying Web Applications as Part of an Enterprise Application.

The table below 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. You set Index Directories using the Administration Console, on the Web Applications node, under the Configuration —>Files tab.

  Table 8-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. For more information, see Configuring Servlets.
  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. For more information, see Configuring Servlets.
  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 For more information, see Customizing HTTP Error Responses.
  `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`.

* For more information, see Configuring Welcome Pages.

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, and follows a standard convention. 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 or for each virtual host that you define.

Log Rotation

You can also choose to rotate the log file based on either the size of the file or after a specified amount of time has passed. When either one of these two criteria are 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. The name of the access log file includes a numeric portion that is incremented upon each rotation. Separate HTTP Access logs are kept for each Web Server you have defined.

Setting Up HTTP Access Logs by Using the Administration Console

To set up HTTP access logs use the Administration Console.

1. If you have set up virtual hosting:

   1. Select the services node in the left pane.

   2. Select the virtual hosts node. The node expands and displays a list of virtual hosts.

   3. Select a virtual host.

      If you have not set up virtual hosting:

   4. Select the servers node in the left pane. The node expands and displays a list of servers.

   5. Select a server.

   6. Select the Logging tab.

   7. Select the HTTP tab.

2. Check the Enable Logging box.

3. Enter values for your Log File Name.

4. Select Common or Extended from the drop-down list labeled Format.

5. If you want the time stamps for HTTP log messages to be in Greenwich Mean Time (GMT) regardless of the local time zone that the host computer specifies, select Log Time in GMT.

   Use this method to comply with the W3C specification for Extended Format Log Files. The specification states that all time stamps for Extended Format log entries be in GMT.

6. In Log File BufferK Bytes, set the size (in kilobytes) of the HTTP message buffer. After the HTTP message buffer reaches this size, the server writes all current entries to the HTTP log file and flushes the buffer.

7. In Log Rotation Type, select `By Size` or `By Date`.

   - `By Size:` Rotates the log when it exceeds the value entered into the Log Buffer Size parameter.

   - `By Date:` Rotates the log after the number of minutes specified with the Rotation Period parameter.

8. If you have selected `Size` as the Rotation Type, in the Max Log File Size K Bytes field specify the file size (1 - 65535 kilobytes) that triggers the server to move log messages to a separate file.

   After the log file reaches the specified size, the next time the server checks the file size, it will rename the current log file as `FileName.n` and create a new one to store subsequent messages.

9. If you have selected Date as the Rotation Type, set the Rotation time to the first date when you want the log file to rotate.

   Use the following `java.text.SimpleDateFormat` format to specify a date and time: `MM-dd-yyyy-k:mm:ss`. For information about this format, refer to the J2EE Javadoc.

   If the time that you specify has already past, then the server starts its file rotation immediately.

10. If you have selected Date as the Rotation Type, set the Rotation Period to the number of minutes after which the log file will rotate.

Common Log Format

The default format for logged HTTP information is the common log 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 "-"

Setting Up HTTP Access Logs by Using Extended Log Format

WebLogic Server also supports extended log file format, version 1.0, as defined by the W3C. This is an emerging standard, and WebLogic Server follows the draft specification from W3C. The current definitive reference may be found from the W3C Technical Reports and Publications page

The extended log format allows you to specify the type and order of information recorded about each HTTP communication. To enable the extended log format, set the Format attribute on the HTTP tab in the Administration Console to `Extended`. (See step 4. in Setting Up HTTP Access Logs by Using the Administration Console).

You specify what information 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 # 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 legal directives at the head of the file.

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. Here is an 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.

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.

  IP address related fields:

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

`c-ip`

  The IP address of the client.

`s-ip`

  The IP address of the server.

  DNS related fields

  These fields give the domain names of the client or the server. This field has type <name>, as defined in the W3C specification. The supported prefixes 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.

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

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. 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. A sample of the Java source for such a class is included in this document. See Java Class for Creating a Custom ELF Field.

To create a custom field:

1. Include the field name in the `Fields` directive, using the form:

   `x-``myCustomField`.

   Where `myCustomField` is a fully-qualified class name.

   For more information on the `Fields` directive, see Creating the Fields Directive.

2. 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. For more information on these methods, see the Javadocs for FormatStringBuffer

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

4. Configure WebLogic Server to use the extended log format. For more information, see Setting Up HTTP Access Logs by Using Extended Log Format.

Note: When writing the Java class that defines your custom field, you should 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.

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

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

Table 8-2 Getter Methods of HttpAccountingInfo

`HttpAccountingInfo Methods` | Where to find information on the methods
--- | ---
`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 `set` `ContentLength()` 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.Http.ServletRequest
`String getContextPath();` | javax.servlet.http.Http.ServletRequest
`Cookie[] getCookies();` | javax.servlet.http.Http.ServletRequest
`long getDateHeader(String name);` | javax.servlet.http.Http.ServletRequest
`String getHeader(String name);` | javax.servlet.http.Http.ServletRequest
`Enumeration getHeaderNames();` | javax.servlet.http.Http.ServletRequest
`Enumeration getHeaders(String name);` | javax.servlet.http.Http.ServletRequest
`int getIntHeader(String name);` | javax.servlet.http.Http.ServletRequest
`String getMethod();` | javax.servlet.http.Http.ServletRequest
`String getPathInfo();` | javax.servlet.http.Http.ServletRequest
`String getPathTranslated();` | javax.servlet.http.Http.ServletRequest
`String getQueryString();` | javax.servlet.http.Http.ServletRequest
`String getRemoteUser();` | javax.servlet.http.Http.ServletRequest
`String getRequestURI();` | javax.servlet.http.Http.ServletRequest
`String getRequestedSessionId();` | javax.servlet.http.Http.ServletRequest
`String getServletPath();` | javax.servlet.http.Http.ServletRequest
`Principal getUserPrincipal();` | javax.servlet.http.Http.ServletRequest
`boolean isRequestedSessionIdFromCookie();` | javax.servlet.http.Http.ServletRequest
`boolean isRequestedSessionIdFromURL();` | javax.servlet.http.Http.ServletRequest
`boolean isRequestedSessionIdFromUrl();` | javax.servlet.http.Http.ServletRequest
`boolean isRequestedSessionIdValid();` | javax.servlet.http.Http.ServletRequest
`String getFirstLine();` | Returns the first line of the HTTP request, for example: `GET /index.html HTTP/1.0`
`long getInvokeTime();` | Returns the length of time it took for the service method of a servlet to write data back to the client.
`int getResponseStatusCode();` | javax.servlet.http.HttpServletResponse
`String getResponseHeader(String name);` | javax.servlet.http.HttpServletResponse

Listing 8-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"));
>         }
>     }

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 console, under Servers or virtual hosts. If you define these attributes for a virtual host, the values set for the virtual host override those set under Servers.

  `PostTimeoutSecs`

  You can limit the amount of time that WebLogic Server waits between receiving chunks of data in an HTTP POST.

  `MaxPostTimeSecs`

  Limits the total amount of 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 MaxPostTimeSecs.`

  `MaxPostSize`

  Limits the number of bytes of data received in a POST from a single request. If this limit is triggered, a `MaxPostSizeExceeded` exception is thrown and the following message is sent to the server log:

  `POST size exceeded the parameter MaxPostSize.`

  An HTTP error code 413 (Request Entity Too Large) is sent back to the client.

  If the client is in listening mode, it gets these messages. If the client is not in listening mode, the connection is broken.

Setting Up WebLogic Server for HTTP Tunneling

HTTP tunneling provides a way to simulate a stateful socket connection between WebLogic Server and a Java 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.

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 two attributes that you can configure in the Administration Console to tune a tunneled connection for performance. You access these attributes in the Servers section, under the Tuning Tab located under the Configuration tab. 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.

  `Tunneling Ping`

  When an HTTP tunnel connection is set up, the client automatically sends a request to the server, so that the server may volunteer a response to the client. The client may also include instructions in a request, but this behavior happens regardless of whether the client application needs to communicate with the server. If the server does not respond (as part of the application code) to the client request within the number of`` seconds set in this attribute, it does so anyway. The client accepts the response and automatically sends another request immediately.

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

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

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

You specify the listen port for WebLogic Server in the Administration Console under the "Servers" node, under the "Network" tab.

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

When running WebLogic Server on Windows NT/2000 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 `400` bytes is used.

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

For more information on writing deployment descriptors, see Writing Web Application Deployment Descriptors.

Copyright © 2001 BEA Systems, Inc. All rights reserved. Required browser: Netscape 4.0 or higher, or Microsoft Internet Explorer 4.0 or higher.