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

[Nicolas Henneaux]

Hi Daniel,

Thank you for your answer !

Such mechanism to provide an *InetSocketAddress* from a hostname would be a
great improvement and matches the usage I have.

I have an implementation using the IP in the URL in
https://github.com/nhenneaux/resilient-httpclient/tree/master/single-host-httpclient.
It needs a custom TLS hostname verifier which is not that nice but I could
live with it.
The main problem I have with such strategy is the loose of the hostname in
the HTTP header which causes wrong routing on the server side. Indeed the
target server relies on the host header for routing to the right
application. I had actually to target a server using such mechanism that
doesn't work with IP in the URl unfortunately.
I think it could also cause problem for SNI since IP's wouldn't be able to
match the right certificate.

Another solution could be to provide a mechanism to filter out a list of
*InetSocketAddress.* From *N* address resolved for the target server (proxy
or actual server), it returns one address that will be used to create the
socket and send the payload (with proxy protocol or regular HTTP).

If you decide to provide an extension mechanism what would be the next
steps? Tell me if I can help in any way to move forward on this subject.

Thanks for your help anyway,

Best regards,

Nicolas Henneaux


On Fri, 15 Nov 2019 at 17:18, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:

> 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/20191117/3f73f250/attachment.html>