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

[Bernd Eckenfels]

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*
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20191115/6939dcd5/attachment.html>