Closed Bug 813365 Opened 11 years ago Closed 10 years ago
techcrunch articles and frontpage don't load w/ B2G browser user agent string - instead, they get "The page isn't redirecting properly"
STR: Load http://m.techcrunch.com EXPECTED RESULTS: techcrunch mobile site loads. ACTUAL RESULTS: Internal browser error page, saying: === The page isn't redirecting properly. Firefox has detected that the server is redirecting the request for this address in a way that will never complete. * This problem can sometimes be caused by disabling or refusing to accept cookies. [Try Again] === B2G browser on my unagi gives ACTUAL RESULTS. For comparison, Nightly on Android gives EXPECTED RESULTS. (My Linux desktop nightly gives EXPECTED RESULTS, too, but it's sort of cheating because they redirect desktop-firefox to the non-mobile site.)
Summary: techcrunch articles (and frontpage) doesn't load on B2G browser → techcrunch articles and frontpage don't load on B2G browser - instead, they get "The page isn't redirecting properly"
Looks like this is actually a bug in Techcrunch. If I change my desktop user agent to match B2G* then I hit this on desktop. Moving to Tech Evang. * B2G user agent: Mozilla/5.0 (Mobile; rv:18.0) Gecko/18.0 Firefox/18.0
Assignee: nobody → english-us
Component: Gaia::Browser → English US
Product: Boot2Gecko → Tech Evangelism
OS: Linux → All
Hardware: x86_64 → All
Summary: techcrunch articles and frontpage don't load on B2G browser - instead, they get "The page isn't redirecting properly" → techcrunch articles and frontpage don't load w/ B2G browser user agent string - instead, they get "The page isn't redirecting properly"
Some targeted curl commands to show what's going on here... http://m.techcrunch.com gets redirected to http://techcrunch.com/ : $ curl -A "Mozilla/5.0 (Mobile; rv:18.0) Gecko/18.0 Firefox/18.0" m.techcrunch.com <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html><head> <title>302 Found</title> </head><body> <h1>Found</h1> <p>The document has moved <a href="http://techcrunch.com/">here</a>.</p> </body></html> ...and that gets redirected back to http://m.techcrunch.com/ : curl -v -A "Mozilla/5.0 (Mobile; rv:18.0) Gecko/18.0 Firefox/18.0" techcrunch.com * About to connect() to techcrunch.com port 80 (#0) * Trying 18.104.22.168... * connected * Connected to techcrunch.com (22.214.171.124) port 80 (#0) > GET / HTTP/1.1 > User-Agent: Mozilla/5.0 (Mobile; rv:18.0) Gecko/18.0 Firefox/18.0 > Host: techcrunch.com > Accept: */* > [--SNIP--] < Location: http://m.techcrunch.com/ [--SNIP--] ...and the loop goes on and on.
Assignee: english-us → nobody
Component: English US → General
Product: Tech Evangelism → Boot2Gecko
This is still technically a Tech Evang bug (a site bug), I think. It looks like techcrunch is still broken, redirecting any browser w/ the B2G UA string in an infinite loop, per comment 2. (I verified that I still get the same results from comment 2's curl commands.) Note: if I use the iPhone UA string instead, then m.techcrunch.com gives me actual content instead of a redirect.  Mozilla/5.0 (iPhone; CPU iPhone OS 5_0 like Mac OS X) AppleWebKit/534.46 (KHTML, like Gecko) Version/5.1 Mobile/9A334 Safari/7534.48.3
I just sent the following email to the TechCrunch webmaster email address (from http://techcrunch.com/contact/ ), to let them know about this & see if they can take care of it: =============== Hi, TechCrunch webmaster! I'm a Firefox developer, and I'm contacting you to report an issue in TechCrunch's UA-string-dependent redirecting, which happens to trigger an infinite redirect loop with the Firefox OS browser. Brief summary: when the Firefox OS browser (or any browser with its user agent string) sends a request to techcrunch.com, the server redirects them to m.techcrunch.com. Then, when we request m.techcrunch.com, the server sends a 302 redirect taking us back to techcrunch.com. And we loop forever. (or rather, we detect the loop and show an error page saying "The page isn't redirecting properly"). This means we can't load anything on your site, which makes us sad. This is tracked in Mozilla's bug-tracking system here: https://bugzilla.mozilla.org/show_bug.cgi?id=813365 I've provided "curl" commands (using the Firefox OS browser's UA string) that you can use to demonstrate this redirect bug for yourself in Comment 2 there. I'm hoping that someone can investigate & fix this on your end (probably removing the redirect from "m.techcrunch.com" and serving the actual mobile site instead). Your mobile website looks awesome on Firefox for Android, and it should look just as great on the Firefox OS browser, if only there weren't that redirect. Please let me know if there's anything I can do to help! Thanks, Daniel Holbert Mozilla  https://www.mozilla.org/en-US/firefoxos/  Firefox OS user agent string: Mozilla/5.0 (Mobile; rv:18.0) Gecko/18.0 Firefox/18.0
Right. Forgot to move it back to tech evangelism. I was just trying to remove the basecamp? nom.
Component: General → Mobile
Product: Boot2Gecko → Tech Evangelism
Just pinged TechCrunch on Twitter. We'll see if this helps. https://twitter.com/mmmandel/status/321329543275220992
pinged again on Twitter from MozWebCompat, and by e-mail to webmaster@
Assignee: nobody → hsteen
techCrunch has been redesigned since this bug has been put in place. They do not do redirection anymore but they distribute content depending on the user agent. Firefox OS and Firefox Android get the same content. → http -v GET http://techcrunch.com/ User-Agent:"$FANUA" | grep -i mobile | head -3 User-Agent: Mozilla/5.0 (Android; Mobile; rv:18.0) Gecko/18.0 Firefox/18.0 <meta name="MobileOptimized" content="320"> <meta name="apple-mobile-web-app-title" content="TechCrunch"> → http -v GET http://techcrunch.com/ User-Agent:"$FOSUA" | grep -i mobile | head -3 User-Agent: Mozilla/5.0 (Mobile; rv:18.0) Gecko/18.0 Firefox/18.0 <meta name="MobileOptimized" content="320"> <meta name="apple-mobile-web-app-title" content="TechCrunch"> closing as WORKSFORME
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → WORKSFORME
Product: Tech Evangelism → Web Compatibility
You need to log in before you can comment on or make changes to this bug.