Okay we need some resolution on this-- is it a Brainstorm item or Bugzilla candidate? If the former, a proposal needs to be created and linked. If the latter, then a bug should be opened (or possibly expanded/voted if an existing one is applicable).

I will be more than happy to help either way.

Sure, let me rephrase that to "limited to a small set of pre-defined ports". Otherwise it may be transparent for the applications but becomes a huge hassle for the user.

Another problem is that too much transparency can be a bad thing. What do you do if you want to access a non-HTTP service on port 80 (recent example)?

Brainstorm, probably, but there's no harm in discussing it a bit more first :-)

I would like to generalise this a bit to a solution for all HTTP-speaking applications to support HTTP properly. If you look at bugzilla, most apps that do HTTP (eg RSS reader, media player, application manager) have the same types of bugs filed against them:

• app doesn't obey proxy settings
• app doesn't support HTTP authentication
• app doesn't support HTTPS

plus a few less frequently occuring ones like handling of HTTP redirects.

In my mind the right solution would involve a high-level HTTP library that all apps[1] would be encouraged[2] to use. It should support HTTP/1.1 fully, notice proxy setting changes automatically (including exceptions), use the built-in certificate store for SSL/TLS, and in a perfect world also support proxy autoconfig[3]. Oh, and it should be language- and toolkit-independent.

[1] including some non-HTTP ones that could use CONNECT through an HTTP proxy (for example Jabber or IRC)
[2] exercise left to the reader ;-)
[3] this requires a javascript engine so decidedly non-trivial

It's a bug. There's an API which applications are supposed to use for the proxy (e.g. gconf's /system/proxy/mode or libconic's con_ic_connection_get_proxy_mode).

There are four possible bug types:

1. System doesn't set http_proxy environment variable for newly launched processes. (Haven't checked)
2. Built-in application doesn't respect proxy settings (such as #3712)
3. Third-party application doesn't respect proxy settings
4. Application using non-HTTP traffic can't use SOCKS proxy or other tunnelling technique.

If there wants to be a generic technical solution to #4, I don't think Brainstorm's race-to-mediocrity and the inexperience-of-crowds will come up with a good technical solution. Perhaps maemo-developers would actually be better?

Well, for [1] and [2], at least, there's libcurl (http://curl.haxx.se/libcurl/) which several applications already use.

I really appreciate all the suggestions stated here.I am not a programmer. but i would like to help with. anything i can do because this bug/issue is affecting me and many other users who live behind network proxies greatly. right now on my n900 only the web browser respects the systemwide proxy. i am unable to use any other internet awared application because they simiply wont work (all the gpodder, mauku, omweather, internet radio, gtalkl, just name it) if it connect to the inernet it doesnt work. because for some reasons the applications have not been programed to use the systemwide proxy. It would help greatly if some of the problems, bugs and proposal stated here can be looked into and a working solution pushed into maemo.