HTTP/1.1 302 (Found) Moved Temporarily
Location: /?ABCDEFGH
Content-Length: 0
Client-Date: Thu, 08 Dec 2005 17:08:51 GMT
Client-Peer: 64.202.167.129:80
Client-Response-Num: 1
Client-Warning: Redirect loop detected (max_redirect
= 0)
Note the last line, about redirect loop detected.
I think you're onto something there. I did some various testing, and I think what's going on is something screwy with the way their redirect service works.
In my testing, regardless of what user agent I use or what client I use, I invariably get the redirect loop for 1 or sometimes 2 iterations before it finally responds with the 302 Found message and points me to the right place. Subsequent requests invariably go straight to the 302 Found response. Until I let some time pass, and then I get the 302 Moved Temporarily loop again.
What I think is happening is that their redirection system is coded to be a "real-time" setup. That is, it's guaranteed to provide you an answer in some kind of reasonable time. When it goes to look up the information in it's redirection database, if that takes longer than expected, you get the loop response back, which makes your browser submit the request again. Once you do get the Found response, that information is cached somewhere, and so subsequent hits to it are fast enough to not shunt you into the loop. Until their cache expires, of course.
And it sounds like Safari doesn't much care for redirect loops.
This explains all the observed behavior.
-Why it works in some browsers but not others (some don't like loops as much as others)
-Why those browsers work after you actually get it to work (that cache on their end)
-Why this happens even if you use browsers on different computers through a router (the cache might be keyed to requesting IP address)
In the end, it's still GoDaddy's problem, but it is unusual that Safari (and Opera) won't follow redirect loops.