rschmitt opened a new pull request, #637: URL: https://github.com/apache/httpcomponents-client/pull/637
This change adds Unix domain socket support. The sync client uses JUnixSocket, which provides synchronous UDS support through the legacy `java.net.Socket` API; the async client uses the JEP 380 implementation of UDS through the `java.nio.channels.SocketChannel` API (requires JDK16 or later). Since the synchronous client is tightly coupled to the `Socket` API, we can't trivially use JEP 380 UDS support. We would first have to write an adapter to implement the `Socket` API, backed by a JEP 380 UDS `SocketChannel`. This would require us to implement features like socket option configuration, connection timeouts, and socket timeouts; we would also have to implement APIs like `getInetAddress()` which don't actually make sense in a UDS context. This is probably doable (JUnixSocket does it, albeit with a different implementation strategy based on native code), but it's not trivial. The asynchronous client is the other way around: it supports JEP 380, but not JUnixSocket. The issue here is more subtle: JDK and JUnixDomain channels cannot be mixed in the same selector, and since JUnixDomain does not provide an implementation of TCP/IP channels, supporting JUnixSocket in the async client would require substantial rework in the IO reactor. Since JDK8 is end-of-life next year, I doubt this is worth doing unless we can find some clever way of integrating the new channel type with minimal churn. Unix domain socket support is exposed through the `RequestConfig` API. A path to a Unix domain socket can be provided as a client-wide default through `setDefaultRequestConfig`, or on a per-request basis through `setConfig`. Currently, proxies and TLS are not supported through UDS. The former feature seems unnecessary, but the latter is likely worth adding at some point, since contacting an HTTPS endpoint over UDS (sometimes denoted by the URI scheme `https+unix`) is not unheard of. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org