Question & Answer
Question
APAR IV75042 implies that starting from version 7.0.0.18 WebSEAL would send RST packet to client after persistent connection timeout has passed. However, customer who was running ISAM version 7.0.0.22 observed FIN packet being sent to client.
Cause
Customer provided use case where several HTTP requests were sent to WebSEAL and one of requests was sent after persistent connection time had been exceeded ( persistent-con-timeout = 5 ). The collected TCP/IP packet trace showed FIN packet being sent to client:
Answer
Starting with ISAM 7.0 the design was changed to send FIN packet instead for RST packet when [server] persistent-con-timeout has expired.
Sending FIN packet to client after persistent connection timeout has exceeded is intentional even after FP18 or newer fix pack has been applied. RST will only be received if error ( return code or timeout ) occurs before the first usage.
The design has been intentionally changed because of the negative effects of sending RST when no data has been sent (which is a non-error condition).
The effect of the RST is more than just closing the socket, it causes the client to clear all unread TCP buffer data.
Example:
Assume you are working with a bank and withdrawal $1,000,000.00 which has been successfully completed and the response sent to the browser.
If the WebSEAL has a lot of active worker threads, then the persistent-con-timeout will be scaled down. This situation could cause connection being closed faster than normal and if the browser was in the middle of reading response, RST would terminate connection unwanted matter. The same problem would arise if the browser is just slow with reading a response.
If the socket is persistent and no data is sent
In 6.1.1, it would send the RST which would force the browser to delete the completed and unread TCP data.
In 7.0. and up, it would send the FIN allowing the completed and unread TCP data to be read.
The following test cases were executed to demonstrate WebSEAL behavior. Connection to a WebSEAL instance was established using a telnet like application.
Notice the key difference is when the first read of the request (whether first on socket or persistent socket).
Not sending data (whether first or persistent socket) is not an error condition. See test cases 1 and 5 below.
Test # Action
1 Send nothing, just wait until disconnected
2 Send ( one byte + hit enter ):
G <hit enter>
3 Send:
GET / HTTP/1.1 <hit enter>
Host: 192.168.10.25
Wait until disconnected
4 Send:
GET / HTTP/1.1 <hit enter>
Host: 192.168.10.25
Wait pass
persistent-con-timeout value
e.g. About 10 seconds
ctrl + c
5 Send:
GET / HTTP/1.1 <hit enter>
Host: 192.168.10.25 <hit enter>
<hit enter>
Wait until disconnected
6 Send:
GET / HTTP/1.1 <hit enter>
Host: 192.168.10.25 <hit enter>
<hit enter>
GET / HTTP/1.1 <hit enter>
Wait until disconnected
7 Send:
GET / HTTP/1.1 <hit enter>
Host: 192.168.10.25 <hit enter>
<hit enter>
GET / HTTP/1.1 <hit enter>
Host: 192.168.10.25 <hit enter>
Wait until disconnected
* with ISAM 7, 22 seconds is not expected -> See APAR IV85652
delta time = seconds between last send/received packet and closure packet ( FIN or RST )
closure packet = TCP/IP packet sent for connection closure ( FIN / RST )
The following WebSEAL timeout settings were used for testing:
[server]
# Initial client connection timeout (seconds)
client-connect-timeout = 20
# HTTP/1.1 persistent connection timeout (seconds)
# This only affects connections to clients, not backend systems.
persistent-con-timeout = 5
# Intra-request timeout (seconds)
# Timeout between data received or sent for a given request,
# but not the first read. When this value is non-zero, it
# also enables timeouts on http writes to clients and causes
# a TCP RST packet to be sent if a connection timeout occurs
# on the non-first data I/O. When this value is zero, the
# client-connection-timeout is used instead.
intra-connection-timeout = 30
Related Information
Was this topic helpful?
Document Information
Modified date:
16 June 2018
UID
swg21985223