On 11/01/2021 22:51, Simone Bordet wrote:
The problem is on the client: if the client application does not read the response content, the client implementation cannot reuse that connection. It cannot use it to send the next request (independently from the server reading it or not), because when trying to read the next response it will find (possibly only some) bytes of the previous response that it will have a hard time to discard. And the server may choke in the middle of the previous response and close the connection, but oops the next request was already sent and it's now lost. So the client cannot reuse that connection to send another request ever. No other choice than to close it.
Exactly :-) Thanks Simone for the detailed explanations! FWIW HTTP/2.0 doesn't have the same problem because each request response goes over its own HTTP/2.0 stream, and the client in this case can close the stream without closing the whole connection. Unfortunately, HTTP/1.1 can only serialize requests (there's no ability to multiplex them), and therefore it has no choice but to close the whole connection if anything goes wrong. In the case of the java.net.http.HttpClient, the streaming bodies (like the InputStream provided by BodyHandlers.ofInputStream()) are made available immediately to the caller, without waiting for the body bytes to arrive. On the other hand, the simpler body handlers (like BodyHandler.ofString()) can only be made available after all bytes have been received, which explain the differences you observed with these two types of bodies... Hope this helps! best regards, -- daniel
