The focus of this paper is to study features and behaviours of Proxy Autoconfiguration files[1] that impact proxy failover and reconfiguration events.
There are several facilities available in proxy autoconfiguration files that can be used to dictate which server is to be used for a request. Once this is determined, the returned value is in the form:
PROXY server1:port; [PROXY server2:port; ...]
In this case, server1 will be tried first; if it fails, server2 will be used. There can also be a DIRECT specification, which will cause the browser to connect directly to the origin server to fetch the object. This is often used as a last-ditch failover mechanism.
Autoconfiguration is the only client-based form of proxy failover. As such, it is often used when the cost of deploying a redundant proxy system cannot be justified. Unfortunately, anecdotal evidence suggests that the failover mechanism is not uniform between browsers, and takes an abnormally long time to switch over. This hinders its use.
Although there are other proxy configuration mechanisms under development or being deployed, Proxy Autoconfiguration enjoys wide deployment and support, and new mechanisms (such as WPAD[2]) are at least partially based upon it, which means that they will inherit Autoconfiguration's limitations.
On the client side, we tested the latest versions of popular browsers; Netscape 4.61 and Internet Explorer 5 on Windows. The "Mozilla" browser[3] was not tested because, as of milestone 8, it does not yet support proxy configuration.
The Autoconfiguration file itself was served by Apache 1.3.6[4], and the caches it directed browsers to were one or more instances of WebTee[5] (used to verify the transactions), each pointing at Squid 2.0[6]. TCPdump was used to watch for connection attempts to unavailable services.
In the experiments, a server was simulated as 'down' by killing the appropriate WebTee process, so that the corresponding socket was no longer listened to.
Determine the browser behaviour when configured to use a single proxy, and it 'disappears'. Then, observe what happens when the proxy is again available.
The following configuration directive was used:
PROXY proxy:8001;
When a request is made, Netscape will attempt to contact the proxy for ~30 seconds. If still not available, the following dialog comes up:
All proxies are unavailable. Do you wish to temporarily override proxies by connecting directly until proxies are available again?
If the user selects 'OK', the browser will attempt to directly contact the origin server of any request for a period of 20 minutes. After 20 minutes, it will ask,
Try connecting to the proxy again?
If the user selects 'OK', the browser will attempt to contact the proxy for ~30 seconds. If it is still not available, the browser will present:
All proxies are still down. Continue with direct connections?
At this point, if the user selects 'OK', the browser will continue to attempt to connect to the origin server(s) for requests. After 40 minutes, it will ask whether the user wishes to connect to the proxy again, and go through the cycle. We did not ascertain whether this apparently exponential backoff continues.
If the user declines going direct by pressing 'cancel', or if the origin server is not available, they will see a notice that states
There was no response. The server could be down or is not responding. If you are unable to conect again later, contact the server's administrator. Using previously cached copy instead.
IE had a more streamlined process for failover. It would attempt to connect to the proxy for ~2 seconds, and then display:
Internet Explorer cannot open the Internet site [origin server]. A connection with the server could not be established.
We see how long it takes, and what happens, when the browser is configured to use a primary and backup proxy, and the primary 'dies'. Also observe what happens when it becomes available again.
The following configuration directive was used:
PROXY proxy:8001; PROXY proxy:8002;
After the primary proxy is unavailable for ~35 seconds, Netscape will switch to the backup proxy. After 40 minutes, it will attempt to reconnect to the primary, timing out after ~35 seconds.
If the backup proxy becomes unavailable, it will ask
All proxy servers are unavailable. Try connecting to [primary proxy] again?
If the user selects 'OK', and the primary proxy is available, it will use it. Otherwise, it will return the 'no response' message as above.
After the primary proxy is unavailable for ~2 seconds, IE will switch to the backup proxy. After 30 minutes, it will attempt to reconnect to the primary, timing out after ~2 seconds.
Internet Explorer does not appear retry the primary proxy if the backup also is unavailable.
Failing over to the secondary proxy only happens when the user accesses a Web site different from the one where they last succesfully received a response; if they attempt to access that site after the proxy becomes unavailable, they will see a rather lengthy error page that states, in part,
Cannot find server or DNS Error
To determine if a browser's proxy autoconfiguration can be updated, we set an Expires: time on it.
Netscape did not make any request for the file after the autoconfiguration file became stale.
IE did not make any request for the file after the autoconfiguration file became stale.
What is the behavoir of the browser when the configuration file returns a 404 response?
If Netscape cannot load the file, and has downloaded it in a previous session, it will ask
Use the configuration file from the previous session instead?
IE will attempt to go direct to the origin server, with no warning to the user, if the autoconfiguration file is missing.
How does the browser treat an invalid configuration file?
Netscape displays the following dialog:
The automatic configuration file has errors: [autoconf URL] Use the configuration file from the previous session instead?
If the user selects 'cancel', the browser will attempt to contact the request's origin server directly.
IE will attempt to go direct to the origin server, with no warning to the user, if the autoconfiguration file is invalid.
Current implementations of proxy autoconfiguration have several undesireable behaviours, including;