gnome-control-center doesn't allow to specify proxy exceptions

Thank you for taking the time to report this bug and helping to make Ubuntu better. The issue you are reporting is an upstream one and it would be nice if somebody having it could send the bug to the developers of the software by following the instructions at https://wiki.ubuntu.com/Bugs/Upstream/GNOME. If you have done so, please tell us the number of the upstream bug (or the link), so we can add a bugwatch that will inform us about its status. Thanks in advance.

I have reported this bug to GNOME bugzilla,
https://bugzilla.gnome.org/show_bug.cgi?id=658570

Thank you for sending it to GNOME

I believe the wishlist Importance of this bug is incorrect as it represents a feature that was working/did exist and now it's been taken away.

This shouldn't be a whishlisty but a regression as the proxy exceptions were available in proxy settings before oneiric.

Agreed, the new Proxy code is vary lacking. I understand that there are some ppl who are great at designing and implementing APIs and Dialog(s), however they shouldn't trample over well tested code that is above there ability to support... What's a Fancy Plate with nothing on it?

We need to have these endeavors be driven by ppl who are well seasoned(as in Soy Sauce and Tabasko) in the given area, instead of spending time with making good looking pottery.

I have experience with network coding and am able to write code to talk to both Socks(several variants) and HTTP Proxy servers. Are there any others?

What troubles me is the decision tree that should be called every time a connection is requested. This Tree needs to include a state-full matrix for current connection status/location. There also needs to be a handful of optional arguments an application can pass for indicating many attributes of a connection. I'll attempt to list a few and try and highlight the ones that matter.

(UDP/TCP/SCTP 4/6/46/64) 46 is ip4 then ip6 and 64 is ip6 then ip4 note this effects DNS lookups, perhaps such that the system resolver is inadequate. Thus DNS servers and resolution should be part of each Network Profile.

Application Level Protocol * HTTP/FTP/SSH/CIFS...
Application(Presentation Level) * ncftp/lftp/wget/axel
Account *
Session (Optional?)

The proxy settings were working fine before, but the latest changes have caused nothing but grief. First was the issue of just finding the new proxy setting GUI, since searching for "proxy" from the launcher or in System Settings doesn't work. Then I've had to manually set the proxy settings for Apt. Pidgin and Empathy still don't work over a proxy for me. Now it's this issue with having to jump through hoops just to set exceptions. It's not even clear how are the changes supposed to be an improvement instead of just a regression. Ubuntu should not accept ill-considered changes from upstream. I won't be recommending Ubuntu to anyone anymore, since it can't be trusted no to regress long-standing and important functionality in recommended updates.

I don't seem to even have a manual workaround. gconf-editor and dconf-editor both seem to access similar (but not identical?) things, neither of which is the same as what I get with System Settings->Network->Network proxy (which is to say, I can
change the settings in any of the Ubuntu settings menu, dconf-editor, or gconf-editor, but the changes aren't always reflected in the other two, and only the Ubuntu menu seems to actually control what my web browser does.)

So, is there still a way to ignore hosts in 11.10 that works? I've tried changing settings, restarting the browser, restarting network manager, rebooting... and I still haven't found a way to make the web proxy ignore specific hosts.

This is also an issue in Debian and I've attempted to create a task force dedicated to assisting developers and packagers with maintaining stable proxy support.

However there is at least one person, with no objections other then myself, who believes that patches for proxy support should not be forced onto the developers and packagers.

I believe that proxy support should be a release goal(for some release after next) and failure to comply(that is to chose the best proxy patch and apply it.. or else) should result to being pushed out of main... into contrib perhaps.

http://lists.debian.org/debian-devel/2011/09/msg00425.html

A good start would be a bug database(perhaps a tag in launchpad and bugs.d.o) with perhaps a wiki that would outline the current status and issues with running behind a proxy. The main goal would help /new/ users in the trial and error department with a secondary goal to identify how much work would be involved and where assistance is needed.

I should point out that at this time I'm no-longer behind a proxy, however I am behind a NAT and this presents some of the same issues with regard to how to establish in-bound connections. One question is to decide is weather to include UPnP as a sort of proxy as it is a tool that applications interested in creating network sockets may need to be configured to use.

Is there any way that works? I am unable to access local/external networks simultaneously and it's quite frustrating. I am curious whether removing ignored_hosts configuration was a known design choice or an oversight.

Unfortunately proxy support is currently lacking and there will likely not be any solution.

From what I can tell proxy support was re-engendered and the new implementation is inadequate. It's unclear if there will be any further development and the previous implementation will likely not be re-implemented... that's my guess at least.

Well, being behind a proxy (workplace), this looks really ugly: applications that try to use system proxy settings (firefox, chromium, eclipse) fail to do so, access to the local mail and svn servers is channelled through the proxy and fails horribly, this change has made the distro unusable at work...

I would love to form a project/team/comity that would work with developers and package maintainers to address proxy issues and also maintain a minimum compliance specification. This task defiantly needs Linux Plumbers type endeavor.

I believe that proxy support needs to be a future release goal! However in order for this to flower it needs support from within the community! Currently me and a few other users have little chance of effecting any real change.

Any suggestions on how this effort can get some attention?

Wow, who is responsible for deciding that this regression should go in the Ubuntu/Gnome? We should not let them destroy the great distro/desktop by doing such obviously wrong decisions.

Replacement implementation should be used once it is feature complete, I think we could live with the old proxy for one more year or so.

For sure, and it's not like there is some one out there behind a bunch of proxies that would even begin to be able to test new proxy code. This really will take a community effort, not just some commit by some one who many not have ever used a proxy.

There surly is something wrong with the vetting process for this to have slipped in.

So... a comment about the lack of a vetting process is immediately followed by a fix with no explanation, nor any testing or user acceptance.

I don't think so, as stated there are plenty of Proxies in the world and I've recently discovered that proxy.pac files are vary much a part of corporate networks these days. I feel that the kernel/libc network stack may need to be adjusted long-term for proper proxy support.

However for the time being we will test your ignore list.

@Mike: could you explain why you changed the status to incomplete? that bug is about proxy exception which is being implemented upstream this cycle, if you need extra feature over that like smart .pac handling, consider opening a new ticket specifically about that request

The bug is incomplete because there has been no testing if the change implemented does either of these two things.

1. Does what the fix was intended to do.
2. Actually corrects the bug posted here.

Until there is some level of testing and user acceptance, the bug is not fixed. Because there is a lack of a better option Incomplete seems most appropriate.

So, what is the status on this ticket? Probably safe to close, right?