29 December 2005

Proxy Auto-Config (PAC) Files and MacOS 10.4

UPDATE: I do believe the issue described herein is fixed as of MacOS 10.4.6. Thanks, Apple!

Ever since MacOS 10.4 “Tiger” I’ve been unable to use AT&T’s corporate proxy auto-config (PAC) file in conjunction with Safari.

This PAC has no coding errors and works fine when fed directly to Firefox or other PAC-aware browsers. (Always has.) Meanwhile, Safari and other apps leverage the MacOS Network Preferences, and for some reason that same PAC file just doesn’t work.

This afternoon, I finally got around to hacking the PAC file to bits, and I’m pleased to report I’ve found the smoking gun, and - at least in my case - how to get things working again.

I’m not at liberty to share AT&T’s PAC but the issue boils down to one thing: global variables.

First, a wee bit of background: PAC files are written in JavaScript. The Proxy Client Auto-Config File Format as originally defined by Netscape is directly supported by several user agents. In the MacOS and Windows cases, PACs are also supported as a system-wide configuration that user agents can tap into if desired.

Now, in JavaScript there are global and local variables. In a nutshell, a variable is global in scope if it is declared:

  • Outside all functions, with or without the var keyword.
  • Inside any function, without the var keyword, but only once the function is called.

A variable is local in scope it if is declared:

  • Inside a function, with the var keyword.

So what’s the problem? It turns out that, as of MacOS 10.4, if your PAC file has any variables defined outside of functions (and I mean any variables, with or without the var keyword), they will not be treated as global. In fact, they will not be visible inside any functions, period! As far as functions in the PAC are concerned, those variables don’t exist.

In the case of AT&T’s PAC, the fix was very straightforward. I moved a group of variables defined at the top, outside of function scope, to the start of the required FindProxyForURL function (taking care to make sure var is not used, making them global variables). Ta-dah, it works in Safari. Meanwhile, all the other browsers I use have no problem with the change. Sweet.

I’m not sure if this treatment of variables within a PAC is considered a bug or a feature, but I’m leaning toward the former. Meanwhile, I’m sharing this with Apple Support and asking for more insight on the matter.

To sum up, when it comes to PAC files:

  • Only define variables within functions, not outside of them.
  • Define all global variables at the start of FindProxyForURL.
  • Leave off the var keyword for those variables.

Happy New Year!

Posted by joe at 02:44 PM

Trackback Pings

TrackBack URL for this entry:
http://www.joesapt.net/mt/mt-tb.fcgi/39

Comments

Will Cox of Cox Crow writes:

That was it? And only for the proxy config javascript?

# 29 December 2005, 09:08 PM -05:00

Joe writes:

In my case, that’s all it was, and only for the PAC. When I took the same code (sans PAC-specific functions), embedded it into a web page and dragged it in to Safari, it worked fine.

Here’s an example, oversimplified PAC file:

globalVar = 1;
function FindProxyForURL(url, host) {
  if (globalVar == 1) { return "DIRECT"; }
}

Doesn’t matter if there’s a var in front of globalVar or not. As long as it remains outside of any functions and is depended upon for PAC functionality, it’s a non-starter.

However, if you were to try similar logic within (X)HTML, it works just fine:

<script type="text/javascript">
//<![CDATA[
globalVar = 1;
function FindProxyForURL(url, host) {
  if (glolbalVar == 1) { return "DIRECT"; }
}
alert(FindProxyForURL());
//]]>
</script>

In this case, you’ll get an alert.

My first thought upon noticing this was there must be two JavaScript engines in play, or perhaps some restrictions are afoot where PACs are concerned … or something completely different.

After posting this, I headed to the OpenDarwin Bugzilla site, searched for “pac” and found a comment from July 2005 mentioning that JavaScriptGlue might be out of sync with JavaScriptCore (the latter of which is part of WebCore).

Another comment from September 2005 backs it up: “When using TOT JavaScriptCore, you should not expect .pac files to work, because the framework JavaScriptGlue in the OS is incompatible with it.”

Is this related? I have no idea. It certainly caught my attention though.

# 30 December 2005, 12:15 AM -05:00

Geoffrey Garen of writes:

“When using TOT JavaScriptCore, you should not expect .pac files to work, because the framework JavaScriptGlue in the OS is incompatible with it.”

TOT stand for Tip of Tree — it’s what you get if you download and build the latest WebKit sources. For obvious reasons, Tip of Tree WebKit is out of sync with the current shipped version of the OS. However, Tip of Tree is not what shipped with Tiger.

So, good guess, but no, it’s not related.

# 13 January 2006, 02:27 PM -05:00

Joe writes:

Update: At last I’ve filed this one over at OpenDarwin Bugzilla. Hopefully some kind soul(s) there can shed more light on this one or provide other advisement.

# 13 January 2006, 03:48 PM -05:00

Joe writes:

Geoffrey, thanks! I should’ve known that one (TOT). :)

# 13 January 2006, 03:49 PM -05:00

Post a comment


(will not be published)


Remember Me?

(you may use HTML tags for style)