How to reuse TCP connection when using a proxy with java.net.http.HttpClient in HTTP/1.1

[Bernd Eckenfels]

The client could drain if yo close the stream,but I think it’s more flexible If the Application decides if it want to do that (it could be a config option but I guess it’s uncommon that you stop reading and. It want to discard data.

Gruss
Bernd


--
http://bernd.eckenfels.net
________________________________
Von: net-dev <net-dev-retn at openjdk.java.net> im Auftrag von Simone Bordet <simone.bordet at gmail.com>
Gesendet: Monday, January 11, 2021 10:51:16 PM
An: Nicolas Henneaux <nicolas.henneaux at gmail.com>
Cc: Daniel Fuchs <daniel.fuchs at oracle.com>; OpenJDK Network Dev list <net-dev at openjdk.java.net>
Betreff: Re: How to reuse TCP connection when using a proxy with java.net.http.HttpClient in HTTP/1.1

Hi,

On Mon, Jan 11, 2021 at 10:13 PM Nicolas Henneaux
<nicolas.henneaux at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20210111/bac239ca/attachment.htm>