GNOME Bugzilla – Bug 603285
support newer libproxy
Last modified: 2010-11-18 17:29:57 UTC
I'm using Ubuntu 9.10 and my libsoup-gnome2.4-1 version is 2.28.1-2. I've set up my proxy to "Automatic proxy configuration", with an autoconfiguration URL of "http://server/wpad.dat". The problem is that running `echo $http_proxy` in a terminal shows "pac+http://server/wpad.dat", with an extra "pac+" in front of that. I don't know which program outputs this $http_proxy variable to the environment, but now apt, wget, curl etc are unable to download anything from the Internet. I downloaded the libsoup sources, and modified "pac+" to "pac+debug-" in libsoup/soup-proxy-resolver-gnome.c: } else if (proxy_mode == SOUP_PROXY_RESOLVER_GNOME_MODE_AUTO) { char *autoconfig_url; autoconfig_url = gconf_client_get_string ( gconf_client, SOUP_GCONF_PROXY_AUTOCONFIG_URL, NULL); if (autoconfig_url && !strncmp (autoconfig_url, "http", 4)) http_proxy = g_strconcat ("pac+debug-", autoconfig_url, NULL); After installing this modified package, `echo $http_proxy` shows "pac+debug-http://server/wpad.dat". So that "pac+" I see in the $http_proxy variable originates from libsoup. Is that "pac+" supposed to be exposed via the API? If so, I should probably be looking for the program that misuses it and exports it to the environment. If not, please fix it! :-) Thanks!
this would break at least curl and wget anyway though, since they don't support PAC, so even if it set it to "http://server/wpad.dat", curl and wget would try to use "server" as the proxy server rather than downloading wpad.dat from it
I would argue that setting 'http_proxy' to anything but a host name (possibly prefixed with http://) is a breakage against how this environment variable has been used since a long time ago. I would argue that anything that wants to do "pac" support should need another environment variable for that purpose.
right, but my question was more, if you actually need to be using PAC, then isn't it the case that there is no possible value for the $http_proxy environment variable that would allow curl/wget/etc to work? Eg, if you set http_proxy=http://server/wpad.dat, then curl will try to use port 80 on server as an HTTP proxy, which presumably will not actually work. The $http_proxy leakage from libsoup is necessary to work around a crasher in libproxy, and is difficult to avoid, so I'm trying to understand the scope of the problem. "curl fails with error message X when it ought to be failing with error message Y" is not a big deal. OTOH, if curl would (somehow) actually be succeeding in this setup if libsoup wasn't leaking the broken http_proxy variable, then that's more important to fix.
I don't have any big emotions attached to what I said. I just quietly think that http_proxy is used to specify a host name for a HTTP proxy and you're not doing that in this case. I agree that if someone actually NEED pac then using a different variable won't help the least to get trough the correct proxy with the tools that don't understand pac (but relies on http_proxy). So no, changing that wouldn't fix anything for the tools for which this was initially brought up.
The desired behavior for me would be one of the following: a) If APT etc somehow actually supported pac. b) If something (libsoup?) downloaded the http://server/wpad.dat file and exported the proxy that was INSIDE that file to $http_proxy. I mean, resolving before exporting. c) If $http_proxy wasn't exported at all to the environment, APT would still work for me using my internet connection directly even if it didn't go through my apt-proxy or my squid etc. After all, one advantage to using wpad is that the clients may still work even when the server is down.
hm... gnome-terminal just got modified to do this on purpose: 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.
so, libproxy 0.4 fixes the crashes. so we can fix libsoup to check the libproxy version at build time, and have the evil code inside #ifdef HAVE_LIBPROXY_0_3. 2.30 is in hard freeze right now, but this could happen for 2.30.1. (especially if someone else wrote a correct patch. :)
fixed in master: with libproxy 0.3 or later, it won't touch your environment