Hi, On Mon, Jan 11, 2021 at 10:13 PM Nicolas Henneaux <nicolas.henne...@gmail.com> wrote: > > Thanks Simone, that makes sense. I haven't thought there is actually no other > way for the server to know the response is fully consumed or not.
Just to be clear, it's not a server problem. The server won't read the next request until it's done with the current response, so for the server the request/response boundaries are clear. 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. -- Simone Bordet --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz
