User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040316 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040316 Go to http://www.sportsnet.ca . Loads fine in Mozilla 1.6 Loads fine in Firefox 0.8 (which uses Moz 1.6) Loads fine in Netscape 7.1 Now try it in Mozilla 1.7x (beta or the latest nightly) Cache and History are cleared. ac.rnm.ca and sportsnet.ca are set to "can set cookies". Tried it in a fresh profile, and still no go. Reproducible: Always Steps to Reproduce: Latest build I tried it with is: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a) Gecko/20040419 I don't know what the source of the problem is; so I don't know if this is a problem with the website or Mozilla. For now, I'm filing it as a tech evangelism bug.
IE also gets stuck for quite a bit, but that may be me [running XP Pro with Service Pack 2 RC installed, which breaks quite a bit of the browser's smoothness :o] Seeing the same problem with a clean profile and Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a) Gecko/20040419 The page lists "download real player", "internet explorer 5+", download flash 6+" Can't find obvious dupes, but i can't see what's happening when the page is stuck in the DETECTING phase.
They are sending a content-location header with an ip-adress which is not reachable afaik: Content-Location: http://172.18.11.11/homepage/splash.jsp I think this line of html code has something to do with it: <EMBED src="/flash/regionchooser.swf?loc=http://www.sportsnet.ca/detectionpages/platformDetect.html&flhost=172.18.4.35:4022" I can't get that content-location header with that direct url in the embed tag. Server-response, which seems to cause the long wait: HTTP/1.x 200 OK Date: Wed, 21 Apr 2004 09:53:48 GMT Server: Orion/1.5.2 Content-Location: http://172.18.11.11/homepage/splash.jsp Set-Cookie: SportsnetUserType=1; Expires=Thu, 06-May-04 09:53:48 GMT; Path=/ Cache-Control: private Content-Type: text/html X-Cache: MISS from www.sportsnet.ca Keep-Alive: timeout=20, max=100 Connection: Keep-Alive Transfer-Encoding: chunked Afterwards, all the image seems to have an url that starts with: http://172.18.11.11/
In this forum they mention that it works in earlier versions of Firefox: http://forums.mozillazine.org/viewtopic.php?t=63200 Here is an rfc about content-location: http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.14 Maybe it is useful.
I've backed out content-location support.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → FIXED
Verified on Win32 zip of 1.7_20040504.
Status: RESOLVED → VERIFIED
Product: Tech Evangelism → Tech Evangelism Graveyard
You need to log in before you can comment on or make changes to this bug.