libpurple should use libproxy

[kipple]

libproxy is an open-source library that provides functions to manage proxy configurations uniformly across applications and user sessions. Linking to libproxy would ensure Piding has access to the correct proxy at any time.

For more information, the libproxy website is http://libproxy.googlecode.com.

[rekkanoryo]

Note that libproxy is wildly deficient currently; this has been discussed at least twice. It is missing at least the ability to determine the type of proxy.

[npmccallum]

libproxy DOES have the ability to determine the type of proxy. If there is a specific problem, please report where you are seeing the problem in our bug tracker.

[felipec]

Replying to rekkanoryo:

Note that libproxy is wildly deficient currently; this has been discussed at least twice. It is missing at least the ability to determine the type of proxy.

Care to mention what is missing?

If you read *any* libproxy documentation you would find:

• The format of the returned proxy strings are as follows:
• - http://[username:password@]proxy:port
• - socks://[username:password@]proxy:port
• - socks5://[username:password@]proxy:port
• - socks4://[username:password@]proxy:port
• - <procotol>://[username:password@]proxy:port
• - direct://

[rlaager]

That seems reasonable to me. I reiterate, "patches welcome".

[datallah]

The situation has apparently improved in the past 3 years, this looks like it might now be a reasonable option for an additional proxy type (potentially even to replace the current "Environment" selection).

That said, it actually isn't clear whether or not libproxy is even reasonable to use with something like Pidgin that does direct TCP/IP communication of arbitrary protocols - the API which does the proxy lookup requires a URL that you're connecting to. What would that be for our cases that aren't http connections? Would "xmpp://talk.google.com" be reasonably expected to work?

Assuming the above isn't a problem, implementing this would require API changes (major version bump) because all proxy lookups need to made in the context of a specific host to connect to and the current API doesn't allow for that.

[felipec]

Replying to datallah:

That said, it actually isn't clear whether or not libproxy is even reasonable to use with something like Pidgin that does direct TCP/IP communication of arbitrary protocols - the API which does the proxy lookup requires a URL that you're connecting to. What would that be for our cases that aren't http connections? Would "xmpp://talk.google.com" be reasonably expected to work?

Of course that would work, how do you think people use libproxy?

[datallah]

Replying to felipec:

Replying to datallah:

That said, it actually isn't clear whether or not libproxy is even reasonable to use with something like Pidgin that does direct TCP/IP communication of arbitrary protocols - the API which does the proxy lookup requires a URL that you're connecting to. What would that be for our cases that aren't http connections? Would "xmpp://talk.google.com" be reasonably expected to work?

Of course that would work, how do you think people use libproxy?

Why "of course"? "Of course" theoretically it could work, but I would imagine that most networks that use a PAC file wouldn't work right with such a URL (the one that I have access to doesn't). There also aren't necessarily standard schemes for every network connection that we make - what scheme would you use for e.g. a direct file transfer connection?

A correctly written PAC file probably should work for unrecognized schemes, but my gut says there will be lots of support requests from people whose stuff suddenly breaks.

All of the examples listed on the libproxy wiki of people using it are http or http-like stuff based as far as I can tell.

None of this is to say that using libproxy isn't a good idea, but it requires investigation of things of this nature.

[npmccallum]

Some clarity might help here.

libproxy uses the URL format for two reasons: 1. PAC files require the URL form 2. Some OSes provide multiple proxy configuration options for different protocols (http/https/socks/gopher/etc).

In the first case you are at the mercy of the PAC file. If your PAC file doesn't know how to return the proper proxy for non-http URLs, then there is a bug in your PAC file. This is not a libproxy bug, it is by design.

In the second case, if we do not find a protocol match we fall back on http and then socks.

In short, using libproxy with "xmpp://talk.google.com" will provide the correct behavior in the second case and, so long as you have a properly written PAC file, the first case.

I'd also like to point out that we (libproxy) are very easy to work with. We close bugs quickly and answer questions as best as we can. If you find any problems or just have a few questions, don't hesitate to contact us.

[rekkanoryo]

For an additional point of clarification, libproxy does nothing but tell the application what proxy to use, correct? That is, libproxy doesn't actually connect to a given host via the proxy, and only tells the application what proxy server to use? That would mean we still need to maintain code to connect through proxies, which means using libproxy isn't as helpful to us as everyone seems to think it is.

(I'm not saying it's not worth supporting libproxy--I'm just pointing out it's not a magic cure-all to solve our quintillion proxy problems like some people seem to think it is.)

[felipec]

Replying to rekkanoryo:

For an additional point of clarification, libproxy does nothing but tell the application what proxy to use, correct? That is, libproxy doesn't actually connect to a given host via the proxy, and only tells the application what proxy server to use? That would mean we still need to maintain code to connect through proxies, which means using libproxy isn't as helpful to us as everyone seems to think it is.

I don't think anybody assumed otherwise. Just having the right proxy configuration is useful. You would get rid of issue #10122 for starters.

(I'm not saying it's not worth supporting libproxy--I'm just pointing out it's not a magic cure-all to solve our quintillion proxy problems like some people seem to think it is.)

I don't know what is that "some people".

The magic solution would be to use GIO, which will utilize libproxy behind the curtains, but that's a distant reality and unrelated to this ticket.

[npmccallum]

That is correct, the scope of libproxy is just configuration. Proxy support is protocol specific and, as such, the proper place for proxy connectivity code is in (either): 1. A networking library (ie. libgnet, gio) for socket level proxy 2. A protocol library (ie. libsoup, libpurple, etc.) for protocol level proxy 3. An application only when using one of the above libraries is unacceptable

I thus suspect that libpurple *is* the proper place for libproxy support since you deal with a variety of protocols and you can fall back to socket level proxy.