Known Issue - Internet Explorer 8 PAC File Support

[Last Updated: Tuesday, 13-Jul-2010 16:58:18 EDT]

UPDATE

After months of downplaying this issue and stating the software was designed to work this way and they won't fix it, Microsoft issued a "security rollup" for IE8 on Tuesday June 9th that addresses this issue. If this issue was such a fundamental design issue, I would think that it could not be fixed so quickly in a simple security rollup release. It is sad that it takes a huge amount of corporate pressure for Microsoft to see the error of their ways.

With the introduction of Internet Explorer 8 by Microsoft many people are beginning to upgrade based on the advertised improved performance and new features included. While that is great, there is a hidden problem (Microsoft calls it "by design") lurking for many Enterprise users or anyone that may make use of a Proxy AutoConfiguration (PAC) file to define a browser forwarding policy for Internet access. Typically Enterprises lock down their workstations so that clients can not install new, unsupported software to avoid incompatibility issues or previously unknown limitations or problems. They will test these packages prior to deploying to their users to proactively identify and resolve these issues that new software can introduce.

Given that web browsers are ubiquitous for the most part and they are supposed to conform to open standards, you would think that would prevent these kinds of issues from occuring. But Microsoft, in their infinite wisdom, has chosen to cripple a rather fundamental process within the browser that supports PAC file parsing functions. The funny thing is that Microsoft has posted a KnowledgeBase KB article about this specific issue. Microsoft has since retracted the original KB article from their website, after releasing a Cumulative Security patch that included a "fix" for this issue.

Original KB Article archived at NetOMatix

Original KB Article link (No Longer Available) - http://support.microsoft.com/kb/922778/en-us

You can see for yourself that Microsoft has decided to not fix this issue and state that it is "by design". This implies that all Enterprises that make use of PAC files for their browser forwarding policy, which includes the majority of Enterprises, must introduce a new construct into their PAC files in order to be able to support isInNet rules with IE8. Following is an example construct that can carry the manually resolved DNS hostname as a variable for use throughout a PAC file. All isInNet rules in the PAC file must now evaluate the hostip variable like the example below.

var hostip = 127.0.0.1;

 if (isResolvable(host)) {
    ip = dnsResolve(host);
 }

 if (isInNet(ip, "10.0.0.0", "255.0.0.0")) {
  return "DIRECT";
 }

This stance that Microsoft has chosen is a terrible precedent for PAC file support. For the past 15+ years there have been no standards around how a PAC file javascript must be written, aside from the default functions that must be supported by all browsers and normal javascript syntax. With this issue, you will no longer be able to use isInNet rules in a PAC file with IE browsers unless you include this "workaround" javascript logic that forces the browser to manually resolve the DNS hostname for a request. This is ridiculous! All browsers throughout the history of PAC file support have automatically resolved the domain in the host variable when parsing an isInNet rule within a PAC file. Now I have to include a manual function in the PAC file script just to support a Microsoft browser to do it because they have chosen not to do it by default anymore. That is crap!

This may seem like a fairly innocent issue, but it has long term implications for implementation standards around the use of PAC files with web browsers. What if another browser decides they don't want to support the dnsResolve function in PAC files anymore because they just do it automatically? Now I have to have a PAC file to support Microsoft browsers and another one to support other browsers. Where does it end? This is a long-term support nightmare. PAC files have long been a source of confusion for many network engineers and support staff. The fact is that there is no "real standard" around PAC file implementation. Netscape introduced the functionality and hosted implementation documentation on their website for many years. They eventually removed that content and now everyone is left to search out bits and pieces of information scattered around the Internet. There really needs to be an RFC written that outlines the standard implementation. Having a written standard that everyone agrees upon prevents further issues like this from occuring as vendors are pressured to conform to industry accepted best practices.