On 2025/04/21 17:40:01 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. > > IMPLEMENTATION > > There are two options here: the JDK16 standard library, and > JUnixSocket. I think we should do basically what we did for ALPN > before JDK 1.8 Maintenance Release 3: model JUnixSocket as an optional > dependency, use reflection to check for both implementations, and fail > if neither one can be found. For JDK16 support we have the option of > vending a multi-release jar, but this would add significant build-time > complexity with little clear benefit over a MethodHandle set in a > static initializer (this approach has equivalent performance to static > linkage, for example). > > ASYNC > > According to my research, JDK16 and JUnixSocket both support > non-blocking IO through the usual NIO abstractions like SocketChannel > and Selector. > > SOCKET TYPES > > There are two types of Unix domain sockets. AF_UNIX is supported > pretty much everywhere (even Windows) and is accessed as a file on the > filesystem. Linux additionally offers abstract Unix domain sockets, > which are accessed through a special namespace. Only AF_UNIX is > supported by JDK16, so this feature would require JUnixSocket. I > recommend only supporting AF_UNIX for the time being, since I'm not > aware of any other HttpComponents features that are non-portable (such > as epoll support). > > 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.
Well-known issue: https://github.com/whatwg/url/issues/577 see also: https://httpd.apache.org/docs/2.4/mod/mod_proxy.html#proxypass I prefer JUnixSocket since it works everywhere and has been around for years AND I prefer the path to the socket be out of band to avoid confusing and interpretation. Do you have competitive numbers how the speed up looks for you? M --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
