don't export http_proxy when there is no host defined

Oh, this is in gnome-network-preferences, if that was unclear.

I've found that _disabled_ proxy entires still show up in the environment too. :)

I don't see any way to explicitly disable a proxy entry, other than leaving the field blank. What do you mean by disabled? That if you define proxies and then choose "direct internet connection" it still sets the environment variables?

I don't have that problem on feisty, what value did you configure for the differents entries from the proxy dialog?

All blank; I set only a socks host.

marking unconfirmed, that works fine on my desktop, maybe it has been fixed on feisty

It seems that it does not, I'm on feisty.

Sebastien, did you remember to start a new gnome-terminal tab or window after changing this setting? It doesn't take effect on existing shells.

I closed every instance of the program when changing a value, there is no http_proxy set when the filed are blank

I just checked this with a fresh/clean install of edgy, and the problem is there; the problem remains after a dist-upgrade to feisty.

Maybe your steps to trigger it are not clear then, could you describe what you do from a fresh account, something like:
* open the dialog
* click on manual proxy config
* enter an IP to one of the entry
* close the dialog
* start a command line
* echo $http_proxy

That series of steps is precisely what I do. The only thing I can add to that, is that for "enter an IP to one of the entry" I specifically enter 127.0.0.1 to the socks host, and I also enter a port (12345) for it. "Use the same proxy for all protocols" is left at the default of unchecked.

I'm seeing an issue, that if the proxy is set ("manual proxy configuration") on bootup, changes to the proxy-settings are ignored.
If the proxy is set to "Direct internet connection" on bootup spawned terminals obey the settings set at the time they are spawned (as expected).
Looking at the code for gnome-terminal I suspect that http_proxy is set as an environment variable, in which case it will always use that.
This is reinforced, by booting with proxy on, starting a terminal, running "unset http_proxy" and then spawning a new terminal with "gnome-terminal" - this new terminal obeys the proxy settings from the control center.

Is this the same issue you are seeing?

Investigating further, I think the bug is in gnome-session which have had some changes to set the http_proxy environment variable according to the gconf settings - this however interferes with gnome-terminal's idea that if the environment variable is set it should obey this.

The root of the problem is that gnome-session assumes the proxy settings to be constant during the session (because the environment is inherited by child processes, and cannot be changed), which is not true.
Maybe these changes should be backed out of gnome-session, as gnome-terminal already handles it?
Also see gnome bug #84315

Attached patch is preliminary fix (disables proxy env. var. setting).
Also filed in gnome bugzilla, bug #398140.

I have no problem with the way it's handled now, *except* that the env. var. should not be set if the setting in control center is not set. I don't understand what interaction there may be with gnome-session; as far as I can tell it's just a problem with control-center's network proxy applet setting the gconf key /system/http_proxy/use_http_proxy to true when no value has been filled in for /system/http_proxy/host. Or, it's with gnome-terminal, setting the env. var. even when /system/http_proxy/host is empty. (I'd lean towards the former)

Alex: The interaction with gnome-session is that gnome-session sets the env. var. according to gconf, and this setting is then inherited by all other apps in the session, see pstree:
     │ └─gnome-session─┬─Xgl
     │ ├─beagle-search───2*[{beagle-search}]
     │ ├─evolution-alarm───2*[{evolution-alarm}]
     │ ├─gnome-cups-icon
     │ ├─gnome-panel
     │ ├─nautilus
     │ ├─nm-applet
     │ ├─2*[ssh-agent]
     │ ├─update-notifier
     │ └─{gnome-session}

For example gnome-terminal sees the env. var. as overruling the gconf values, and thus stops obeying changes to the gconf settings for the duration of the session.

Gnome-session does _NOT_ set the env. var. if "use_http_proxy" is not set. The problem is that gnome-session is only able to check _once_ at startup, and this setting is then inherited and overruling.

Alex, do you have "8080" as port number for http to the dialog? I tried again and without an IP nor a port there is no http_proxy variable set on my feisty desktop

Yes, I did. 8080 was the default value; I assumed it would be ignored if the host was left blank. Further, using gconf-editor's "unset key" action on /system/http_proxy/port sets it back to 8080

Through the applet I cannot completely unset the port. It gets set to 0 if I blank it out (and the gconf key /system/http_proxy/use_http_proxy stays set)

So presumably either this applet should be changed to default to 0; or other things (gnome-session?) should ignore the [other] settings for http_proxy if the host is blank; or the the applet should unset the key /system/http_proxy/use_http_proxy if the host is blank, and whatever sets the environment variable should read the key /system/http_proxy/use_http_proxy instead of using /system/http_proxy/host and /system/http_proxy/port.

Forwarded upstream to http://bugzilla.gnome.org/show_bug.cgi?id=405119

This is relevant for Bug #78098.

This is relevant for Bug #219227.
Please ignore my last comment.

Thanks for your bug report but this appears to be fixed on Hardy. Feel free to reopen this bug if the bug still exists.