One Year Safari Response Timeouts?

'That should be plenty of time for a server-side process to complete!'
 - Apple Inc

Get It Try It

Proprietors of websites with authenticating URLs may have a bit of a shocker when they check their HTTP logs: thousands upon thousands upon thousands of misfired access requests all returning 401s and all in spurts of 2-3 minutes at a time.

Naturally these occurrences can create a dangerous denial of service situation.

Research by 'Peter T' in Vic in Australia seems to have isolated the culprits: three separate Apple 'technologies' which together create a catastrophic concoction.

1. Apple's keychain. The file 'login.keychain' seems prone to corruption, possibly on an upgrade from Tiger 10.4 to Leopard 10.5.
2. YASB - yet another Safari bug. Which keeps Apple's web browser hammering away at a URL despite being told '401' ('no') thousands upon thousands of times.
3. YASB - yet another Safari bug. And in this case a fortunate one which leads to Safari crashing after a few minutes of this nonsensical activity.
4. A brilliant 'Apple' design decision for OS X 10.3.6. See below.

The fix seems eminently straightforward: destroy website keychain entries and let the system create them again.

Plenty of Time! Yeah!

The fact a seemingly benign web browser can effectively create a denial of service situation is not solely due to buggy Apple code but also to a fateful decision made back in 2004. And it applies to an annoyance early adopters of Safari experienced: the browser would simply give up. All too easily.

So someone at Apple got a great idea.

Yes it should be plenty of time. Unfortunately it leads to disaster if anything's wrong with the browser.

1. User upgrades from Tiger to Leopard. The keychain gets corrupted.
2. User chooses Safari to access authenticating URLs. Safari can't read the corrupted entry properly.
3. Safari starts looping on the 'inaccessible' URL. The user is given no authentication challenge.
4. This can theoretically continue for one year. But fortunately there's yet another bug in Safari.

Firefox users are not affected.

Monitor with GD

ACP users can easily monitor Safari behaviour with the GD connection window, explains Peter. The window keeps track of all unique connections by IP and port. If the number of recorded connections starts going ballistic - kill the Safari process, remove the website keychain entries, and start again.

Postscript: 'And While We're At It'

An anomaly reported to Apple in July 2007: Safari only works with one keychain entry per domain. This was reported nearly a year ago - before the advent of 10.5 Leopard. It was reported after gawking at it for years on end and noticing nobody in Cupertino got their MacCoins dropping down their MacSlots.

The issue? Safari stores responses to authentication challenges per domain. But that scrawny little web server known as Apache with its miniscule 70% of the market allows for authentication per directory.

Which makes sense: different user groups are allowed access to different sections of a website. It makes perfect sense.

Now try propagating that factoid up the ranks in Cupertino. Good luck.