October 01, 2003
Autoconfig proxy settings
If you run a network and people on it are using Internet Explorer (or even other browsers) you can help them find and use your network proxy (if you have one, that is).
HOW TO: Enable Proxy Autodiscovery from Microsoft discusses how to setup your DHCP server to help the client programs in finding the proxy.
There's also a domain you'll want to setup in your internal DNS zones. HOW TO: Configure Firewall and Web Proxy Client Autodiscovery discusses the steps. Basically you'll be setting up a DNS alias for 'wpad' and the putting a file named 'wpad.dat' on it's web server.
It's also described in the article: A Description of the Automatic Discovery Feature.
You can even do this for WinSock proxies.
A very important point to consider is you have to be using a current version of the browser. If you're using IE4 or IE5 you really should stop. Update to 5.5 or 6.0 immediately. There are enough bugs and security risks in those older versions to more than justify the upgrade.
Once you've got the network configured, or perhaps before, you'll want to make sure the file at that location is setup properly. It needs to contain instructions on how the client program should attempt to access the proxies. Yes, you can have more than one proxy. This same file can also be used on a laptop device for when it goes off the network. The autoconfig file can be setup to tell the client that if it can't reach the proxy it should try going direct. Since most laptops taken on the road won't be able to see the internal network proxy this lets them function with no changes to it's configuration.
This is basically the same thing as a proxy.pac file that other browsers might use.
Let's say your internal network uses the 192.168.8.0/24 IP address range. And you've got your proxies setup on a machines with the IP addresses of 192.168.8.253 answering on port 3128. Here's the simplest example of a wpad.dat (or proxy.pac) file:
function FindProxyForURL(url, host)
{
if (isInNet(myIpAddress(), "192.168.8.0", "255.255.255.0))
return "PROXY 192.168.8.253:3128; "
else
return "DIRECT";
}
That tells your client machines that if they find themselves on the 192.168.8.0 network they should try using the .253 proxy, otherwise they should go direct. If they fire up their laptop while connected via dial-up or WiFi they won't be on the .8 network and wouldn't bother trying to use a proxy.
There are much more sophisticated configuration options possible. For more info see Netscape's docs. Written way back in '96, they should still work. Example #5 is interesting in that it detects what type of request is being made and adjusts the proxy selection accordingly. Pretty slick.
It's multiplatform solution, even Novell has an AppNote discussing it. Their note also mentions you could use a file:// directive for locating it. Be careful here and only use this if you know what you're doing. Those file URLs can get tricky to set up properly.
I prefer taking the 'less is more' approach to setting up these files. Best to make it as simple as possible. Don't make this file any fancier that is needed. Don't go hog-wild configuring it for dozens of situations. Make it support only what your users are ever likely to encounter.
The great things is Windows supports these things right out of the box. But it does depend on you doing your part in configuring your network resources.
When you get these pieces setup properly new users won't have to suffer the agony of manually configuring this stuff.
