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

[Daniel Fuchs]

Hi Bernd,

The HttpClient uses nio SocketChannels in non blocking mode,
not java.net.Socket.

best regards,

-- daniel

On 15/11/2019 17:10, Bernd Eckenfels wrote:
> Hello,
> 
> Another possible extension point would be a custom socket factory. This 
> has the additional benefit that the sockets from this factory also can 
> implement a happy eyeballs algorithm (which would connect in parallel to 
> multiple IP address candidates, which is especially helpful for IPv6 
> problems).
> 
> Havent looked closely, but the current API might already allow this with 
> a custom proxy selector?
> 
> Gruss
> Bernd
> -- 
> http://bernd.eckenfels.net
> ------------------------------------------------------------------------
> *Von:* net-dev <net-dev-bounces at openjdk.java.net> im Auftrag von Daniel 
> Fuchs <daniel.fuchs at oracle.com>
> *Gesendet:* Freitag, November 15, 2019 5:18 PM
> *An:* Nicolas Henneaux
> *Cc:* OpenJDK Network Dev list
> *Betreff:* Re: [java.net.http.HttpClient] Active monitoring of resolved 
> IP addresses
> Hi Nicolas,
> 
> Sorry for the late reply...
> 
> On 07/11/2019 17:13, Pavel Rappo wrote:
>  >> On 7 Nov 2019, at 14:24, Nicolas Henneaux 
> <nicolas.henneaux at gmail.com> wrote:
>  >>
>  >> Hi,
>  >>
>  >> *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? *
> 
> I don't think there is any existing mechanism, besides hardcoding
> the server's address in the URL. One thing we could potentially
> consider for future evolution is add an API to pass a lambda to the
> HttpClient.Builder that would take a hostname and a port and return
> an InetSocketAddress.
> The HttpRequestImpl could use that when its getAddress() method
> is called. Note however that this would only help when no proxy is
> used (except maybe in case of tunneling?).
> 
> Would that be enough to allow you to implement your logic?
> 
> There are security implications (permission checking) that would
> need to be carefully considered however, if we decided to that.
> 
> On the other hand having the server address in the URL instead
> should work even in the presence of proxies.
> 
> best regards,
> 
> -- daniel
> 
>  >>
>  >>
>  >>
>  >> Thank you in advance for your help!
>  >>
>  >>
>  >>
>  >> Best regards,
>  >>
>  >>
>  >>
>  >> *Nicolas Henneaux*
>  >
>