On Thu, Dec 20, 2007 at 08:51:07PM -0500, Nathaniel McCallum wrote:
> Currently, an autodetection taking "minutes" is not possible. I'm not

Give me a PC and NIST Net and I'll bet I could show you a delay of an
hour or two :^)

> 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)

A worst-case scenario would involve having no PAC record therefore requiring
a new DHCP request, a DHCP server with a slow RADIUS connection, a
lossy DHCP gateway, fallback to SLP, multiple DNS servers, all but the
last DNS server black-holed, high-latency/lossy DNS, several levels
in the domain name hierarchy to check for WPAD records, multiple HTTP
redirections, high latency HTTP server.

I did say worst-case after all, but if even a fraction of the things that
could go wrong do go wrong, it could still add up to a noticable delay.
A script callig the curl command-line tool several times would
necessarily see that delay multiple times. And yes, I did make some of
assumptions about how libpac works in the example above that might not be
true since I haven't looked at the code (does it do its own DHCP
request?); several of the sources of the delay could be worked around
with intelligent timeouts, at the risk of allowing autodetection to fail
on some legitimate but marginal networks.

But, of course, the end result is that a connection might be able to be
made that wouldn't have otherwise.

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

But we shoudn't force the poor user behind that network above to suffer,
even when running an app that doesn't provide its own way to turn off this new
libcurl option.

> 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?

Sounds reasonable; I'm sure patches would be welcome :^) You'll definitely
have fun with #3, BTW.

>>> Dan

-- 
http://www.MoveAnnouncer.com              The web change of address service
          Let webmasters know that your web site has moved