[java.net.http.HttpClient] Active monitoring of resolved IP addresses

[Pavel Rappo]

A more appropriate mailing list would be net-dev (cc'ed).
When replying, please remove jdk-dev from the addressees.

> On 7 Nov 2019, at 14:24, Nicolas Henneaux <nicolas.henneaux at gmail.com> wrote:
> 
> Hi,
> 
> 
> 
> I am not sure it is the right mailing list. If it’s not, I apologize in
> advance and could you tell me which is one the more appropriate?
> 
> 
> 
> *I am trying to build an HTTP client based on java.net.http.HttpClient and
> I would like to have some control on the IP addresses resolved under the
> hood.*
> 
> 
> 
> I would like such mechanism to use all the IP addresses behind the host of
> the request. The underlying problem, I am trying to solve, is to react as
> soon as possible to an unavailability of a target IP. It could be done by
> doing active monitoring for each IP and use only the addresses available
> (at TCP, TLS or HTTP level) when sending an HTTP request. I also would like
> to load balance the traffic between all the IP’s and actively detect change
> in the DNS resolution. I am maintaining a long live connection to an
> external HTTPS service.
> 
> 
> 
> At the moment, only one IP address is used by the HTTP java client and pool
> of connections is maintained to target this IP.
> 
> 
> 
> I have built a work-around by using the IP address in the URL provided to
> the HTTP client and using a specific trust manager matching the expected
> name to keep the TLS validation. It has several limitation. In particular
> it changes the HTTP request which could impact the response you received
> depending on the server you target. It also forces to use one HTTP client
> by host you want to target. I have created a small GitHub repository
> <https://github.com/nhenneaux/resilient-httpclient> to illustrate this
> workaround.
> 
> 
> 
> I explored a bit the HTTP client implementation and so far I have not found
> any way to implement such mechanism. In particular, I am stuck in
> jdk.internal.net.http.HttpRequestImpl#getAddress which is package visible
> and prevents any extension.
> 
> 
> 
> Such mechanism exists in Jetty HTTP client (see
> org.eclipse.jetty.util.SocketAddressResolver) or in HTTP Apache client.
> 
> 
> 
> *Is there any existing mechanism I could use to properly solve such
> problem? If none, is there a way to contribute or to submit a request of
> improvement? *
> 
> 
> 
> Thank you in advance for your help!
> 
> 
> 
> Best regards,
> 
> 
> 
> *Nicolas Henneaux*