Web Caching

Web Proxy Auto-Discovery

As I mentioned earlier, proxy auto-configuration usually requires the user to manually enter a URL in the proxy configuration window. Recent efforts by browser developers seek to eliminate that step. This new feature is called web proxy auto-discovery, or WPAD. WPAD is designed to let browsers automatically learn the auto-configuration URL with no assistance from the user.

WPAD uses a number of protocols and services to find the auto-configuration URL. The preferred protocol is DHCP (Dynamic Host Configuration Protocol). If DHCP fails, the user-agent may try the Service Location Protocol (SLP, RFC 2068) next. If SLP fails as well, it queries the DNS for A, SRV, and TXT records. A client that implements WPAD must support at least the DHCP and DNS A record queries. Support for SLP is optional.

Using the DNS is likely to be the simplest and most popular approach for network administrators. The first step is to select an HTTP server and place a proxy auto-configuration script there under the name /wpad.dat. Then the administrator needs only to add a DNS entry for a host named wpad. For example, if wpad.company.com is an alias for company.com’s web server, and the wpad.dat file is installed there, all of the company’s web browsers can automatically configure themselves.

WPAD was submitted to the IETF as an Internet Draft in December of 1999. Unfortunately, it has not yet been updated or moved beyond that stage, and the draft is now expired. Even so, Microsoft’s Internet Explorer (Version 5) already supports WPAD. The protocol authors seem uninterested in advancing the protocol within the IETF. Their lack of enthusiasm may be due to some negative reactions to WPAD on various mailing lists and in IETF working-group meetings. One of the issues is that WPAD refers to (i.e., requires) JavaScript, which is not a standardized language. The situation is unfortunate because many of us believe WPAD is a much better way to get clients talking to a caching proxy.