1080475 - Accessing http://mozilla.org/ results in 4 top-level redirects (and so 5 fetches)

Status: RESOLVED FIXED

(www.mozilla.org :: General, defect)

Description

[Gervase Markham [:gerv]]

STR: Type "mozilla.org" into your web browser's URL bar.

Actual:
* Browser does get for "/" on mozilla.org via HTTP
* 301 Moved Permanently. Location: https://mozilla.org/
* Browser does get for "/" on mozilla.org via HTTPS
* 301 Moved Permanently. Location: https://www.mozilla.org/
* Browser does get for "/" on www.mozilla.org via HTTPS 
* 301 Moved Permanently. Location: https://www.mozilla.org/en-GB/
* Browser does get for "/en-GB/" on www.mozilla.org via HTTPS
* 302 Found. Location: https://www.mozilla.org/en-US/
* Browser does get for "/en-US/" on www.mozilla.org via HTTPS
* 200 OK. Wahey!

Expected:
* Browser does get for "/" on mozilla.org via HTTP
* 302 Found. Location: https://www.mozilla.org/en-US/

Or:

* Browser does get for "/" on mozilla.org via HTTPS because we use HSTS
* 302 Found. Location: https://www.mozilla.org/en-US/

Gerv

Comment 2

[Paul [:pmac] McLanahan]

I think some (most) of this can be done in the IT controlled layer (Zeus et. al.). What say you Jakem?

Comment 3

[Jake Maul [:jakem]]

0) It's actually even slightly worse than this... if you start at http://mozilla.org, you first get redirected to https://mozilla.org, and then the chain above.

I dunno what we can do at the Zeus level... two of the 4 redirects are for locale things. We'd have to essentially duplicate the locale config from bedrock in either Zeus or Apache.


1) Seems like one could be cut out in bedrock by knowing that en-GB == en-US. Seems like it knows that eventually, but not up-front, and so sends a redirect that ultimately just redirects again.

2) We could maybe save another one by *not* redirecting for mozilla.org->www.mozilla.org at the Zeus/Apache layer, and letting Bedrock do that out as part of the locale redirect.

3) We could combine the one I mentioned above (#0) with the one that adds www to the URL as well. This overlaps with #2, so maybe not that helpful. I have done this.


How complicated is the locale redirect logic, and how frequently does it change? We could definitely merge that into Zeus or Apache if it's straightforward enough... I'm just hesitant to do so unless it's fairly static, because it's much less visible to you. Raises the "magic" level.

Comment 4

[Jake Maul [:jakem]]

(and FYI, this bug is outside of components I watch religiously, so please continue to NEEDINFO me if you need something from me... keeps it much brighter on my radar.)

Comment 5

[Paul [:pmac] McLanahan]

Oh yeah Jake. I'd not expect or want zeus to do anything with locales, but the whole http://mozilla.org -> https://www.mozilla.org could be done in one redirect instead of 2. Once we get there it's definitely on us to reduce the hops to the correct locale. If we wanted to reduce it to a single redirect we'd have to point mozilla.org and www.mozilla.org to bedrock, and I think part of the problem (especially with en-GB) is that it's hitting the PHP side first.

Comment 6

[Gervase Markham [:gerv]]

(In reply to Jake Maul [:jakem] from comment #3)
> 0) It's actually even slightly worse than this... if you start at
> http://mozilla.org, you first get redirected to https://mozilla.org, and
> then the chain above.

Er, that's the first one in my list...

> I dunno what we can do at the Zeus level... two of the 4 redirects are for
> locale things. We'd have to essentially duplicate the locale config from
> bedrock in either Zeus or Apache.

Let's not do that. I'd suggest one redirect from

http://mozilla.org/
to
https://www.mozilla.org/

at the Zeus level, and then a second one from
https://www.mozilla.org/
to
https://www.mozilla.org/en-US/
at the Bedrock level.

I think that would be OK.

> 1) Seems like one could be cut out in bedrock by knowing that en-GB ==
> en-US. Seems like it knows that eventually, but not up-front, and so sends a
> redirect that ultimately just redirects again.

Right. This needs fixing.

Gerv

Comment 7

[Jake Maul [:jakem]]

You're right, I must have misread... sorry!

Your first recommendation is done now:

$ curl -i mozilla.org
HTTP/1.1 301 Moved Permanently
Content-Type: text/html
Date: Fri, 17 Oct 2014 18:11:42 GMT
Location: https://www.mozilla.org/
Connection: Keep-Alive
Content-Length: 0


The second will be a code issue that pmac or jgmize will need to look at.

Comment 8

[Paul [:pmac] McLanahan]

Nice! Thanks jakem!

Comment 9

[Paul [:pmac] McLanahan]

Getting back to this, I think the rest of this will be fixed, or at least helped by our full removal of the PHP site and apache configs associated therewith. We're attempting to finish this in q3. Once that's done I believe we'll be about as efficient with this as is reasonable. If not, it will then be easier to tweak more since the app deployment will be much more simple.

Comment 10

[Jennifer Bertsch [:jbertsch]]

Pmac - Can we resolve this one now?

Comment 11

[Gervase Markham [:gerv]]

The new flow is:

* Browser does get for "/" on mozilla.org via HTTP
* 301 Moved Permanently. Location: https://www.mozilla.org/
* Browser does get for "/" on www.mozilla.org via HTTPS 
* 301 Moved Permanently. Location: https://www.mozilla.org/en-GB/
* Browser does get for "/en-GB/" on www.mozilla.org via HTTPS
* 200 OK. Wahey!

So 2 redirects, involving 3 fetches. It would be nice to get it down to 1, but this is better.

Gerv

Comment 12

[Paul [:pmac] McLanahan]

I think this is about as good as we can get at the moment. Currently the servers responding to mozilla.org are different from those at www.mozilla.org, so that initial redirect can't really be improved right now. It's possible we could combine them at some point in the future, but I agree that we can resolve this for now and improve it again later when our architecture is a bit more settled.