On Mon, 2025-04-21 at 10:40 -0700, Ryan Schmitt wrote: > I've got Apache client 5.4.3 working with a custom connection > operator > that implements UDS support. I want to upstream this as a proper > feature, since it's significantly more efficient than localhost. I > want to discuss the design of this feature a bit; since it's a non- > TCP > transport layer, we have to be careful about how it's integrated into > the overall design of the client. > > CONVENTION > > There are a couple of ways clients expose UDS support. One is to use > a > URI scheme like unix or http+unix and provide the path to the socket > as the URI authority: > > http+unix://%2Fpath%2Fto%2Fsocket/socket.sock/path?query > > This is a slight abuse of notation since Unix sockets are a > transport, > rather than an application-level concern; additionally, neither > scheme > has no IANA registration. > > Another solution is to provide the UDS path out-of-band, as in this > example from curl's man page: > > curl --unix-socket socket-path https://example.com > > This is cleaner since it gives us a principled way to derive the Host > header (typically localhost) and doesn't stuff transport details into > the URI. It's also easier for end users to convert an existing > localhost call to UDS. I think this is my preferred approach. The > main > question is which of the many config types should expose this option. > RequestConfig seems reasonable, but there's also ConnectionConfig and > SocketConfig. >
Hi Ryan My apologies for not having responded sooner. 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. > ASYNC > > According to my research, JDK16 and JUnixSocket both support > non-blocking IO through the usual NIO abstractions like SocketChannel > and Selector. > This will likely require changes to the i/o reactor code in core but should be doable. > INTERACTIONS > > UDS support would need to work correctly with connection pooling, > route modeling, and existing features like proxy support. > Additionally, any code that assumes that the remote address is an > InetAddress or InetSocketAddress may need to be adjusted. Finally, > features like request logging and debug logging may need to account > for the possibility of a UDS connection. > As far as I know InetAddress / InetSocketAddress should be exclusively used by connection operators, so we are safe. HttpRoute may need an extra attribute though. Oleg --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
