GNOME Bugzilla – Bug 596688
Expose more proxy settings
Last modified: 2010-03-30 21:12:29 UTC
Currently g-t sets http_proxy env var based on /system/http_proxy gconf setting. We can do more. CURL respects the following env vars: http_proxy [protocol://]<host>[:port] Sets the proxy server to use for HTTP. HTTPS_PROXY [protocol://]<host>[:port] Sets the proxy server to use for HTTPS. FTP_PROXY [protocol://]<host>[:port] Sets the proxy server to use for FTP. ALL_PROXY [protocol://]<host>[:port] Sets the proxy server to use if no protocol-specific proxy is set. NO_PROXY <comma-separated list of hosts> list of host names that shouldn’t go through any proxy. If set to a asterisk ’*’ only, it matches all hosts. wget understands: retr.c: proxy = opt.http_proxy ? opt.http_proxy : getenv ("http_proxy"); retr.c: proxy = opt.https_proxy ? opt.https_proxy : getenv ("https_proxy"); retr.c: proxy = opt.ftp_proxy ? opt.ftp_proxy : getenv ("ftp_proxy"); Looking at /system/http_proxy and /system/proxy gconf keys, we should be able to set most of those variables: HTTPS_PROXY, https_proxy -> /system/proxy/secure_{host,port} FTP_PROXY, ftp_proxy -> /system/proxy/ftp_{host,port} ALL_PROXY -> /system/socks_{host,port} /* THIS IS APPROXIMATE *? NO_PROXY -> /system/http_proxy/ignore_hosts One mismatch re how we do http_proxy is that we support username/password for /system/http_proxy but not for /system/proxy entries.
Also, not sure where autoconfig_url fits in.
Wget accepts "no_proxy" too, so it's just case difference.
there is work ongoing for wget to support libproxy. Then the entire proxy handling is abstracted by the library.
(In reply to comment #1) > Also, not sure where autoconfig_url fits in. This is an issue for most applications, as they do not bring their own javascript parser. Current implementation is to put pac+<pacurl> or wpad:// into http_proxy. Most apps fail on it more or less silently (wget less silently).
I've merged this to master now. We set both lowercase and uppercase envs, but NEVER overwrite an existing env var. commit ed365372429aaf5888aa0a8254f572eb93be26f2 Author: Behdad Esfahbod <behdad@behdad.org> Date: Fri Dec 11 09:42:44 2009 -0500 Support autoconfig http proxy Also part of Bug 596688 - Expose more proxy settings If /system/proxy/mode is set to auto, we put "pac+URL" into http_proxy where URL comes from /system/proxy/autoconfig_url. commit 3a4de6e4a71711b33e69f83dab5a8606d292e5cd Author: Behdad Esfahbod <behdad@behdad.org> Date: Fri Dec 11 09:38:46 2009 -0500 Set $all_proxy from socks proxy settings Last part of Bug 596688 - Expose more proxy settings (edit) commit cf6c5f76a5276a8d40d26ddb0528923e8d9f2f58 Author: Behdad Esfahbod <behdad@behdad.org> Date: Fri Dec 11 09:36:40 2009 -0500 Add https_proxy and ftp_proxy support Part of Bug 596688 - Expose more proxy settings commit d72c94ffd593a9835b53d83f918ee0a2fb8720ee Author: Behdad Esfahbod <behdad@behdad.org> Date: Fri Dec 11 09:20:24 2009 -0500 Prefetch proxy dirs commit 8ed799cfc115327926e99751f8aa74a4c1f22819 Author: Behdad Esfahbod <behdad@behdad.org> Date: Fri Dec 11 09:00:47 2009 -0500 Set both lowercase and uppercase $http_proxy and $no_proxy Part of Bug 596688 - Expose more proxy settings
(In reply to comment #5) > If /system/proxy/mode is set to auto, we put "pac+URL" into http_proxy > where URL comes from /system/proxy/autoconfig_url. Excuse my ignorance, but in which use case would that help? I can imagine two alternative implementations that would help in my case (= I have an autoconfig_url that points to a squid server, and I'm using my Internet connection directly when the server's down): If gnome-terminal actually downloaded the wpad file that is pointed by the autoconfig_url, executed the javascript function inside it, and exported *that* value in $http_proxy, then it would work with the current wget, curl and apt implementations. Or, if http_proxy wasn't exported _at all_ when autoconfig_url is used, then wget etc might still work on _some_ cases like mine, using the Internet connection directly. But now that no program (yet?) supports the pac+URL scheme, where does exporting it help?
I was going to send a note out to desktop-devel-list or my blog to see what people think. I probably just disable that for now.
Disabled autoconfig_url.
Please see https://bugs.launchpad.net/ubuntu/+source/libsoup2.4/+bug/433827 https://bugzilla.gnome.org/show_bug.cgi?id=603285 Summary: Exporting the pac+URL scheme (as gnome is currently doing, actually, from somewhere in gnome-session or something) causes every HTTP-using app that I can find to break horribly, usually with misleading error messages. Maybe we should fix all those apps and *then* export pac+URL in the environment. But then, the easiest way to fix the apps would be to port them to use libproxy, and then once they're using libproxy they'll ignore the environment variable and just read stuff from gconf (which is more correct anyway, because the user might change their proxy during runtime). So I'm not sure there is any value in exporting pac+URL.
*** Bug 425430 has been marked as a duplicate of this bug. ***
(In reply to comment #9) > Summary: Exporting the pac+URL scheme (as gnome is currently doing, actually, > from somewhere in gnome-session or something) causes every HTTP-using app that > I can find to break horribly, usually with misleading error messages. An Idea on this (I implemented a 'hack' for this on my system, as I'm using a pac file in thee office as well) Gnome already links into libproxy, which can be of great use here: Currently, gnome-terminal get's http_proxy set to what is set in gconf, in case of a pac file it sets pac+http:// in case of wpad nothing is done at all. Why not use libproxy and use the 'first' proxy returned in the array to fill in the variable? (of course in case of a .pac this is kind of blunt and not accurate, but in *most* cases still better than having pac+ which can't be interpreted by most apps). My *hack* on this currently is in .bashrc: pxy=$(proxy http://www.google.com | awk '{print $1}') if [ "$pxy" == "direct://" ] ; then pxy="" fi export http_proxy=$pxy export https_proxy=$http_proxy If this logic could be directly in gnome-terminal, I think that would be awesome. (proxy is the helper app of libproxy)