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.henne...@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*
