+

Search Tips   |   Advanced Search

HTTP transport channel settings

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

From the admin console, click...

Click the name of the transport chain that includes this 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 this version of the product, the server responds with a 500 response code.trns


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

Information Value
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 our 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 we change the value of this setting, that 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, 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

Information Value
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 your workload has clients that send multiple requests.

If our 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 that the number of persistent requests per connection is not limited.


Maximum persistent requests per connection

When selected, specifies that 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. The 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 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 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 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 the 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 100


Maximum header field size

Specifies, in bytes, the maximum size for a header that can be included on an HTTP request.

Set 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 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 administrative 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 the server.xml file. This change will override any value we previously set for this property in the server.xml file even if we did not intend to update the current value of this property in the server.xml file.


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

To have any of the enabled logging services to start when the server starts, click...

        Servers > Server Types > WebSphere application servers > server. 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 enabled automatically starts when the server starts.

If we are running the product on z/OS, HTTP error, NCSA access, and FRCA logging settings must be specified on the controller. These settings are ignored if they are specified on the servant or adjunct.


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 administrative 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 selecting the Use chain-specific logging option, we can make the following configuration changes:


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.


Disable chain specific logging

To disable NCSA, FRCA, and error logging on a specified chain, set the HTTP Transport Channel custom property loggingDisable. Once the custom property is set or a change is made to its value, the server must be restarted before the changes will take effect.


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.

(ZOS) If we are running the product on z/OS, we should use a server-specific variable, such as $(SERVER_LOG_ROOT), to prevent log file name collisions.


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.


(ZOS) FRCA logging

By default, the Use global logging service option is selected for FRCA logging. This setting means that the FRCA logging settings default to the settings that are specified for FRCA logging on the HTTP error, NCSA access and FRCA logging page in the administrative console. To change these settings for this specific HTTP transport channel, expand the FRCA logging section, and select the Use chain-specific logging option.

This field only displays if we are running the product on z/OS.

After selecting the Use chain-specific logging option, we can make the following configuration changes:


(ZOS) Enable FRCA logging

When selected, a record of inbound client requests that the HTTP transport channel handles is kept in the FRCA log file.

This field only displays if we are running the product on z/OS.


(ZOS) FRCA log file path

Directory path and name of the FRCA log file. we should use a server-specific variable, such as $(SERVER_LOG_ROOT), to prevent log file name collisions.

This field only displays if we are running the product on z/OS.


(ZOS) FRCA log maximum size

Maximum size, in megabytes, of the FRCA 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.

This field only displays if we are running the product on z/OS.


(ZOS) Maximum number of historical files

Maximum number of historical versions of the FRCA log file that are kept for future reference.

This field only displays if we are running the product on z/OS.


(ZOS) FRCA log format

Specifies in which format the client access information appears in the FRCA 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.

This field only displays if we are running the product on z/OS.


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 administrative 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 selecting the Use chain-specific logging option, we can make the following configuration changes:


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.

(ZOS) If we are running the product on z/OS, we should use a server-specific variable, such as $(SERVER_LOG_ROOT), to prevent log file name collisions.


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

  • Configure transport chains
  • Tune transport channel services
  • Object names: What the name string cannot contain
  • HTTP error, FRCA, and NCSA access log settings
  • Transport chain settings