Hi,
On 25/09/2019 08:20, Alan Bateman wrote:
On 24/09/2019 23:47, mark.reinh...@oracle.com wrote:
Using network proxies with Java applications is still, after all these
years, painful on Linux.
Is there a reason not to change the default value of the system property
`java.net.useSystemProxies` [1] to `true`?
This is a problematic area, I think Daniel Fuchs looked into it recently
to see what should be changed.
When we where in the process of standardizing the HTTP client I did some
investigation to see if we could make the HTTP client more user friendly
for Docker applications. Namely I wanted whatever was defined in the
http_proxy env variables to be used by default, if no system property
was defined to override them. That's when I discovered that the
launcher on mac was explicitly setting system properties as a means
to enable the default system proxy - so there was no way to distinguish
whether those had been set by the user or not, and whether the env
variables should take precedence or not. I stopped my investigation
there.
One thing on Linux is that is that useSystemProxies will look for gconf
or GNOME configuration. That seems legacy now and the JDK should
probably be looking at the http_proxy and https_proxy env variables to
be consistent with other tools.
It's close to the issue I ran into.
I think the main issue with using system proxy configuration by default
is testing the JDK. The macOS port is the one case where system proxies
are used by default and it has been problematic to test when the proxy
configuration on tests systems isn't setup correctly (the equivalent of
noProxy in particular).
I have updated many of the networking tests to explicitly specify
openConnection(Proxy.NO_PROXY) in my effort with test stabilization,
though I suspect many still remains that don't do that - in particular
with tests in other area than networking that may use
URL.openConnection (JCK tests might need some updates too).
But on this front - we probably are in a better place now than
we used to be.
One other thing is that as far as I can tell the default system
proxy configuration used by the JDK (at least on my machine)
does not seem to recognize '::1' as an address that shouldn't
go through the proxy - so currently any http test that uses
the IPv6 loopback and runs on some machine where a proxy is
configured could end up failing with error 500 Bad Gateway
(which in part prompted my effort into updating tests to use
explicitly NO_PROXY).
This is something we should fix in the default proxy selector.
Though I'm not sure there's a unified syntax to do that.
Another part to this is to enumerates the APIs and features that that
could or should use the proxy configuration. The legacy URL protocol
handlers for sure but there are other areas that might need attention.
Yes.
-Alan
best regards,
-- daniel
