GNOME Bugzilla – Bug 343811
$http_proxy being set incorrectly by Network Proxy
Last modified: 2018-01-29 08:48:57 UTC
That bug has been opened on https://launchpad.net/distros/ubuntu/+source/control-center/+bug/48294 "If I have these settings in System -> Network Proxy, $http_proxy is being set incorrectly: [NOT SELECTED] Direct internet connection [NOT SELECTED] Manual proxy configuration HTTP proxy: sunhill, port: 3128 [SELECTED] Automatic proxy configuration Autoconfiguration URL: http://www.it.usyd.edu.au/proxy.pac Even though "Manual proxy configuration" is not selected and the text is greyed out as per the screenshot I will attach, the following happens when I open new terminals with those settings in place: $ echo $http_proxy http://sunhill:3128/ I know that $http_proxy can't be set from the autoconfiguration URL, but the GUI's use of radio buttons and greying out suggests that it should *not* fall back to the manual configuration to set $http_proxy, yet it does. (In my case this behaviour is not only counterintuitive but also an actual bug in and of itself -- that manual setting is left over from a previous network.) ... http://librarian.launchpad.net/3009530/network-screenshot.png Screenshot to confirm settings ... I've never used the "Manual proxy configuration", but I have set "Automatic proxy configuration". This is what my $http_proxy is set to: $ echo $http_proxy http://:8080/ Which is clearly wrong. "
gnome-terminal? I assume you meant control-center?
Argh, I wasted so much time thinking the musicbrainz server was just always broken because of this. Finally debugged it after much stracing of sound-juicer. (It would also help if sound-juicer/libmusicbrainz had good error reporting - "can't connect to http proxy x.y.z.a" dialog would have been helpful, vs. "can't send/receive to/from server" printed on the console.) The control center UI 100% definitely indicates that manual and auto proxy configuration are mutually exclusive. Which makes sense to me. I'd change the gconf schema or the way the schema is used in e.g. gnome-terminal, rather than the UI. But in any case, get them in sync... As a secondary bug, I don't think a sane GUI app like sound-juicer should pay any attention to this broken http_proxy environment variable. (broken since env variables can never be dynamically changed or properly reflected in the control center UI)
On further investigation the problem is not sound-juicer using the http_proxy env variable set by gnome-terminal - sound-juicer is looking at the gconf keys, but misinterprets them in the same way as gnome-terminal. Or is misled by control-center, depending on how it's intended to work.
I've also very recently started experiencing this with the latest 2.16.1 builds. I had the network proxy set to direct access, but for some reason gnome-terminal was offering $http_proxy according to the manual configuration setting. Removing the entries from the manual configuration fields cured the problem. It appears there are a couple of other bugs relating to reorganizing the proxy preferences (eg. bug 362596 and bug 322211). Has there been any progress with this bug?
Hmmm, scratch that, sorry. I'm no longer able to recreate the problem. It appears that the use_http_proxy setting must've gotten out of sync with what the control applet was showing. If it comes back, I'll try to make detailed recordings of the gconf settings and further track down what's causing the problem...
Gnome-terminal sets http_proxy.. moving back.
Isn't it easier to make control center unset the gconf key if manual is not selected?
You probably want to save the proxy in the manual section even when manual is disabled, otherwise if you toggle auto/manual you lose your proxy setting.
(In reply to comment #8) > You probably want to save the proxy in the manual section even when manual is > disabled, otherwise if you toggle auto/manual you lose your proxy setting. That's an implementation detail of control center too me. It can save it in another key when not selected...
If there is already a use_http_proxy boolean value, that should be (and I think even is) used to determine whether the proxy settings are used or not. I'm not certain how you discern the difference between using automatic settings and manual settings, though. Either way, it seemed very strange that my http_proxy variable was set, but that I couldn't find it linked into the profile or my .bashrc. Perhaps this feature will cause more confusion than aid? Or perhaps as has been suggested in bug 84315, it should be moved fully into gnome-session so that there is only a single interpretation of the proxy settings and they are applied to all subsequently launched programs?
If setting http_proxy env variable it might be nicer to do it in an /etc/profile.d script (using gconftool to get the settings). People will look in scripts to see where env variables come from, but it's surprising (and hard to fix) if the env variable is set by gnome-session or gnome-terminal.
That'd work nicely. Probably gnome-vfs should provide such a script, as it is the module that installs the gconf keys.
I have a problem that I think that can be also reported here. This was reproduced by a #gnome user, kenvandine, that was running 2.17.92. If you start a gnome-session with this Network Proxy Preferences: [NOT SELECTED] Direct Internet connection [SELECTED] Manual proxy configuration [NOT SELECTED] Automatic proxy configuration when you star gnome-terminal $http_proxy is set correctly, but if you enter the Network Proxy Prferences and change to this: [SELECTED] Direct Internet connection [NOT SELECTED] Manual proxy configuration [NOT SELECTED] Automatic proxy configuration gnome-terminal still sets the $http_proxy variable, even if gnome-terminal is restarted. If the session is started with Direct Internet connection I can change between Manual and Direct and the $http_proxy variable is set correct after restart the gnome-terminal.
Having gnome-session set the http_proxy environment variable is in fact broken. See the following example: - at session startup gnome is configured to use a proxy - gnome-session set the http_proxy variable and starts gnome-panel - some time later, the user changes the proxy configuration (because he moved on to another network), so that no proxy is used (direct) - all programs started by the panel and who first interpret the http_proxy env variable before looking at gconf keys will try to use the old proxy and will fail (this seems to be true for Evolution, Liferea, and probably some others) - there is no way for the user to get the right setting back, except killing the panel and have it restart It seems to me that no process supposed to run for a long time (gnome-session, gnome-panel, ...) should play with the http_proxy environment. This may be acceptable for gnome programs, if they are implemented to always have gconf keys override *_proxy env. variables, but all other non-gnome applications will be broken.
Sorry, please ignore the above comment: setting the http_proxy setting in gnome-session has been removed (commit February 27th). If there is still an issue, its then purely gnome-terminal issue. It seems acceptable that gnome-terminal sets theses environment variables: even though the changes to gconf settings made during after a shell is started won't impact this shell, the user could understand he has to start a new shell...
For me, this is not an issue anymore. I think removing the code from gnome-session which set the http_proxy environment variable was the solution.
In GNOME 2.18.0 I also don't see the problem with the http_proxy variable anymore.
This bug is still pretty much alive with recent gnome-terminal 2.18.1. For me the problem was getting http://:8080/ as proxy settings, while I'm using automatic configuration. This can easily be reproduced: - enable manual proxy settings - set the port to 8080 in settings for http proxy, having blank hostname - enable use of automatic proxy settings - restart gnome-terminal The bug basically is that gnome-terminal does not check the variable /system/proxy/mode at all in src/terminal-screen.c. You might have some invalid settings in the manual settings, and these are picked, whatever the mode is set to. This only goes wrong with automatic settings of course, since selecting no proxy sets /system/http_proxy/use_http_proxy to false, preventing misconfiguration. Suggested patch is quite simple: around line 1190 in above source file, check that /system/proxy/mode gconf key is set to manual and skip whole proxy settings code if the value is auto. The code should also check that host parameter is not NULL (no hostname was set in the settings), and ignore the settings if it is. This is just extra checking, not really necessary after the mode checking is fixed.
Created attachment 101950 [details] [review] Fix proxy detection More thorough checking, including checking that /system/proxy/mode is "manual" and not "automatic". Works for me.
Created attachment 111416 [details] [review] Alternate patch set http_proxy only if the mode is manual.
This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report.
*** Bug 405119 has been marked as a duplicate of this bug. ***