HTTP transport channel settings
HTTP transport channels handle handle HTTP requests from a remote client, finding appropriate application channels to handle the request and the response.
To configure an HTTP transport channel....
Servers | Server Types | WebSphere application servers | server_name | Ports | port | View associated transports | transport chain_name | HTTP transport channelParams...
- 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.
Data type String
- Discrimination weight
- Priority this channel has in relation to the other channels in this transport chain. 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.
Data type Positive integer Default 0
- Read timeout
Amount of time, in seconds, that 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.
For transitioning users: The value specified for this property, in conjunction with the value specified for the Write timeout property, provides the timeout functionality that the ConnectionIOTimeout custom property provided in previous releases.trns
Data type Integer Default 60 seconds
- Write timeout
- Amount of time, in seconds, that 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.
For transitioning users: The value specified for this property, in conjunction with the value specified for the Read timeout property, provides the timeout functionality that the ConnectionIOTimeout custom property provided in previous releases.trns
If some of the 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 that is 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 we change the value of this setting, that the new value still protects the server from malicious clients.
Data type Integer Default 300 seconds
- Persistent timeout
- Amount of time, in seconds, that the HTTP transport channel allows a socket to remain idle between requests.
For transitioning users: The value specified for this property provides the timeout functionality that the ConnectionKeepAliveTimeout custom property provided in previous releases.trns
Data type Integer Default 30 seconds
- Use persistent (keep-alive) connections
- When selected, specifies that the HTTP transport channel connections are left open between requests. Leaving the connections open can save setup and tear down costs of sockets if the workload has clients that send multiple requests.
If the 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.
The default value is true, which is typically the optimal setting.
Avoid trouble: 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
- Number of persistent requests per connection is not limited.
- Maximum persistent requests per connection
- 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. 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 appserver, 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 the 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 that are 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 appserver, 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 the server from running out of open sockets.
If a value of 0 or 1 is specified, only one request is allowed per connection.
Data type Integer Default 100
- Maximum header field size
Specifies, in bytes, the maximum size for a header that can be included on an HTTP request.
Set 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.
Set 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.
- 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
Use the settings in this section to configure and enable National Center for Supercomputing Applications (NCSA) access logging, or HTTP error logging. If running WAS 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 we want any of the enabled logging services to start when the server starts, click...
Servers | Server Types | WebSphere application servers | server_name Troubleshooting | HTTP error | NCSA access FRCA logging | Enable logging service at server start-upWhen 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 that 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 admin 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 that 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 that 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 that the Error logging settings default to the settings specified for Error logging on the HTTP error, NCSA access and FRCA logging page in the admin 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 that 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 that 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 appserver 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 tasks
Tuning transport channel services
Set transport chains
Related
Object names: What the name string cannot contain
HTTP error, FRCA, and NCSA access log settings