On Dec 20, 2007 8:51 PM, Nathaniel McCallum <npmccallum_at_gmail.com> wrote:
> 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).

Of course, all this depends on a Javascript provider plugin actually
being installed (off by default, not in the core). Without a
Javascript plugin, autodetection is bypassed altogether. Thus,
without a Javascript plugin, performance should be near-parity with
"raw" libcurl.

Nathaniel
Received on 2007-12-21