On Thu, 2025-04-24 at 13:04 -0700, Ryan Schmitt wrote: > > UDS looks like a route / connection property, not a request one. So > > RequestConfig would likely be a bad choice. ConnectionConfig would > > make > > a better choice in my option. Better yet, it could be a method, say > > #useUnixSocket, in the `PoolingHttpClientConnectionManagerBuilder` > > that > > would make the connection manager use a special UDS based > > `HttpClientConnectionOperator`. This would be pretty much > > equivalent to > > the `curl --unix-socket` option. > > I think that a Unix domain socket is conceptually a proxy: you're > connecting to `localhost` but proxying the request through an IPC > mechanism. And I think it's awkward to say that a route property is > not a request property for two reasons: > > 1. There is currently a `proxy` field defined on `RequestConfig` > (admittedly deprecated) > 2. The `HttpRoutePlanner` computes the route entirely from > request-scoped information: the target, the HttpContext, and the > HttpRequest itself.
Hi Ryan You are right. The route for a request gets determined based on properties of the request or some applicable defaults. I am fine with using `RequestConfig` to contain UDS properties as well. In this case we should also un-deprecate the `proxy` property in `RequestConfig` to be consistent. Oleg --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
