More on the Apple PAC bug

Apple has this as case # 49365331.



Apple *still* doesn't realize the impact of this problem. I had to go througha group at work that has a megabuck support contract (hundreds of G5s),just to get a case number assigned.



The Proxy Automatic Configuration URL feature, as implemented in Safari, is broken. Instead of just making one HTTP request for the PAC file at the start of a session, Safari 2.0(412) makes a HTTP request to the PAC server once for each *object* requested -- for each HTTP request out to the Internet,a corresponding request is made to a local HTTP server, for the PAC file.I've seen individual workstations making PAC request at rates as highas 57 GETs/second, totalling over ten thousand hits in a day from a single Tiger workstation.



For comparison, the average MS-Windows client hits the PAC URL a mere 7 times per day. Normally a web browser will retrieve a fresh copy of PAC when first launched,and then cache this copy, refreshing the contents either based on the Expires header or using an internal refresh timeout (Under MSIE, the refresh time can be set using the IEAK).



When using a local PAC file (a file::/localhost/... URL), the network problems are avoided, but browser performance is poor, with sporadic broken images and general slowness in loading pages.



In MacOS Panther and Tiger, the option to configure proxy settings is under System Preferences/Network/Proxies. This menu gives the user the option to set the "PAC File URL", but no option for how/whether this file is cached and refreshed. Also, Safari does not respect Expires header sent with the PAC file.For each object accessed, Safari makes a new TCP connection to the PAC server (specifying "Connection: close") and sends a HTTP/1.0 request.



Workarounds:

Installing 10.4.1 does not resolve this issue.

Switching to Firefox eliminates this problem. Firefox will only download the PAC file at session start, or when the user manually chooses to reload it.



(P.S. A description of this problem was sent one week ago to the official "product-security@apple.com" address. Further assistance in bringing this issue to the attention of the Safari development team is appreciated.)



(P.P.S. I must give credit to Isaac Claymore for independently identifying the problem about a week before I first noticed it.)