> 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. Another issue with modeling a UDS as a proxy is that `HttpHost` and its superinterface `NamedEndpoint` are both coupled to TCP/IP and DNS (they're built around concepts like hostname, InetAddress, and port number). I see why you want to model UDS as an attribute directly on `HttpRoute`, since `ConnectionConfig` is a function of the `HttpRoute`. We could add a field like `private final Path unixDomainSocket`, but I still think there's an ergonomic issue here with requiring a custom `HttpRoutePlanner` instead of offering declarative configuration of UDS. The way forward here might be to expose this as an option on `DefaultRoutePlanner`. Users would create a UDS-enabled instance which they would then supply directly to the client builder. This would then produce a UDS-enabled `HttpRoute` for UDS-enabled requests (TODO: enabled based on what?), and the connection operator would then connect directly to the Unix socket by calling the relevant low-level code in httpcore5. Personally, I still think that `RequestConfig` is a reasonable way of exposing this option. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
