Hi Ondrej, Understood, thanks.
The Delphi comparison fits the cause: this only shows up because the FPC client keeps the connection after the failed read, so the late response has somewhere to be queued. The candidate is one line. In DoKeepConnectionRequest's EHTTPClientSocket handler, disconnect before deciding whether to retry or to re-raise. The retry path already reconnects; the re-raise did not, and the finally clause disconnects only on HasConnectionClose, which is False for a keep-alive request that sets no Connection header - so the caller got the exception while the client kept a socket whose state it did not know. Measured on main 8604d19b11, fourteen checks, three runs each on aarch64-win64 and aarch64-linux, identical on both: 6 failed checks unchanged, 3 with the change. The three it clears are exactly your scenario. The three that remain are the retry findings I mentioned - a non-idempotent request repeated, and a partly received response the retry appends to - which I would rather report separately. I will prepare a patch. The write-ups and the reproducer are ready. Sven _______________________________________________ fpc-pascal maillist - [email protected] https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
