Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Add libproxy support #977
This adds optional support for using libproxy to determine which proxy to use for a given URL.
The PacRunner dæmon provides a service where you can simply ask it, over D-Bus, which proxy to use for a given URL. Not only does it have a plugin for the original libproxy, but it also provides its own replacement libproxy implementation which does nothing but field the call to PacRunner.
I am mentoring a Google Summer of Code project this year which is fixing NetworkManager to pick up proxy information from DHCP, VPN servers and other sources, and to allow it to be an explicit part of per-network configuration — and to poke it into PacRunner appropriately.
Thus the expectation will be that asking libproxy should consistently give correct answers. Once that's true, I hope to change Linux distribution packaging guidelines to suggest that packaged applications should be using libproxy's results (or at least PacRunner's results) by default.
This implements libproxy support for curl because it seems like the more generic option, rather than talking to PacRunner directly over D-Bus. This is just the basic functionality; we need to look at how we make it accessible from the curl command line tool, and/or enable it by default.
I've updated the patch slightly to pass all tests: 0001-proxy-add-libproxy-support.patch
I'm a concerned about:
Apologies for the delay; I've been deep down the rathole of #974 (and will post an update there shortly).
Hm? libproxy has had that API basically forever (December 2007 AFAICT, before they even set the licensing such that people could actually use it). The only real changes to the file since then have been to the documentation, which (such as it is) resides therein.
Even when its soname changed from
We even have other projects providing their own reimplementation of it, using precisely the same API: http://git.kernel.org/cgit/network/connman/pacrunner.git/tree/libproxy?id=HEAD
Good point. The intent in libproxy, AIUI, is to be cross-platform. Even on platforms which typically have a single consistent location for proxy information, such as Windows, there's still benefit to something like curl, to being able to just use a simple cross-platform API for getting the information from wherever it comes from.
For Windows I think it's a bug that it requires the caller to free the data, for precisely the reasons you state. I've filed libproxy/libproxy#43 — ironically asking for a change (well, an addition) to that API that I've just said has been stable for almost a decade... :)
You really want that to be global; it's the libproxy state where it goes off and finds the PAC file via DHCP or WPAD or whatever, and loads a JS interpreter to handle it. It's bad enough that in the original libproxy implementation you get that JS interpreter in the context of every process (that's what PacRunner fixes, and gives you just a simple DBus query). But you certainly don't want a new one for every curl easy-handle!