HTTP proxy is used for non-HTTP protocols due to incorrect use-same-proxy default
@wjt
Submitted by Will Thompson Link to original bug (#739311)
Description
https://developer.gnome.org/gio/unstable/GProxyResolver.html#g-proxy-resolver-lookup is documented as follows:
If you don't know what network protocol is being used on the socket, you should use none as the URI protocol. In this case, the resolver might still return a generic proxy type (such as SOCKS), but would not return protocol-specific proxy types (such as http).
My proxy settings are as follows (real hostnames removed):
org.gnome.system.proxy autoconfig-url ''
org.gnome.system.proxy ignore-hosts ['.example.com', '.local', '127.0.0.1', 'localhost']
org.gnome.system.proxy mode 'manual'
org.gnome.system.proxy use-same-proxy true
org.gnome.system.proxy.ftp host 'webproxy.example.com'
org.gnome.system.proxy.ftp port 3128
org.gnome.system.proxy.http authentication-password ''
org.gnome.system.proxy.http authentication-user ''
org.gnome.system.proxy.http enabled false
org.gnome.system.proxy.http host 'webproxy.example.com'
org.gnome.system.proxy.http port 3128
org.gnome.system.proxy.http use-authentication false
org.gnome.system.proxy.https host 'webproxy.example.com'
org.gnome.system.proxy.https port 3128
org.gnome.system.proxy.socks host ''
org.gnome.system.proxy.socks port 0
I have no SOCKS proxy configured, so I would expect
g_proxy_resolver_lookup (g_proxy_resolver_get_default (), "socks://www.google.com/", NULL, NULL);
and
g_proxy_resolver_lookup (g_proxy_resolver_get_default (), "none://www.google.com/", NULL, NULL);
to return:
[ "direct://" ]
and certainly no HTTP proxies. But in fact it returns:
[ "http://webproxy.example.com:3128" ]
ie the configured HTTP proxy. This violates g_proxy_resolver_lookup()'s documented behaviour, and is wrong.
This behaviour is, as far as I can tell, caused by:
org.gnome.system.proxy use-same-proxy true
but GNOME 3.12's Control Center (I've not checked 3.14) does not expose any UI for that field: the inputs for all four of HTTP Proxy, HTTPS Proxy, FTP Proxy and Socks Host are sensitive, and there is no indication that by leaving the Socks Host field blank, the HTTP Proxy setting will be used.
I think this commit to gnome-control-center https://git.gnome.org/browse/gnome-control-center/commit/?id=3fd861b, which removed code setting use-same-proxy to false, caused this bug. This code was added in 3.1.91 to prevent AFAICT exactly this problem (bug 657235).
The key defaults to true https://git.gnome.org/browse/gsettings-desktop-schemas/tree/schemas/org.gnome.system.proxy.gschema.xml.in.in#n53 and has this documentation:
This key is not used, and should not be read or modified.
But it is read by glib-networking: https://git.gnome.org/browse/glib-networking/tree/proxy/gnome/gproxyresolvergnome.c#n271.
So, I guess I suggest one or more of the following, any of which on their own would have prevented this bug for me:
- change the default value for the use-same-proxy GSetting to 'false'.
- change glib-networking to ignore use-same-proxy, as its documentation advises.
- revert the above commit to gnome-control-center, so that it continues to explicitly set the field to false.
The first two feel cleaner, but they would both cause regressions for anyone accidentally depending on the current behaviour where the http proxy is used for https, which makes me lean towards the third option (hence filing this against gnome-control-center).
In my case the third option is mildly worse: we have organisation-wide dconf proxy settings so that no-one needs to set their own proxies up; that file will need to include use-same-proxy to false, since users will never (necessarily) fire up gnome-control-center.