If you open gnome-network-properties and setup your proxy accordingly you would notice that most network applications don’t really work. There are several reasons for that.
Since as long as I can remember I have looked for a way to add proxy support on my applications. There has been a number of network libraries, none of which have ever fitted the bill for me. Finally, came GIO, now part of GLib, which has many advantages (although IMO not ideal; it works perfectly). Unfortunately, no proxy support.
There’s also libproxy, which one might think has proxy support, but it doesn’t; it merely provides a mechanism to find proxy configuration. This is good, but not the full picture.
But since GIO has plug-ins, it might be possible to provide proxy support transparently, with the help of libproxy… right? That’s where GLib networking comes. Great! So we have everything we need.
You can read the full debate on Ubuntu’s bug report for Empathy. There are two major obstacles.
1) GLib developers don’t want HTTP Connect to work seamlessly
2) libproxy developers have changed their opinion on that GConf values mean
Let’s start with the first. AFAICR GLib developers said; well, libproxy plugins cannot have a backup method, so if you specify a global HTTP Connect proxy, applications would try to use it, then fail, and do nothing else; instead, they should try the direct method as a fallback.
While that’s true, the fact of the matter is that *today* all applications fail anyway! First implement the main case, then worry about the fall-back!
But I guess for GLib developers everything has to be perfect the first time, even if this is not GLib, but GLib networking. If you want HTTP Connect support, implement it yourself, GLib won’t help you. Fortunately, that’s what people do already anyway.
The idea of libproxy sounded great; you have a single library that has all you need to get the proxy configuration: GConf, KDE settings, a personal configuration file, or even environment variables.
Except that at some point they decided that a personal configuration file was too difficult to maintain, and they decided to interpret GConf settings differently. So now libproxy is basically useless.
Yes, if you open gnome-network-properties, select “Manual proxy configuration”, “Use the same proxy for all protocols”, and input your “HTTP proxy”, libproxy will assume you are using a socks proxy. Stupid.
I discussed this with a libproxy developer. Before, you could have HTTP Connect for all protocols, and socks also for all protocols, but now, HTTP Connect for all protocols is not possible. Now, only socks for all protocols work, not HTTP Connect. Their answer; people don’t use HTTP Connect anyway.
Again, nonsense; most people use HTTP Connect.
So, what if you are like me; behind an HTTP Connect proxy? Well, you use Pidgin, or something not-GNOME that implements proxy support by themselves.
Or you do like me.
After getting the latest glib, glib-networking, telepathy-glib, and telepathy-gabble (which implements HTTP Connect by themselves), you would still have the problem that libproxy will interpret GConf wrongly. That’s why I wrote libproxy-simple.
Just clone it, build it:
make prefix=/opt/libproxy-simple install
And run telepathy-gabble with the right LD_LIBRARY_PATH:
LD_LIBRARY_PATH=/opt/libproxy-simple/lib GABBLE_PERSIST=1 /opt/gabble/libexec/telepathy-gabble
That’s it, libproxy-simple would emulate the full-blown libproxy, but instead to something useful; parse the GConf settings properly.
I also implemented libproxy support in XChat, which will probably be available in the next version 2.8.10. Just use the same trick (LD_LIBRARY_PATH=/opt/libproxy-simple/lib) and it will automatically pick the right proxy from GConf.
What about other programs? Well, unfortunately my workaround is only useful for 2), that means if the application already has proxy support, but it’s not getting the right configuration, then the LD_LIBRARY_PATH trick would help. Otherwise, you would are out of luck