On Mon, 26 Jan 2009, A. Craig West wrote:

>> PAC is javascript and we've been down this road before. Getting such an
>> interpreter into libcurl is not an option, that should be left for the app
>> that uses libcurl.
>
> I was thinking something along the lines of adding in optional support for
> the pacparser library ( http://code.google.com/p/pacparser/ ), as I believe
> it does just about everything we need. That way, we don't need to deal with
> the javascript parsing ourselves. If the person building the library has
> pacparser installed and enabled, we just use it, like how we use other third
> party libraries like the openssl stuff.

I'm far from convinced about the goodness of something like that. Sure, adding
a dependency on another lib can be good but no matter what it adds to the code
and maintainability and people will expect it to remain working etc.

I can't but to remain in the position that figuring out the proxy is a job for
the outside. libcurl uses what the outside tells it.

> We could certainly leave it out, but it would greatly simplify some of the
> proxy configuration issues we are dealing with now.

Would it really? I can't see how it simplifies anything. It'd add a lot of
code for the glue layer.

> Redirects are one example where having the user do the pac parsing
> separately would be cumbersome, as they would be forced to manually deal
> with the redirect if the redirected site needed a different proxy than the
> original site.

Yes, you'd do the redirect logic yourself but with modern libcurl that is
about three to five lines of additional code to get the new url and set it,
and then you can do whatever magic you think is necessary before the next
request.

I think as a general rule that whenever it starts to feel like something is
getting clumsy or complicated when we think of things to do between requests
when libcurl follows locations, then we should consider just leaving it for
the app to deal with completely.

> Even given something like pacparser, we will probably need some way to have
> authentication information stored on a per-proxy basis. Do we currently have
> a way of storing authentication per-site, in some type of external file? It
> seems like a useful thing to do...

Nope, neither concept exist today the way I think you mean.

-- 
  / daniel.haxx.se