On Dec 20, 2007 9:34 PM, Dan Fandrich <dan_at_coneharvesters.com> wrote:
> 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.

Wow... do you work for the government? ;)

The RFC does not require making a fresh DHCP connection. It specifies
that the URL for the PAC *may* be contained in DHCP option 252. It is
up to the implementation to figure out how to get that option. The
DHCP and SLP techniques are optional according to the RFC and I may
never implement them (they are not currently implemented). If I were
to implement DHCP, I would NOT make a new DHCP request, but instead
search the existing dhcp lease on the system.

Therefore, we are at DNS. Currently, the code doesn't have a FULL DNS
solution, but the most common deployments are implemented. This is
mainly wpad.$domain, with no traversing.

Thus, the current worst case scenario is one DNS blackhole or one HTTP timeout.

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

All apps get this functionality for FREE with libproxy because all
configuration is managed in a consistant way. Don't want
autodetection? Set your proxy settings to "None" in the GNOME proxy
preferences (or KDE's or a config file or an environmental variable).
Thus, such a user will never have to suffer: he/she can just disable
autodetection (which may or may not be on by default anyway, it
depends on GNOME, KDE, etc).

Don't we want to optimize for the most common case? The most common
case is that a user with a fine network can't see anything because he
doesn't know what proxy to use.

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

I'm sure I will! I'm happy to work with someone on a patch. :) The
learning curve for libproxy is minimal compared to libcurl (we only
have 3 functions). This is why we are trying to push upstream people
to write patches.

Nathaniel
Received on 2007-12-21