491731 - Add redirects to deal with Firefox-related 404 errors

Status: RESOLVED FIXED

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

Description

[David Boswell]

The following report just recently came in on the webmaster at mozilla dot org address.  Not sure if this is a bug for www.mozilla.com or Firefox, so please feel free to reassign if I put it in the wrong place.

"I apologise if you've had this reported a hundred times before, but whenever I upgrade Firefox to the new version (e.g. 3.0.10) I end up at a "404: File Not Found" error for the following URL:

http://www.mozilla.org/projects/firefox/3.0.10/firstrun/

This happened for 3.0.9 as well (possibly others but, meh, I forget) and it affects both my Windows box at work and my Linux box at home (and other Linux/Windows boxes I maintain)."

The weird thing about the reported URL is that it is pointing to mozilla.org, but even if you replace .org with .com it brings up a 404 error on mozilla.com as well.

Comment 1

[Samuel Sidler (old account; do not CC)]

The URL they *should* be seeing is:

http://www.mozilla.com/firefox/3.0.10/firstrun/

I'm not sure why anyone would see a mozilla.org URL.

Comment 2

[:Gavin Sharp [email: [e-mail]]]

That URL matches what we use in unbranded builds, I think. Perhaps he's getting his build from somewhere crazy.

Comment 3

[:Gavin Sharp [email: [e-mail]]]

Yeah:
http://mxr.mozilla.org/mozilla/source/browser/app/firefox-branding.js#2

Comment 4

[David Boswell]

Maybe this is a separate bug, but if that reported URL is used in unbranded
builds, should there be a page on mozilla.org for those users to avoid
confusion about missing pages and to talk about advantages/disadvantages of
unbranded builds?

Comment 5

[:Gavin Sharp [email: [e-mail]]]

Generally we haven't bothered adding those pages, since the target audience is so small. But a redirect for all versions might be a good idea.

Comment 6

[David Boswell]

CC'ing John Slater.  Even if this is now a www.mozilla.org bug, I assume John
will want to have input into what these users should be seeing since the person
who sent the original email was assuming this was a bug in Firefox.

Comment 7

[David Boswell]

Changing component back to www.mozilla.org.  Accidentally switched it on last update.

Comment 8

[Samuel Sidler (old account; do not CC)]

We should direct the user to download an official build, but otherwise I wouldn't worry about it.

Comment 9

[David Boswell]

I'll respond back to the person who emailed and suggest he use an official build and will ask where he got the one he's using.  I'll leave it to someone else to wontfix this if we shouldn't worry about it for other users.

Comment 10

[Reed Loden [:reed]]

This a dupe.

Comment 11

[Robert Kaiser]

bug 381734 is about /whatsnew but /firstrun is probably similar...

Comment 12

[David Boswell]

FYI, this person replied: I'm using the build that ships with Kubuntu (9.04 Jaunty Jackalope). This looks like a normal branded Firefox to me, it's definitely not one of the Debian Ice Weasel builds.

Comment 13

[David Boswell]

Re comment #11, bug 381734 is about links in pre-release versions of Firefox.  This bug is about a bug with a released version.  FWIW, another person just emailed webmaster at mozilla dot org with a seemingly similar error:

404: File Not Found

/projects/firefox/3.0.10/whatsnew/

We are sorry, the file you requested could not be found.

----

Since the beginning of Firefox 2.0, every single release has had a 404 webpage and this is the page presented to the user on their first startup.

Why would you do this?

Comment 14

[David Boswell]

I just checked the www.mozilla.org stats and saw that the http://www.mozilla.org/projects/firefox/3.0.10/firstrun/ page had 3,387 views from 4/30/2009 - 5/6/2009.  This is more than a handful of people.  Instead of a 404 error, would it be better to redirect them to the relevant .com pages or set up separate pages on .org?

Comment 15

[Robert Kaiser]

David, I suspect that some older Firefox (alpha/beta?) versions actually had firstrun pages at http://www.mozilla.org/projects/firefox/%VERSION%/firstrun/ and the pref files of people with so old profiles may still contain such a pref.

Comment 16

[David Boswell]

Re comment #15, that may be the case, but it also looks like Firefox users on Linux are also getting directed to .org instead of .com.  See comment #12 -- the person who sent the original email mentioned in this bug is using the version that ships with Kubuntu.  Regardless, why wouldn't we do something with those links?

Comment 17

[David Boswell]

Just to clarify my last comment, I should have said that some subset of Linux users are getting directed to .org instead of .com.  I just tested the Firefox that ships with Ubuntu and was redirected to the Ubuntu site for release notes.  Each distribution probably handles this in a different way.

Comment 18

[franklin]

I can set up an .htaccess redirect for this to fix the problem.  That should be easy enough and should solve the 404 errors.

Comment 19

[David Boswell]

Franklin, great.  This would be a big help since there are a lot of people getting 404 errors.  For more specifics about the number of errors and the types of URLs we'll need to redirect, take a look at the firefox404errors tab on this spreadsheet:

http://spreadsheets.google.com/ccc?key=rL83qEekHMrV0kk0g9hCujA

Any redirect would need to cover a range of releases and also several different pages.  For example:

/projects/firefox/3.0.10/firstrun/
/projects/firefox/2.0.0.1/releasenotes/
/projects/firefox/3.0.1/whatsnew/

Note that there are also errors for pre-release versions of Firefox.  The released versions can point to the relevant pages on mozilla.com but the pre-release versions should point to a different page (see bug 381734 for details).  An example of a pre-release URL is:

/projects/firefox/3.6a1pre/whatsnew/

If it would be better to deal with both types of redirects together, I can combine the bugs.

Comment 20

[franklin]

I went through the spreadsheet and have updated the following links...  Also, for the pre-release I had them point to the page mentioned in bug 381734 (www.mozilla.org/projects/firefox/prerelease.html).  I will be submitting a patch shortly.

/projects/firefox/3.0.10/firstrun/|
/projects/firefox/2.0.0.13/firstrun/|
/projects/firefox/3.0.10/whatsnew/|
/projects/firefox/3.5b5pre/whatsnew/|
/projects/firefox/2.0.0.1/whatsnew/|
/projects/firefox/4.0a1pre/whatsnew/|
/projects/firefox/4.0a1pre/firstrun/|
/projects/firefox/3.6a1pre/firstrun/|
/projects/firefox/3.0.8/firstrun/|
/projects/firefox/3.5b4/whatsnew/|
/projects/firefox/3.0.11pre/firstrun/|
/projects/firefox/3.0.11pre/whatsnew/|
/projects/firefox/3.0.8/whatsnew/|
/projects/firefox/2.0.0.14/firstrun/|
/projects/firefox/3.5b5pre/firstrun/|
/projects/firefox/3.1b3pre/whatsnew/|
/projects/firefox/3.0.9/whatsnew/|
/projects/firefox/3.5b4pre/firstrun/|
/projects/firefox/3.2a1pre/whatsnew/|
/projects/firefox/3.0a6pre/whatsnew/|
/projects/firefox/2.0.0.7/firstrun/|
/projects/firefox/2.0.0.4pre/firstrun/|
/projects/firefox/3.0.7/whatsnew/|
/projects/firefox/3.0.10pre/whatsnew/|
/projects/firefox/3.5b4/firstrun/|
/projects/firefox/3.0.3pre/whatsnew/|
/projects/firefox/3.0.4pre/whatsnew/|
/projects/firefox/2.0/whatsnew/|
/projects/firefox/3.1b2pre/whatsnew/|
/projects/firefox/3.1b2/firstrun/|
/projects/firefox/3.0.6/whatsnew/|
/projects/firefox/3.0a2pre/firstrun/|
/projects/firefox/3.0.6/firstrun/|
/projects/firefox/3.0a3pre/firstrun/|
/projects/firefox/3.0/whatsnew/|
/projects/firefox/3.0.1/whatsnew/|
/projects/firefox/3.0a4pre/firstrun/|
/projects/firefox/3.0a6pre/firstrun/|
/projects/firefox/3.1b3pre/firstrun/|
/projects/firefox/2.0.0.12/firstrun/|
/projects/firefox/3.1b3/whatsnew/|

Comment 21

[franklin]

Attachment: Mods to projects/firefox htaccess for redirects

I added some entries to te .htaccess under html/projects/firefox/ to fix the pages listed in the 404 report.

Comment 22

[Robert Kaiser]

Does this obsolete bug 381734 now?

Also, we should not need to add every new version explicitely, as that means we'll always fail for some time when the versions are changed until someone remembers to add the new version to this list of redirects. Can't we do some regex that applies to all version numbers we use and therefore make this future-proof?

Comment 23

[franklin]

I'll work on a more permanent solution.  I'm not sure if this obsoletes 381734 yet since the pre-release page still needs to be published to clear up the pre-release 404s.  This fix was only redirects the pre-release URLs to the correct page (as mentioned in 381734).

Comment 24

[Robert Kaiser]

As you're including *pre/whatsnew/ in this fix, you're including the cases mentioned in bug 381734 - which is fine, this is all long-standing, annoying problems that ought to be fixed once and for all. :)

Comment 25

[franklin]

Is there a pattern to when these URL's redirect to mozilla.com rather than redirect to mozilla.org?  For example, redirect from mozilla.org/.../whatsnew to mozilla.org/.../firstrun

I was able to resolve the redirects between mozilla.org to mozilla.com and the prerelease versions; however, I'm having some difficulty with the scenario when we're going from /whatsnew to /firstrun.

Here's the path I was heading down:

RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule   ^([^/]+)pre/firstrun  http://www.mozilla.org/projects/firefox/prerelease.html [R]

RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule   ^([^/]+)pre/whatsnew  http://www.mozilla.org/projects/firefox/prerelease.html [R]

RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule   ^([^/]+)/whatsnew    http://www.mozilla.com/firefox/$1/whatsnew  [R]

RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule   ^([^/]+)/firstrun    http://www.mozilla.com/firefox/$1/firstrun  [R]

Comment 26

[David Boswell]

If we're unsure when there will be release notes for a given release on mozilla.org, maybe we could piggyback on what we did for the automate archive redirects?  That only redirects someone if there isn't a page or another redirect for a URL.  Could we update the script to redirect these Firefox-related pages only if there isn't an existing page?

http://mxr.mozilla.org/mozilla-org/source/html/missing.pl

Comment 27

[David Boswell]

Updating bug summary to reflect current goals for this bug to add redirects for Firefox-related 404 errors (both for pre-release builds and released builds).

Comment 29

[franklin]

I took a look at the perl script and am not sure it would quite do what we need, since the version will always be changing, and we're looking for a different filename from what is being requested.  I'm trying to see if I can mimic the behavior that you described with a rewrite condition.

Comment 30

[franklin]

I think I got this worked out as we discussed here.  

I did notice that one of the existing redirects points to a file with a 403: Redirect permanent /projects/firefox/3.0a8pre/ http://www.mozilla.org/projects/firefox/3.0a8/

There are a couple of redirects that didn't quite follow the patterns we discussed here, so I had to move those around.

I'll have to post a patch later on tonight when I get a chance.  For now here's what I've come up with...

#check for if this is a whatsnew URL
RewriteCond %{REQUEST_URI} ^/projects/firefox/([^/]+)/whatsnew.*
#if this is a whatsnew url, check if the directory exists
RewriteCond %{DOCUMENT_ROOT}/projects/firefox/%1/whatsnew !-d
#if the directory doesn't exist, check if a firstrun/index.html exists
RewriteCond %{DOCUMENT_ROOT}/projects/firefox/%1/firstrun/index.html -f
#if the firstrun exists go ahead and rewrite the URL to the firstrun
RewriteRule ^([^/]+)/whatsnew    http://www.mozilla.org/projects/firefox/%1/firstrun/index.html [R]

#rewrites pre release firstruns to the local prerelease.html
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule   ^([^/]+)pre/firstrun  http://www.mozilla.org/projects/firefox/prerelease.html [R]

#rewrites pre release whatsnew to the local prerelease.html
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule   ^([^/]+)pre/whatsnew  http://www.mozilla.org/projects/firefox/prerelease.html [R]

#rewrites whatsnew to mozilla.com
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule   ^([^/]+)/whatsnew    http://www.mozilla.com/firefox/$1/whatsnew  [R]

#rewrites firstrun to mozilla.com
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule   ^([^/]+)/firstrun    http://www.mozilla.com/firefox/$1/firstrun  [R]

Comment 31

[David Boswell]

Great.  Once you have a patch, we'll get this reviewed.

One question for now, will the redirects in #30 cover people with released versions who are looking for the release notes?  For example:

/projects/firefox/3.0.10/releasenotes/

Comment 32

[franklin]

Attachment: Patch to fix redirects

Here's the patch, it should solve the issues with the whatsnew, releasenotes, pre release pages, and firstrun redirects.

Comment 33

[David Boswell]

Comment on attachment 382961 [details]
Patch to fix redirects

Reed, could you please review this when you have a chance?  Thanks.

Comment 37

[David Boswell]

Raising priority.

Comment 39

[fantasai]

Looks good to me, I'd just remove the 'index.html' from the [R] redirect.

Comment 46

[David Boswell]

Two more dupes of this bug have come in today.  Is there any way we can escalate this so the patch can get reviewed and checked in?

Comment 47

[David Boswell]

I've decided to go ahead and check this patch in tomorrow instead of waiting for another review.  If I break the site in the process, I'll back it out.

Comment 48

[David Boswell]

I just tested

http://www.mozilla.org/projects/firefox/3.0.10/firstrun/

and it redirects to

http://www.mozilla.com/en-US/firefox/3.0.10/firstrun/

which is definitely a good thing.

I want to go back and check all dupes to make sure they're no longer 404s, but things look good so far.

Thanks franklin for the patch and I apologize it took a while to get it checked-in.

Comment 49

[David Boswell]

Closing as fixed.  

I spot checked most of the dupes in this bug and those URLs are now working correctly.  I've also checked the site logs and no more release related URLs are showing up in the 404 error list.  Lastly, the new prerelease.html page was the 10th most viewed page on the first weekday after the patch was checked in.  That's all to say that this seems to be working correctly.