Most systems support manually configuring a proxy for web access, but this is cumbersome and kind of technical, so Chrome also supports WPAD for proxy configuration (enabled if “automatically detect proxy settings” is enabled on Windows).
Currently, WPAD is pretty slow when we‘re starting up Chrome - we have to query the local network for WPAD servers using DNS (and maybe NetBIOS), and we wait all the way until the resolver timeout before we try sending any HTTP requests if there’s no WPAD server. This is a really crappy user experience, since the browser‘s basically unusable for a couple of seconds after startup if autoconfig is turned on and there’s no WPAD server.
There are a couple of simplifying assumptions we make:
Therefore our proposed solution is that when we‘re trying to do WPAD resolution, we fail very fast if the WPAD server doesn’t immediately respond to a lookup (like, 100ms or less). If there‘s no WPAD server, we’ll time the lookup out in 100ms and get ourselves out of the critical path much faster. We won't time out lookups for explicitly-configured WPAD servers (i.e., custom PAC script URLs) in this fashion; those will still use the normal DNS timeout.
This could have bad effects on networks with slow DNS or WPAD servers, so we should be careful to allow users to turn this off, and we should keep statistics as to how often lookups succeed after the timeout.
So here's what our WPAD lookup policy looks like currently in practice (assuming WPAD is enabled throughout):
Here's what the proposed lookup policy looks like in practice: