2019/9/25 6:21:46 -0700, chris.hega...@oracle.com: > ... > > Yeah, what we want is for the ( standard? ) environment variables, > http_proxy, https_proxy, and ftp_proxy, to be recognized and used by the > networking implementation, by default. Daniel's previous investigation > has shown us that doing so is possible, but a larger effort than we > initially thought.
Sigh. > As Volker pointed out, the ( not enabled by default ) support for system > proxies was greatly improved in JDK 9, see 8170868 [1]. This was a > really nice contribution, which allows integration with the system > configured proxies on more platforms. Especially the update to the newer > GNOME version, so that system proxies work on relatively recent versions > of Ubuntu. Yes. On Linux we now use glib’s GProxyResolver, which on a system without GNOME itself installed (e.g., most servers) winds up reading the environment variables (`http_proxy`, etc.) via libproxy, so it just does the Right Thing -- if only you set `-Djava.net.useSystemProxies=true`. > It's a sad state of affairs that we still don't support system proxies > out-of-the-box by default, but maybe supporting the above three > environment variables, by default, is a more attractive route at this > point in time. Sad state, indeed. The URLConnection and HttpClient APIs already use the system’s default ProxySelector. What other APIs might require checking? Do we care about SOCKS proxies? (Are those in broad use? I have no idea.) Making every TCP connection check for a system default SOCKS proxy could be going too far in terms of compatibility impact, and anyway solving this problem for http, https, and ftp should address most of the pain. Perhaps this is more a matter of test clean-up than anything else. I’ll make this change and run some tests ... - Mark
