Previous 1 2 3 4 Next 47 Replies Latest reply: Dec 3, 2015 12:35 AM by joeykork
brian_c Level 1 (5 points)

I use a .pac file in order to enable/disable my web proxy when browsing specified sites with Safari.  It worked fine under Snow Leopard, but does not work under Lion.  My .pac looks like this:


function FindProxyForURL(url, host)


// variable strings to return

var proxy_yes = "PROXY my";

var proxy_no = "DIRECT";

if (shExpMatch(url, "*")) { return proxy_yes; }

if (shExpMatch(url, "")) { return proxy_yes; }

// Proxy anything else

return proxy_no;



Any advice on how to get the .pac working again?

15" i5 MacBook 2.4GHz, Mac OS X (10.6.5)
  • Keri Henare Level 1 (0 points)

    I can confirm that this bug exists. My .pac proxy file is also failing.

    var tests = [
        direct = 'DIRECT',
        proxy = 'PROXY webserver:80';
    var FindProxyForURL = function (url, host) {
        var i = 0;
        for (i = 0; i < tests.length; i = i + 1) {
            if (shExpMatch(host, tests[i])) {
                return proxy;
        return direct;
  • brian_c Level 1 (5 points)

    Glad to see that it's not just me... since it's reproducible by multiple users, hopefully Apple will get to work on fixing this.  I've reported it to them via their developer bug reporter;  fingers crossed for 10.7.1.

  • tjj70302 Level 1 (0 points)

    same victim here, and a similar topic below


    Safari 5.1 ingores .pac file

  • FreeWizard Level 1 (10 points)

    Local PAC will not work bc of the sandbox mechanism in Lion.

    Using a remote (http://) should be fine.

  • brian_c Level 1 (5 points)

    Yup, moving my .pac to a remote server got it working again.  Thanks!

  • SpaceAge Level 1 (5 points)

    Thanks for the info about the sandboxing.  Putting the proxy on the remote sever does work, but that means ALL my requests have to go to the remote sever first, and I only want a few select sites to go that way instead.  Temporarily, I enabled web sharing, and placed the .pac file on http://localhost/proxy.pac , which works too.

  • brian_c Level 1 (5 points)

    Clever solution.... I'm gonna use it

  • SpaceAge Level 1 (5 points)

    Also note that there is a discrepancy between the fact that the pac file is supposed to be on a http:// site, and yet there is still the "Choose File" button, which opens the local drive.

  • tjj70302 Level 1 (0 points)

    nice and neat, i am going to do the same


    thanks a bunch!

  • wmd were my initials first Level 1 (0 points)

    I see we have a workaround but is this considered a bug and is Apple planning on fixing it?


    I ask this because the wizards at my company use an applet from Juniper Networks to implement their RSA based secure VPN.  In their zeal for security, they thought they'd copy the PAC file locally upon VPN connection.  I can only assume that they hoped to increase the performance of browser connections.


    Yet, by bypassing the traditional commands to set proxy and forcing their choice on the system, any browser that uses the system proxy settings are hosed - that means Safari.  Yes, it was a well-intentioned but poorly thought out configuration decision.


    The question now is - do I have to wait some period of months until the wizards at my company fix their mistake?  or is this a bug that Apple will be fixing in a few weeks?

  • ThatsUnpossible Level 1 (0 points)

    I am pretty sure the .pac file is not downloaded for every request (that would be insane). More than likely it is downloaded and cached periodically (perhaps when the browser first starts up). So running it on a localhost web server should not be required.


    I agree this seems like a bug, at the very least Apple should warn you when it detects a local proxy pac if it's really not "supposed" to work any more.

  • brian_c Level 1 (5 points)

    I also think it'a bug.  They wouldn't have a "Choose File..." dialog available if local files weren't permissible.

  • Tom Fischer Level 1 (0 points)



    I found a workaround to this issue that doesn't involve having to install your pac file on another web server, nor activating web sharing on the local system.


    First, a little more background on what I found:


    After configuring my system to use a local .pac file (in my case, "proxy.pac"), I took a look at my console log messages, and found the following:


    07/09/11 12:21:25.721 AM sandboxd: ([82829]) WebProcess(82829) deny file-read-data /Users/tfischer/Documents/scripts/proxy.pac


    Ok - so this just confirms that the sandboxing of Safari 5.1 is preventing the WebProcess daemon from accessing the proxy.pac file. 


    However, Safari does a lot of stuff, and it has to be able to read some files (plugins, etc.), so the trick is to put the pac file somewhere that WebProcess can access.


    After rooting around a bit, I found that there are sandbox definition/configuration files for various processes and apps in /usr/share/sandbox.  These files end in ".sb", and they define all sorts of things - what files can be read, written, etc.  Unfortunately, the sandbox definition file for WebProcess doesn't live in /usr/share/sandbox.  Searching a little bit further revealed that the sandbox definition file is here:


    /System/Library/PrivateFrameworks/Webkit2.framework/ urces/


    I initially thought about modifying the file to tell it that it could read /Users/tfischer/Documents/scripts/proxy.pac (with a couple lines like the following:


    (allow file-read-data

              (home-literal "/Users/tfischer/Documents/scripts/proxy.pac"))


    but after some reflection, I decided that this wasn't a good idea:  even if the modified file worked, my changes would be wiped out the next time that Safari was updated.


    Further examination of the file showed that WebProcess has read access to the "/Library/Internet Plug-Ins/" directory.  So, I copied my pac file into "/Library/Internet Plug-Ins/proxy.pac", modified my network preferences to reflect the pac file's new home, and restarted Safari.


    After doing this, Safari was able to use the local pac file again...


    I hope this helps!


    best regards,



  • tjj70302 Level 1 (0 points)

    Wow, excellent findings! this workaround looks much better than enabling the web server, gonna try it later when i get home


    thanks Tom

Previous 1 2 3 4 Next