GNOME Bugzilla – Bug 684519
Cannot use HTTPS direct if HTTP proxy is set
Last modified: 2018-05-29 06:42:53 UTC
Setting an HTTP proxy but leaving HTTPS blank in gnome-control-center causes the glib-networking implementation of GProxyResolver to return the HTTP proxy for HTTPS connections, rather than "direct://" This makes it impossible to use a HTTP proxy and a direct connection for HTTPS, as is required by my organisation, thus making HTTPS unusable. In the short term, if there is a blank HTTPS proxy, no proxy should be used. In the long term, most other clients have a preference "Use HTTP proxy for all protocols" preference (but only really apply it to HTTPS and maybe FTP), which is really what is needed here.
Created attachment 224895 [details] Test program With glib-networking 2.33.14, running the test program results in the following: > mjg@montbard:~/tmp$ gsettings list-recursively | grep -i proxy > org.gnome.system.proxy mode 'manual' > org.gnome.system.proxy.http host 'www-proxy.cse.unsw.edu.au' > org.gnome.system.proxy.http port 3128 > org.gnome.system.proxy.https host '' > org.gnome.system.proxy.https port 0 > [snip] > mjg@montbard:~/tmp$ ./gproxy-resolver.py http://duckduckgo.com/?q=hello > http://www-proxy.cse.unsw.edu.au:3128 > mjg@montbard:~/tmp$ ./gproxy-resolver.py https://duckduckgo.com/?q=hello > http://www-proxy.cse.unsw.edu.au:3128 The last result should be "direct://".
(In reply to comment #0) > Setting an HTTP proxy but leaving HTTPS blank in gnome-control-center causes > the glib-networking implementation of GProxyResolver to return the HTTP proxy > for HTTPS connections, rather than "direct://" This is by design, and changing it would break existing users. There ought to be some way to specify that though.
If people are relying on that, it's understandable then. Perhaps a better short-term solution would be to add a "use-same-proxy" setting to the GNOME schema, by default set to true. Then have glib-networking look for this and if unset or set to true, retain the existing behaviour, else treat each protocol separately. This is an existing setting for this for my login, perhaps migrated from an old GConf value, so there's perhaps some precedent. > mjg@montbard:~$ gsettings list-recursively | grep -i use-same > org.gnome.system.proxy use-same-proxy false
This seems to be recent behavior, as libproxy would have return direct:// for https if an http proxy was set and not a secure one. I did some test Firefox and Chrome. Firefox, when using system setting, seems to respect this behaviors, though if you configure manually it behave the way Mike have described (but it supports the use_same_proxy). Chrome can only use system settings and behave the way Mike is expecting.
Mike, meanwhile, you can workaround this issue by using a PAC file. This way you can script the exact behavior you want.
From org.gnome.system.proxy.gschema.xml: If an http proxy is configured, but an https proxy is not, then the http proxy is also used for https. and <key name="use-same-proxy" type="b"> <default>true</default> <description> This key is not used, and should not be read or modified. </description> </key> IIRC, use-same-proxy was supposed to be for the case where you use the HTTP proxy for non-HTTP protocols, but we ended up not supporting that. (But we can't remove the key from the schema because that would be an ABI break because of how GSettings works.) There was never any way (in gsettings or in the old GConf schema) to specify that http should use a proxy but https shouldn't. At any rate, apparently some people have it set to true now and same have it set to false, so I'm not sure I'd want to suddenly start interpreting it as meaning something. We'd probably want a new key for that. Maybe /system/proxy/https/no-proxy or something. Alternatively, we could move the proxy settings again (ha ha) to get it properly namespaced (/org/gnome/something rather than /system) and fix things there...
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/glib/issues/608.
Reopening. This bug was migrated to https://gitlab.gnome.org/GNOME/glib, but it should have been migrated to https://gitlab.gnome.org/GNOME/glib-networking.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/glib-networking/issues/23.