Closed Bug 802789 Opened 12 years ago Closed 12 years ago

Old Firefox Start page (http://start.mozilla.org/firefox) 404s

Categories

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

defect
Not set
critical

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: stephend, Unassigned)

References

()

Details

See http://www.computeractive.co.uk/ca/pc-help/2214636/what-is-the-firefox-was-not-found-on-this-server-error

This is apparently hitting the PR circuit in some areas, so it'd be great to have it fixed ASAP...

Apparently, some people are getting taken to http://start.mozilla.org/firefox, which 404s.

http://start.mozilla.org, though, works, so maybe we can 302 anything after the /?
See Also: → 773654
See Also: → 758910
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → DUPLICATE
The issues in that bug was resolved and verified... we are suspecting this may be a regression of some kind. Reopening here for a little bit.


There are a lot of rules for this site already, a global 302 is probably not good. The problem is legacy... what start page you might got varied over the years, and included some bizarre things with respect to locales.

I'm going to assume for now though that we are dealing *only* with start.mozilla.org. This is inherently bad, but we have nothing else to go on. There is also <locale>.start.mozilla.com, start2.mozilla.com, etc... lots of things, that basically all redirect to start.mozilla.org in the end, but they try to preserve the original requested path. So if a user is actually requesting pt-br.start.mozilla.com/some/random/thing, they will get redirected to start.mozilla.org/some/random/thing. That was intentional.


So, looking *only* at start.mozilla.org, here are some of the relevant redirects/rewrites that it does:

# in case you don't specify a path, send you to en-US
# triggers if you came in without a subdomain on start.mozilla.org directly
RedirectMatch ^/$ http://start.mozilla.org/en-US/

# Firefox actually defaults to locale.start3.mozilla.com/firefox?stuff
# we try to redirect away from the /firefox, but apparently some things are still busted
# this is a hack to get them to the proper page, rather than 404
RedirectMatch ^/([a-z]{2,3}(-[a-zA-Z]{2})?)/firefox http://start.mozilla.org/$1/


So you can see we tried to work around this, and apparently didn't quite succeed... or did, and there's been a regression.


There is also this, though possibly not relevant here:

# We also get things like this occasionally (bug 773654, 758910):
# http://start.mozilla.org/firefox?client=firefox-a&rls=org.mozilla:en-US:official
# Should redirect these based on the locale in the string
# mod_alias can't deal with query strings, need to use mod_rewrite
RewriteEngine on
RewriteCond %{QUERY_STRING} ^client=firefox-a&rls=org\.mozilla:([a-z]{2,3}(-[a-zA-Z]{2})?):official$
RewriteRule ^/firefox/?$ http://start.mozilla.org/%1/? [R=301,L]


If someone can tell me what redirect is needed/missing/incorrect, we can put it into place very easily. :)
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
This is fixed now. Someone want to verify?
Status: REOPENED → RESOLVED
Closed: 12 years ago12 years ago
Resolution: --- → FIXED
Can we check the log files for start.mozilla.org for 404 errors and see what are the most common URLs being accessed that are 404s?

Jakem: What is the new rewrite rule that you put in place?
(In reply to Jake Maul [:jakem] from comment #4)
> This is fixed now. Someone want to verify?

I'm not getting any 404s now with or without the locale. Before you put the fix in, /en-us/firefox was redirecting to /en-us/ where as /firefox was 404'ing before. If could have locale detection/redirection.
I curl'd and manually tested with other locales, and valid /firefox and other, bogus paths, too, and it WFM now.  Would love to see the logs, as Chris requests, so we can also build out some automation and verify this more thoroughly.
The rewrite I put in places is:

    RewriteRule ^/firefox/?$ http://start.mozilla.org/? [R=301,L]


There is no locale detection.

Hits to http://start.mozilla.org/ (full-stop, no path or query string) are redirected to /en-us/, period.

Hits to http://start.mozilla.org/locale/firefox have the /firefox stripped.

Hits with a query string indicating a locale are redirected to proper page. So:
http://start.mozilla.org/firefox?client=firefox-a&rls=org.mozilla:en-US:official
redirects to:
http://start.mozilla.org/en-US/

Hits to <locale>.start.mozilla.com are redirected to start.mozilla.org/locale/.


That's about it. We rely 100% on the browser telling us via the host name or query string what their locale is, which is determined by what localization of Firefox they originally installed.
As for logfile 404's, here's a snippet of 1 hours' worth of log data for the site. Specifically, this is a count of how many things get what return code:

 317968 200
    910 206
  47945 301
    231 302
 101057 304
   6026 403
   5059 404

Of those 5059 404 return codes, 4/5ths of them were for favicon.ico, and a small number were for crossdomain.xml... neither of which is essential to seeing the page properly.

This gives us a total 404 volume of around 0.12%.


I can provide a complete log of 1 hour of data, if you like. Checking only the current 404's seems rather pointless... it makes at least as much sense to create tests for things that are *not* 404'ing currently, since those are the most common scenarios by far.

Let me know who I should send the logfile to for analysis. Note that it already goes to metrics, too... I don't know if they do anything with it though.
You need to log in before you can comment on or make changes to this bug.