WAS v8.5 > Reference > Sets
HTTP transport channel settings page
Use this page to configure an HTTP transport channel. This type of transport channel handles HTTP requests from a remote client.
An HTTP transport channel parses HTTP requests and then finds an appropriate application channel to handle the request and send a response.
To view this dmgr console page, click Servers > Server Types > WebSphere application servers > server_name > Ports. Locate the port for the HTTP channel whose settings to view or configure, and click View associated transports. Click the name of the transport chain that includes this HTTP transport, and then click the name of the HTTP transport channel.
Transport channel name
Name of the HTTP transport channel.
The name field cannot contain any of the following characters: # \ / , : ; " * ? < > | = + & % '
This name must be unique across all channels in the system. For example, an HTTP transport channel and a TCP transport channel cannot have the same name if they reside within the same system.
| Information | Value |
|---|---|
| Data type | String |
Discrimination weight
Priority this channel has in relation to the other channels in this transport chain. This property is only used when port sharing is enabled, and the transport chain includes multiple channels to which it might forward data. The channel in the chain that has the lowest discrimination weight is the first channel that looks at incoming data and determines whether it owns that data.
| Information | Value |
|---|---|
| Data type | Positive integer |
| Default | 0 |
For transitioning users: In previous versions, a "Discrimination failed"
exception in the HTTP Channel responds with a 403 response code. In v8.5, the server responds
with a 500 response code.trns
Read timeout
Amount of time, in seconds, the HTTP transport channel waits for a read request to complete on a socket after the first read occurs. The read being waited for could be part of the body of the read request, such as a POST, or part of the headers, if all of the headers are not read as part of the first read that occurs on the socket for this request.
transition: The value specified for this property, in conjunction with the value specified for the Write timeout property, provides the timeout functionality the ConnectionIOTimeout custom property provided in previous releases.
| Information | Value |
|---|---|
| Data type | Integer |
| Default | 60 seconds |
Write timeout
Amount of time, in seconds, the HTTP transport channel waits on a socket for each portion of the response data to be transmitted. This timeout typically only occurs in situations where the writes are lagging behind new requests. This situation can occur when a client has a low data rate or the network interface card (NIC) for the server is saturated with I/O.
transition: The value specified for this property, in conjunction with the value specified for the Read timeout property, provides the timeout functionality the ConnectionIOTimeout custom property provided in previous releases.
If some of your clients require more than 300 seconds to receive data being written to them, change the value specified for the Write timeout parameter. Some clients are slow and require more than 300 seconds to receive data sent to them. To ensure they are able to obtain all of their data, change the value specified for this parameter to a length of time in seconds that is sufficient for all of the data to be received. Make sure that if you change the value of this setting, the new value still protects the server from malicious clients.
| Information | Value |
|---|---|
| Data type | Integer |
| Default | 60 seconds |
Persistent timeout
Amount of time, in seconds, the HTTP transport channel allows a socket to remain idle between requests.
transition: The value specified for this property provides the timeout functionality the ConnectionKeepAliveTimeout custom property provided in previous releases.
| Information | Value |
|---|---|
| Data type | Integer |
| Default | 30 seconds |
Use persistent (keep-alive) connections
When selected, specifies the HTTP transport channel connections are left open between requests. Leaving the connections open can save setup and tear down costs of sockets if your workload has clients that send multiple requests.
If your clients only send single requests over substantially long periods of time, it is probably better to disable this option and close the connections right away rather than to have the HTTP transport channel setup the timeouts to close the connection at some later time.
Default is true, which is typically the optimal setting.
If a value other than 0 is specified for the maximum persistent requests property, the Use persistent (keep-alive) connections property setting is ignored.
Unlimited persistent requests per connection
When selected, specifies the number of persistent requests per connection is not limited.
Maximum persistent requests per connection
When selected, specifies the number of persistent requests per connection is limited to the number specified for the Maximum number of persistent requests property. This property setting is ignored if the Use persistent (keep-alive) connections property is not enabled.
Change the value specified for the Maximum persistent requests parameter to increase the number of requests that can flow over a connection before it is closed. When the Use persistent connections option is enabled, the Maximum persistent requests parameter controls the number of requests that can flow over a connection before it is closed. Default is 100. This value should be set to a value such that most, if not all, clients always have an open connection when they make multiple requests during the same session. A proper setting for this parameter helps to eliminate unnecessary setting up and tearing down of sockets.
For test scenarios in which the client will never close a socket or where sockets are always proxy or web servers in front of the application server, a value of -1 disables the processing, which limits the number of requests over a single connection. The persistent timeout still shuts down some idle sockets and protect your server from running out of open sockets.
Related Information: The behavior of persistence is the same as keep-alive connections from the HTTP Transports. The MaxKeepAliveConnections setting, which specifies the maximum number of concurrent keep alive (persistent) connections across all HTTP transports, and the thread pool size are not directly related to persistence. Persistence operates independently of the MaxKeepAliveConnections setting and thread pool size settings.
Maximum persistent requests per connection
Maximum number of persistent requests allowed on a single HTTP connection. We can add a value to this field only if the Maximum persistent requests per connection property is selected.
When the Use persistent connections option is enabled, the Maximum persistent requests parameter controls the number of requests that can flow over a connection before it is closed. The default value is 100. This value should be set to a value such that most, if not all, clients always have an open connection when they make multiple requests during the same session. A proper setting for this parameter helps to eliminate unnecessary setting up and tearing down of sockets.
For test scenarios in which the client will never close a socket or where sockets are always proxy or web servers in front of the application server, a value of -1 will disable the processing which limits the number of requests over a single connection. The persistent timeout will still shutdown some idle sockets and protect your server from running out of open sockets.
If a value of 0 or 1 is specified, only one request is allowed per connection.
| Information | Value |
|---|---|
| Data type | Integer |
| Default | 1.0 |
Maximum header field size
Specifies, in bytes, the maximum size for a header that can be included on an HTTP request.
Setting this property to a realistic size for the applications helps you to prevent denial of service (DoS) attacks that use large headers within an HTTP request as an attempt to make a system resource, such as the applications that handle HTTP requests, essentially unavailable to intended users.
The default for this property is 32768 bytes.
Maximum headers
Maximum number of headers that can be included in a single HTTP request.
Setting this property to a realistic number for the applications helps you to prevent denial of service (DoS) attacks that use a large number of headers within an HTTP request as an attempt to make a system resource, such as the applications that process HTTP requests, essentially unavailable to their intended users.
The default for this property is 50.
Even if we do not change the value of this property, when we use this dmgr console page to change other HTTP transport channel settings, the value specified for this property when we do your save is automatically saved to the corresponding property in server.xml. This change will override any value you previously set for this property in the server.xml file even if you did not intend to update the current value of this property in server.xml.
Limit request body buffer size
When selected, specifies that size of the body of an HTTP request is limited.
This property can be used to prevent denial of service attacks that use large HTTP requests as an attempt to make a system resource, such as the applications that process HTTP requests, essentially unavailable to their intended users.
Maximum request body buffer size
Specifies, in bytes, the maximum size limit for the body of an HTTP request. If this size is exceeded, the request is not processed.
A value can be added to this field only if the Limit request body buffer size property is selected.
Logging
We can use the settings in this section to configure and enable National Center for Supercomputing Applications (NCSA) access logging, or HTTP error logging. If you are running the product on z/OS , we can also use this section to configure and enable Fast Response Cache Accelerator (FRCA) logging. Enabling any of these logging services slows server performance.
If you want any of the enabled logging services to start when the server starts, click Servers > Server Types > WebSphere application servers > server_name. Then in the Troubleshooting section, click HTTP error, NCSA access and FRCA logging, and select Enable logging service at server start-up. When this option is selected, any HTTP error, NCSA or FRCA logging service that is enabled automatically starts when the server starts.
NCSA access logging
By default, the Use global logging service option is selected for NCSA access logging. This setting means the NCSA access logging settings default to the settings specified for NCSA access logging on the HTTP error, NCSA access and FRCA logging page in the dmgr console. To change these settings for this specific HTTP transport channel, expand the NCSA Access logging section, and select the Use chain-specific logging option.
After you select the Use chain-specific logging option, we can make the following configuration changes:
- Explicitly enable or disable NCSA access logging.
- Specify an access log file path that is different from the default path.
- Specify a maximum size for the access log file that is different from the default maximum size.
- Explicitly select the format of the NCSA access log file.
Enable access logging
When selected, a record of inbound client requests the HTTP transport channel handles is kept in the NCSA access log file.
Access log file path
Directory path and name of the NCSA access log file. Standard variable substitutions, such as $(SERVER_LOG_ROOT), can be used when specifying the directory path.
Access log maximum size
Maximum size, in megabytes, of the NCSA access log file. When this size is reached, the logfile_name archive log file is created. However, every time the original log file overflows this archive file, the file is overwritten with the most current version of the original log file.
Maximum number of historical files
Maximum number of historical versions of the NCSA access log file that are kept for future reference.
NCSA access log format
Specifies in which format the client access information appears in the NCSA log file. If Common is selected, the log entries contain the requested resource and a few other pieces of information, but does not contain referral, user agent, and cookie information. If Combined is selected, referral, user agent, and cookie information is included.
Error logging
By default, the Use global logging service option is selected for Error logging. This setting means the Error logging settings default to the settings specified for Error logging on the HTTP error, NCSA access and FRCA logging page in the dmgr console. To change these settings for this specific HTTP transport channel, expand the Error logging section, and select the Use chain-specific logging option.
After you select the Use chain-specific logging option, we can make the following configuration changes:
- Explicitly enable or disable HTTP Error logging.
- Specify the access log file path. This path can be different from the default path.
- Specify a maximum size for the error log file. This value can be larger or smaller than the default maximum size.
- Specify the type of error messages you want included in the HTTP error log file.
Enable error logging
When selected, HTTP errors that occur while the HTTP channel processes client requests are recorded in the HTTP error log file.
Error log file path
Indicates the directory path and the name of the HTTP error log file. Standard variable substitutions, such as $(SERVER_LOG_ROOT), can be used when specifying the directory path.
Error log maximum size
Indicates the maximum size, in megabytes, of the HTTP error log file. When this size is reached, the logfile_name archive log file is created. However, every time the original log file overflows this archive file, this file is overwritten with the most current version of the original log file.
Maximum number of historical files
Maximum number of historical versions of the HTTP error log file that are kept for future reference.
Error log level
Type of error messages that are included in the HTTP error log file.
We can select:
- Critical
- Only critical failures that stop the Application Server from functioning properly are logged.
- Error
- The errors that occur in response to clients are logged. These errors require Application Server administrator intervention if they result from server configuration settings.
- Warning
- Information on general errors, such as socket exceptions that occur while handling client requests, are logged. These errors do not typically require Application Server administrator intervention.
- Information
- The status of the various tasks that are performed while handling client requests is logged.
- Debug
- More verbose task status information is logged. This level of logging is not intended to replace RAS logging for debugging problems, but does provide a steady status report on the progress of individual client requests. If this level of logging is selected, specify a large enough log file size in the Error log maximum size field to contain all of the information that is logged.
Related
Tune transport channel services
Reference:
Object names: What the name string cannot contain
HTTP error, FRCA, and NCSA access log settings
Related information:
Transport chain settings