The biggest problem with socket based proxies are their simplicity. It’s a bigger pain to write them once for all applications than to implement them for a single application. But that is if you don’t consider system wide and automatic configuration. So far, the result on Linux is that most desktop environments have global settings. Except the browsers, none of the applications use them.
A few months ago, I was asked to implement proxy support for Telepathy Gabble. While reading about socket based proxies, I asked myself why should Gabble cares about proxies ? It does not change anything in the way XMPP is being used. The only difference is at connection time. As GLib offers an abstraction to socket connections why GLib can’t take care of them ?
That’s why I started hacking on GLib to implement transparent proxies. I came up with a set of patches that can be found in my git tree.
The problem can be split in two:
- Which proxies should I use ?
- How do I connect through these proxy servers ?
The first problem is configuration. There is at least three types of proxy configuration. The network provided proxy WPAD (e.g. often through DHCP), the JavaScript configuration files (PAC) and the static configuration (e.g. system network configuration). This problem can be solved using LibProxy. While its name is a little generic, LibProxy only deals with proxy configuration. You give it an URI and it gives you back one or more proxy URIs.
The second problem is the connection. Some proxy protocols are dialects of other protocols. As those are very specific, it’s normal to leave to specialized library the task of handling them (e.g. libsoup will care of HTTP proxy). For other protocols like SOCKS, every application should support them. Currently, every application and library implements their own partial support for SOCKS and some just don’t. If you are lucky like me, you may end-up with Evolution not using SOCKS except when rendering emails external images because libsoup does support it.
Quickly the problem gets bigger and code more complicated. At some point, having this in a centralized library should help desktop applications to just work. But my idea has some limitations since we can’t force anyone from using BSD sockets directly. So far, I can only encourage maintainers to port over GIO, basing their code on a well tested network abstraction.