Please forgive my breaking up of this thread. I just joined the mailing list...

On Thu, 20 Dec 2007, Daniel Stenberg wrote:
> Right, if libproxy supports the same variables the same way, no current
> functionality would be lost...

That is our intention. You can see what we support on the IgnorePatterns page:
http://code.google.com/p/libproxy/wiki/IgnorePatterns

> But I would really not hit application developers with this in their heads.
> libcurl would all of a sudden scan around the system to figure out proxy
> details (and in the case it is a remote PAC, it would even have to actually
> fetch a remote file), details that it would need to search for every time you
> create/init a new libcurl handle to make a new request - just another reason
> it makes sense to do this outside of libcurl.

You should be able to do this without performance penalty as long as
you keep the pxProxyFactory object around. Within that object your
performance hit is only on the first request (and only when using WPAD
or PAC). For instance, the most performance intensive is using GGconf
+ WPAD + NetworkManager. We benchmark resolving 1000 URLs through
that chain in .2 seconds. That said, we are definitely willing to
work on any performance issues that you may find.

> If we would support this library within libcurl, I would still want an option
> that explicitly asks libcurl to attempt to autodetect a proxy to use, so that
> existing apps won't break or start behaving funnily.

This sounds entirely sensible to me. I'm sure I wouldn't want MY
library behaving differently. :)

Of course the drawback to this is that apps don't get the benefit
automatically (duh!).

Now, I'm just thinking out loud here, but doesn't checking envvar
constitute autodetecting a proxy? Aren't we just really adding more
*methods* to autodetect?

> Then also, if there are more than one proxy returned from libproxy, won't the
> app author want the ability to perhaps pick the one sh/she prefers most?
> That too would require further API fluff to get added to libcurl.

Yes, libproxy does return more than one proxy. However, it is
explictly NOT up to the user to pick the preferred proxy. Part of the
reason for this is that SysAdmins often deploy WPAD as client side
load balancing with failover. So proper behavior is ALWAYS to use the
proxies in the order of their return, stoping upon successful
transaction. You can see this on the HowTo page
(http://code.google.com/p/libproxy/wiki/HowTo) and in the header
comments (http://libproxy.googlecode.com/svn/trunk/src/lib/proxy.h).
Thus, no further API is needed.

Nathaniel
Received on 2007-12-21