A transport is the request queue between a WAS plug-in for Web servers and a Web container in which the Web modules of an application reside. When a user at a Web browser requests an application, the request is passed to the Web server, then along the transport to the Web container.
Transports define the characteristics of the connections between a Web server and an appserver, across which requests for applications are routed. Specifically, they define the connection between the Web server plug-in and the Web container of the application server.
Administering transports is closely related to administering WAS plug-ins for Web servers. Indeed, without a plug-in configuration, a transport configuration is of little use.
The internal transport
The internal HTTP transport allows HTTP requests to be routed to the appserver directly or indirectly through a Web server plug-in. Logging is provided for debug purposes. By default, the internal HTTP transport listens for HTTP requests on port 9080 and for HTTPS requests on port 9443.
For example, use the URL http://localhost:9080/snoop to send requests to the snoop servlet on the local machine over HTTP and https://localhost:9443/snoop to send requests to the snoop servlet on the local machine over HTTPS.
The transport configuration is a part of the Web container configuration. You can configure the internal transport to use ports other than 9080 and 9443. However, also adjust your virtual host alias and what you type into the Web browser.
HTTP transport custom properties
- To set, go to...Console | Servers | Application Servers | server | Web Container | HTTP Transport | Host | Custom Properties | New
- On the settings page, enter the property you want to configure in the Name field and the value you want to set it to in the Value field.
- Click "Apply | Save"
- Restart the server.
The following custom properties are provided:
Maximum number of seconds to wait when trying to read or process data during a request.seconds.
Default is 5
Maximum number of seconds to wait for the next request on a keep alive connection.
Maximum number of seconds to wait when trying to read or write data during a response.
Default is 300 seconds
Maximum number of outstanding connect requests that the operating system will buffer while it waits for the appserver to accept the connections. If a client attempts to connect when this operating system buffer is full, the connect request will be rejected.
Set this value to the number of concurrent connections that you would like to allow. Keep in mind that a single client browser might need to open multiple concurrent connections (perhaps 4 or 5); however, also keep in mind that increasing this value consumes more kernel resources. The value of this property is specific to each transport.
Maximum number of concurrent keep alive (persistent) connections across all HTTP transports. To make a particular transport close connections after a request, you can set MaxKeepAliveConnections to 0 (zero) or you can set KeepAliveEnabled to false on that transport.
The Web server plug-in keeps connections open to the appserver as long as it can. However, if the value of this property is too small, performance is negatively impacted because the plug-in has to open a new connection for each request instead of sending multiple requests through one connection. The appserver might not accept a new connection under a heavy load if there are too many sockets in TIME_WAIT state. If all client requests are going through the Web server plug-in and there are many TIME_WAIT state sockets for port 9080, the appserver is closing connections prematurely, which decreases performance. The appserver closes the connection from the plug-in, or from any client, for any of the following reasons...
- The client request was an HTTP 1.0 request when the Web server plug-in always sends HTTP 1.1 requests.
- The maximum number of concurrent keep-alives was reached. A keep-alive must be obtained only once for the life of a connection, that is, after the first request is completed, but before the second request can be read.
- The maximum number of requests for a connection was reached, preventing denial of service attacks in which a client tries to hold on to a keep-alive connection forever.
- A time out occurred while waiting to read the next request or to read the remainder of the current request.
Default is 90% of the maximum number of threads in the Web container thread pool. This prevents all of the threads from being held by keep alive connections so that there are threads available to handle new incoming connect requests.
Maximum number of requests which can be processed on a single keep alive connection. This parameter can help prevent denial of service attacks when a client tries to hold on to a keep-alive connection. The Web server plug-in keeps connections open to the appserver as long as it can, providing optimum performance.
Whether or not to keep connections alive
Specify whether or not a client certificate should be resolved to a SAF principal. If this property is set to true, all SSL connections from a browser must have a client certificate, and the user ID associated with that client certificate must have RACF CONTROL authority for CB.BIND.servername. If these conditions are not met, the connection will be closed. Issue the following RACF command to give the user ID associated with that client certificate RACF CONTROL authority:PERMIT CB.BIND.servername CLASS(CBIND) ID(clientCertUserid) ACCESS(CONTROL)
Private Headers received from a WebSphere plug-in for Web servers are to be trusted.