(due to some local mail problems of mine, I reply to Mohun's mail instead of
Nathaniel's original)

> Nathaniel McCallum wrote:

That's a nice summary of what we discussed so far indeed.

I've found very little motivation or reasons presented by anyone to move
forward to work on making libcurl use libproxy - those 8 points were all
issues in libproxy but there are a few additional ones that are reasons for
libcurl to not implement support for it. Including these:

   * There's just no way we can allow libproxy support enabled by default in
     libcurl so it will require clients to modify their code no matter what.
     So, why add it to libcurl when the apps can just as well just use libproxy
     when they're changing their code?

   * I have this feeling most libcurl apps authors aren't longing for this
     feature so they'll don't build with it enabled or won't enable it. This,
     and the fact that writing tests for various proxy config options is dead
     hard, will make it harder to become good and solid.

   * Failure in the proxy detection will end up causing funny results, and with
     things like PAC it needs to fetch things first to be able to fetch things
     so it'll give everyone a new level of support problems. I mean, apart from
     the potential performance problems.

If someone else provides a fine patch that allows libcurl to get built with
libproxy support I would be willing to consider applying it. Such an approach
pretty much must also introduce something that allows libcurl users to re-use
the proxy information comfortably between requests with fresh handles, which
probably could be made by allowing the share object be able to hold proxy info
or similar.

I am however very interested in making curl the command line tool use it - if
built with support, but that's not really a subject for this mailing list. I'm
not exactly sure when I'll start working on that, but I hope to do it soon.

-- 
  Commercial curl and libcurl Technical Support: http://haxx.se/curl.html