Repeated `Connection idle time too long: 301` in state 13

I have been seeing this issue for a long time on OpenLiteSpeed. It occurs frequently and affects many unrelated clients. Most occurrences are for ordinary static HTTP/1.1 requests, for example:

Connection idle time too long: 301 while in state: 13 watching for event: 0, close!
Content len: 0, request line: 'GET /storage/gtfs/gtfs-rt-vehicles.pb HTTP/1.1'

The same pattern occurs for other static files, as well as for dynamic requests. There are also occurrences over HTTP/2.

For example, today's log contains many such entries within a single day, involving numerous different clients. The problem is therefore not tied to a particular application endpoint or client.

I investigated one occurrence with tcpdump, with the help of ChatGPT. The TCP connection was working normally, the client sent FIN, the server acknowledged it, and then there was no further traffic for approximately 296 seconds. The client eventually sent RST, at almost exactly the same time that OpenLiteSpeed logged the 301-second idle timeout. There were no retransmissions or other obvious signs of packet loss in the capture.

This makes a network transmission problem seem unlikely. It looks more like OpenLiteSpeed leaves the connection in state 13 (HSS_IO_ERROR) for the full connection timeout after the peer has already closed its side of the connection.

I am currently running:

OpenLiteSpeed 1.9.2
lsquic 4.9.3
Ubuntu 24.04
BUILD (built: Tue Aug 25 15:48:28 UTC 2026)

This has been happening for a long time, including with previous OpenLiteSpeed versions.

Start by tracing OpenLiteSpeed's handling of state 13 (HSS_IO_ERROR) and the connection idle-timeout log, then compare the behavior with the supplied tcpdump sequence. Reproduce with static HTTP/1.1 or HTTP/2 requests if possible. Done means a peer-closed connection is handled without waiting for the full 301-second timeout, with regression coverage where the relevant tests are found.