Hey Rafael, [Note that I've switched the mailing list to `net-dev`.]
Networking team has already been considering this for a while. We recognize the problem, but it's a convoluted area: connection load balancing, directing to a Unix domain socket address, etc. We still need to organize these requirements to determine the optimal API surface change. Your feedback is most appreciated. If you have further remarks, or more details about its potential usage context, please share. Cheers! On Sat, Sep 26, 2026 at 3:10 PM Rafael Winterhalter <[email protected]> wrote: > Hei, > java.net.http.HttpClient resolves host names inside its implementation, and > there is no per-client way to influence that. The only hook is the JVM-wide > InetAddressResolverProvider, and the JDK installs exactly one of those per > JVM. > This blocks a common SSRF defence. A server that fetches user- or > upstream-supplied URLs checks that the host resolves to a public address > and then sends the request. HttpClient resolves the name again when it > connects, so a name that rebinds between the check and the connect reaches > an internal address the check refused. Connecting to the checked > address yourself > isn't an option either: it breaks TLS host-name verification and SNI. > Other clients offer a per-client hook for exactly this: Jetty > (SocketAddressResolver), Apache HttpClient (DnsResolver) and OkHttp (Dns). > We moved our outbound calls to Jetty's client for this reason alone, while > keeping the java.net.http API. > Would a per-client resolver on HttpClient.Builder be considered? That could > be an InetAddressResolver, or a filter over the resolved addresses. > Thanks, Rafael >
