747316 - Infinite 302 redirects when viewing production mobile Input site from iPhone

Status: VERIFIED FIXED

(Input Graveyard :: Frontend, defect)

Description

[Stephen Donner [:stephend] Not actively reading bugmail]

http://www.blaze.io/mobile/result/?testid=120420_AE_8QX&vidid=120420_6209035b179678151720d9deae18d9960b5ed9a4

1) We're constantly 302'ing when we hit https://m.input.mozilla.org with an iPhone; see above
2) Additionally, when we hit https://m.input.mozilla.org from a desktop, we should stay on the mobile view (URL stays, but the desktop view persists)

Comment 1

[James Socol [:jsocol, :james]]

(In reply to Stephen Donner [:stephend] from comment #0)
> http://www.blaze.io/mobile/result/
> ?testid=120420_AE_8QX&vidid=120420_6209035b179678151720d9deae18d9960b5ed9a4
> 
> 1) We're constantly 302'ing when we hit https://m.input.mozilla.org with an
> iPhone; see above

Reproed with my phone, but not sure how critical this is, do we get a lot of feedback/traffic via iOS Safari? Does it occur in Fennec or B2G?

> 2) Additionally, when we hit https://m.input.mozilla.org from a desktop, we
> should stay on the mobile view (URL stays, but the desktop view persists)

This is a very old-school way of doing mobile sites, we should update to using mobility. You know, when we have some dev time.

Comment 2

[Matt Brandt [:mbrandt]]

(In reply to James Socol [:jsocol, :james] from comment #1)
> (In reply to Stephen Donner [:stephend] from comment #0)
> >  Does it occur in Fennec or B2G?
I was able to reproduce the error on Fennec.

Comment 3

[James Socol [:jsocol, :james]]

It's bouncing back and forth between m.input.mozilla.org and m.input.mozilla.com, I think that makes this an IT bug around bug 618157. Stephen or Matt, can you push it to the web ops component and ping them?

Comment 4

[Jake Maul [:jakem]]

I can't reproduce this with curl:

[root@pp-app-input01 reporter]# curl -I http://m.input.mozilla.org
HTTP/1.1 301 MOVED PERMANENTLY
Server: Apache
Vary: Accept-Language,X-Mobile,User-Agent, Accept-Encoding
X-Backend-Server: pp-app-input01
Content-Type: text/html; charset=utf-8
Date: Fri, 20 Apr 2012 16:54:48 GMT
Location: http://m.input.mozilla.org/en-US/
Transfer-Encoding: chunked
Connection: Keep-Alive
x-frame-options: DENY
X-Cache-Info: caching

Testing http://m.input.mozilla.org/en-US/ returns a normal 200 OK, no redirect.


[root@pp-app-input01 reporter]# curl -I http://m.input.mozilla.com/
HTTP/1.1 301 Moved Permanently
Server: Apache
X-Backend-Server: pp-app-input01
Vary: Accept-Encoding
Content-Type: text/html; charset=iso-8859-1
Date: Fri, 20 Apr 2012 16:55:37 GMT
Location: http://m.input.mozilla.org/
Transfer-Encoding: chunked
Connection: Keep-Alive
X-Cache-Info: caching


Is this something in the app, perhaps?

Note: I did just discover a strangeness with our Apache config- the config file was renamed, but puppet didn't purge the old one. This wasn't affecting my curl testing above, so I don't *think* this will have an effect, but I mention it for completeness.

Comment 5

[Jake Maul [:jakem]]

This is definitely something in the app code... figured out how to replicate it- it's triggered based on the User-Agent passed. Nothing in Apache cares about that. :)

With the UA from my phone:

[jakemaul@jakebook domains]$ curl -I -H 'User-Agent: Mozilla/5.0 (Android; Linux armv7l; rv:10.0.3) Gecko/20120302 Firefox/10.0.3 Fennec/10.0.3' http://m.input.mozilla.org/en-US/
HTTP/1.1 302 FOUND
Server: Apache
Vary: User-Agent,X-Mobile,Cookie, Accept-Encoding
X-Backend-Server: pp-app-input03
Content-Type: text/html; charset=utf-8
Date: Fri, 20 Apr 2012 20:27:14 GMT
Location: http://m.input.mozilla.com/en-US/
Transfer-Encoding: chunked
Connection: Keep-Alive
x-frame-options: DENY
X-Cache-Info: not cacheable; response is 302 without expiry time


With curl's stock UA:
[jakemaul@jakebook domains]$ curl -I http://m.input.mozilla.org/en-US/
HTTP/1.1 200 OK
Server: Apache
Vary: X-Mobile,User-Agent,Cookie, Accept-Encoding
X-Backend-Server: pp-app-input02
Cache-Control: max-age=300
Content-Type: text/html; charset=utf-8
Date: Fri, 20 Apr 2012 20:27:51 GMT
Expires: Fri, 20 Apr 2012 20:28:23 GMT
Accept-Ranges: bytes
x-frame-options: DENY
Last-Modified: Fri, 20 Apr 2012 20:23:23 GMT
X-Cache-Info: caching
Content-Length: 49052

Comment 6

[Shyam Mani [:fox2mike]]

Jake, I did the UA based testing before I asked Stephen to file this bug to the developers. Surely not something on the IT side of things AFAICS.

Comment 7

[Nigel Babu [:nigelb]]

I have a suspicions this is the fall out from the com -> org in the app logic.  Did we change the url in the Django site framework? James, do you know?

Comment 8

[Nigel Babu [:nigelb]]

I worked with ashish today morning and we looked that the django_site table on input.  These are the entries.

+----+---------------------+---------------------+
| id | domain              | name                |
+----+---------------------+---------------------+
|  1 | input.mozilla.com   | input.mozilla.com   | 
+----+---------------------+---------------------+
|  2 | m.input.mozilla.com | m.input.mozilla.com |
+----+---------------------+---------------------+


I believe we need to have the .com entries changed to .org.  We do app-level redirects based on these entries and I suspect this is what's gone wrong.  Since, neither ashish nor I wanted to experiment on a Sunday night, I'll leave the decision to make the change to jsocol :-)

Comment 9

[James Socol [:jsocol, :james]]

Thanks, Nigel!

Do you have a superuser account on Input? Or, um, does anyone?

Comment 10

[James Socol [:jsocol, :james]]

Gone ahead and implemented Nigel's suggestion. Doesn't seem to have broken anything. Calling this fixed so QA can re-test. Please reopen if it's not.

Comment 11

[Stephen Donner [:stephend] Not actively reading bugmail]

Verified FIXED; works on my iPhone and on Android 3.0.

Comment 12

[Matt Brandt [:mbrandt]]

Yay .. double verified on my truly superior Android phone - tosses a zing @ stephend ;-)