HTTP transport channel settings
Use this page to 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.
To view this administrative console page, click > Ports. Locate the port for the HTTP channel whose settings you want 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.
server_nameTransport channel name
Specifies the 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 your 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
Specifies the 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 |
Read timeout
Specifies the 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.
Information | Value |
---|---|
Data type | Integer |
Default | 60 seconds |
Write timeout
Specifies the 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.
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 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 you 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
Specifies the amount of time, in seconds, that the HTTP transport channel allows a socket to remain idle between requests.
Information | Value |
---|---|
Data type | Integer |
Default | 30 seconds |
Use persistent (keep-alive) connections
When selected, specifies that the HTTP transport channel connections remain 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 immediately 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.
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 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 your 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.
Maximum persistent requests per connection that are allowed
Specifies the maximum number of persistent requests that are allowed on a single HTTP connection. You 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 your 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 shut down 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 | 100 |
Maximum header field size
Specifies, in bytes, the maximum size on various HTTP fields on an HTTP request, such as request URLs, or individual header names or values.
Setting this property to a realistic size for your 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
Specifies the maximum number of headers that can be included in a single HTTP request.
Setting this property to a realistic number for your 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 500.
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
You 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®, you 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 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.
server_name. Then in the Troubleshooting section, clickNCSA 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. If you want to change these settings for this specific HTTP transport channel, expand the NCSA Access logging section, and select the Use chain-specific logging option.
- 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.
Disabling 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
Specifies the 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
Specifies the 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
Specifies the 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 that are specified for Error logging on the HTTP error, NCSA access and FRCA logging page in the administrative console. If you want to change these settings for this specific HTTP transport channel, expand the Error logging section, and select the Use chain-specific logging option.
- 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 of the HTTP error log file
Specifies the maximum number of historical versions of the HTTP error log file that are kept for future reference.
Error log level
Specifies the type of error messages that are included in the HTTP error log file.
- 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, you must specify a large enough log file size in the Error log maximum size field to contain all of the information that is logged.