Repository navigation
Add per-request DNS override API (curl --resolve / OkHttp Dns-style) #866
Description
Activity
This feels like a totally reasonable feature request. Right now it's not likely to be high enough up our priority list for us to tackle it immediately, but we'd welcome a contribution and I'd make sure we got it merged and across the line.
Thanks for confirming that a contribution would be welcome. I explored a minimal additive API based on the existing
Configuration.dnsOverridebehavior and the request-levellocalAddressprecedent:public var dnsOverride: [String: String]?
In the local prototype,
niluses the client configuration, while a non-nilmapping replaces it for that request; an empty mapping explicitly disables client-level overrides. The mapping is preserved across redirects. The overridden connection target participates in the pool key, while the original host remains unchanged for the Host header, SNI, certificate validation, and request URL/tracing. The full local test suite passes.Before opening a PR, could you clarify a few contract and lifecycle choices?
- Given the client-level
Configuration.DNSResolverintroduced in Add randomized DNS resolver option for load balancing #907, would you prefer a per-request mapping, or an extension of that resolver model for per-request/custom resolution? - Should request entries replace the client mapping, or merge over it? What should an empty mapping mean?
- Should the still-public
HTTPClient.RequestAPI be supported as well? - Each distinct overridden target currently creates a distinct pool key, and the pool manager retains those pools until client shutdown. For mappings that change frequently over a long-lived client, should the target set be treated as bounded, or is empty-pool eviction/another pool-identity design expected?
I also noticed #914 touches the same request/preparation files for local-port binding, but it does not appear to overlap functionally with this work.
- Given the client-level
Could you please add support for a per-request DNS override that behaves like curl’s --resolve, or similar to OkHttp’s pluggable Dns interface (which lets you override host→IP
resolution on a per-request basis)? At the moment HTTPClient.Configuration.dnsOverride is the only entry-point, so the mapping is effectively static for the lifetime of a client. In
our workloads the host→IP mapping can change every minute, and paying the cost of creating and shutting down separate HTTPClient instances (each with its own connection pool) just to
apply a new override is prohibitively expensive.
The capability we are looking for is:
If the existing execute APIs exposed an optional per-request override, or allowed callers to provide a resolver closure (akin to overriding OkHttp’s Dns.resolve), we could keep the
default behavior while enabling dynamic overrides. We’d greatly appreciate this enhancement.