On Dec 20, 2007 8:18 PM, Dan Fandrich <dan_at_coneharvesters.com> wrote:
> On Thu, Dec 20, 2007 at 08:01:35PM -0500, Nathaniel McCallum wrote:
> > Idealy, curl should be able to exhibit the correct behavior by
> > default, rather than a "--make-it-work-correctly" option.
>
> The problem is that in a worst-case scenario, it could take on the order of
> minutes to try to autodetect a proxy, even in situations where no proxy
> is even needed. That's a pretty big backwards compatibility issue.

Currently, an autodetection taking "minutes" is not possible. I'm not
sure it will ever be. This is how WPAD works:
1. Examine the already-on-disk dhcp lease for the PAC
2. Ask for a SRV record for the domain (1 DNS request)
3. Check wpad.site.company.com, then wpad.company.com. (N-1 DNS
requests, where N is the number of periods in your domain)

Under a normal functioning network, detection should be <1sec. It
might balloon larger than that if a firewall drops packets silently or
if you are on an incredibly high-latency connection (Mars rover
anyone?). But in the vast majority of cases, autodetection is a
not-too-expensive operation the first time (faster than HTTP GET of a
remote URL) and a fast operation subsequent times (magnitudes faster
than actual HTTP GET time).

> The other libcurl issue to consider is cross-platform compatibility. If
> libcurl rips out its environment variable handling code and hands that
> responsibility to libproxy, that means auto proxy support is no longer
> available on any platform on which libproxy is not available.

Of course, I'm definitely not asking you to do that (at least yet ;)
). We definitely want cross-platform compatibility in libproxy. But
it is chicken and egg. Someone has to have a reason to want the
functionality to port it to a different OS. :)

> > Depending on libproxy means you commit to depending on a >=35K core,
> > not on the plugins. Users/admins/distros can then make the call for
> > expanded functionality. In any case, libcurl has to do nothing, all
> > such extra functionality is free.
>
> That's not so bad, then, but I still think it should be off by default.

IMHO, "enablement" should be compile-time. If libwpad is compiled in,
it is on by default. If not, it is off (obviously).

Here is what I propose:
1. Make libcurl/curl work with libproxy, but disabled at compile-time
by default.
2. Test the snot out of it.
3. Make sure libproxy has cross-platform parity with libcurl.
4. Enable libproxy by default at compile-time ONLY if there are no
regressions (still can be disabled at compile time).
5. After it is just accepted and widely used, we can re-evaluate
pulling old/dead proxy handling code (if no one uses it).

That plan seems pretty low risk to me. No?

Nathaniel
Received on 2007-12-21