Configuring WebLogics HTTP Server
Configuring WebLogic s HTTP Server
WebLogic's HTTP server forms an implicit part of its support for a number of different protocols. For example, it supports HTTP, HTTPS, T3, T3S, IIOP, and IIOPS. This chapter concentrates on its support for HTTP only, while Chapter 13 examines the other protocols. The HTTP protocol can be configured from the Administration Console by selecting the Server node from the navigation tree in the left frame, and then choosing the Protocols/HTTP tab from the right frame. As the next section will explain, identical HTTP settings can be configured for a number of virtual hosts as well. Table 3-1 lists the general settings for the HTTP server (or virtual host).
|
Parameter |
Description |
Default |
|---|---|---|
|
Default Server Name |
Sets the hostname returned in the HTTP response header when the web server redirects a request. |
none |
|
Enable Keepalives |
Use this to set HTTP keepalives. You generally want this set to true. |
true |
|
Duration |
The number of seconds to wait before closing an inactive HTTP connection. |
30 |
|
HTTPS Duration |
The number of seconds to wait before closing an inactive HTTPS connection. |
60 |
The Default Server Name is useful when you are using a firewall or a load balancer, and redirected requests from the browser should go to a particular hostname. For example, suppose that you set the hostname to xena, and the server is configured with the listen address 10.0.10.10. Now suppose that when a client submits a request for the URL http://10.0.10.10:7001/, the web server redirects the request to the main welcome page say, index.jsp. The Default Server Name setting ensures that the supplied hostname is included in the redirected URL http://xena:7001/index.jsp.
Three additional attributes, available in the advanced section, also are relevant if you have some frontend, such as a load balancer or firewall. If the frontend causes inaccurate information to be delivered in the incoming HTTP headers, such as erroneous hostname or port number information, you may want WebLogic to ignore the information received in the header, and instead configure WebLogic with this data. The frontend host and ports parameters allow you to do just this.
3.1.1 Denial-of-Service Attacks
POST denial-of-service attacks attempt to put a web server out of service by overloading it with HTTP POSTs. The first three configuration settings described in Table 3-2 help prevent these attacks from overwhelming a server. WebLogic supports two additional settings that are useful in guarding against more general denial-of-service attacks.
|
Parameter |
Description |
Default |
|---|---|---|
|
Post Timeout Secs |
This setting limits the amount of time that the server waits between receiving chunks of data in an HTTP POST. It defaults to 30 seconds. |
30 |
|
Max Post Size |
This setting limits the maximum amount of data that WebLogic will receive for an HTTP POST. If this size is exceeded, a MaxPostSizeExceeded exception is thrown and the message "POST size exceeded the parameter MaxPostSize" is written to the server log. In this case, an HTTP error code also is sent back to the client: code 413 (Request Entity too large). |
-1 |
|
HTTP Max Message Size |
Set this attribute to specify the maximum HTTP message size allowable in a message header. This helps prevent attacks that try and force the server to allocate more memory than is available, increasing response time. |
-1 |
|
HTTP Message Timeout |
Set this attribute to specify the maximum number of seconds that WebLogic waits for a complete HTTP message to be received. This helps prevent attacks where callers tie up connections by indicating that they will be sending a message of a certain size, which they never finish sending. |
-1 |
You should configure these settings appropriately according to the performance needs of your network and application.
3.1.2 WAP Options
There are two options that can be used to configure WAP support. Both of these are available under the advanced options of the Protocols/HTTP tab and are listed in Table 3-3.
|
Parameter |
Description |
Default |
|---|---|---|
|
WAP Enabled |
If this is selected, the session ID will not include JVM information. This can be used to limit the size of URLs when using URL rewriting on WAP devices. |
Disabled |
|
Send Server Header |
If set to false, the server name is not sent with the HTTP response. This is useful for saving header space for WAP applications. |
true |
3.1.3 Setting the Default Web Application
Each server or virtual host can be configured with a default web application that responds to HTTP requests that can't be resolved to any of the targeted web applications. This means that a client can access any resource within the default web application, even without a context path in its URL. For instance, if a web application called webapp is the default web application for WebLogic Server, a file hello.jsp under the document root can be accessed through the URL http://server:port/hello.jsp. Whenever a client invokes a URL that uses a context path that cannot be resolved to any of the deployed web applications, WebLogic automatically forwards the request to the default web application (if it exists). If the resource cannot be found within the default web application, or if no default web application has been configured for the server (or virtual host), the client will receive an HTTP 404, Resource Not Found error.
Setting up a web application as the default requires nothing more than setting its context root to /. To set the context path, you must set the context-root element within the weblogic.xml descriptor for the web application. Here is an example:
/
Be sure to target the web application to the particular server or virtual host.
|