Closed Bug 491731 Opened 13 years ago Closed 13 years ago

Add redirects to deal with Firefox-related 404 errors


( :: General, defect, P1)


(Not tracked)



(Reporter: davidwboswell, Assigned: franklin_yamamoto)





(2 files)

The following report just recently came in on the webmaster at mozilla dot org address.  Not sure if this is a bug for 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:

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, but even if you replace .org with .com it brings up a 404 error on as well.
The URL they *should* be seeing is:

I'm not sure why anyone would see a URL.
That URL matches what we use in unbranded builds, I think. Perhaps he's getting his build from somewhere crazy.
Component: →
QA Contact: www-mozilla-com → www-mozilla-org
Maybe this is a separate bug, but if that reported URL is used in unbranded
builds, should there be a page on for those users to avoid
confusion about missing pages and to talk about advantages/disadvantages of
unbranded builds?
Component: →
QA Contact: www-mozilla-org → www-mozilla-com
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.
Component: →
QA Contact: www-mozilla-com → www-mozilla-org
CC'ing John Slater.  Even if this is now a 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.
Component: →
QA Contact: www-mozilla-org → www-mozilla-com
Changing component back to  Accidentally switched it on last update.
Component: →
QA Contact: www-mozilla-com → www-mozilla-org
We should direct the user to download an official build, but otherwise I wouldn't worry about it.
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.
This a dupe.
Whiteboard: DUPEME
bug 381734 is about /whatsnew but /firstrun is probably similar...
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.
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


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?
I just checked the stats and saw that the 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?
David, I suspect that some older Firefox (alpha/beta?) versions actually had firstrun pages at and the pref files of people with so old profiles may still contain such a pref.
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?
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.
I can set up an .htaccess redirect for this to fix the problem.  That should be easy enough and should solve the 404 errors.
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:

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


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


If it would be better to deal with both types of redirects together, I can combine the bugs.
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 (  I will be submitting a patch shortly.

I added some entries to te .htaccess under html/projects/firefox/ to fix the pages listed in the 404 report.
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?
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).
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. :)
Is there a pattern to when these URL's redirect to rather than redirect to  For example, redirect from to

I was able to resolve the redirects between to 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 [R]

RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule   ^([^/]+)pre/whatsnew [R]

RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule   ^([^/]+)/whatsnew$1/whatsnew  [R]

RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule   ^([^/]+)/firstrun$1/firstrun  [R]
If we're unsure when there will be release notes for a given release on, 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?
Whiteboard: DUPEME
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).
Summary: Reported 404 error for Firefox first run page after an upgrade → Add redirects to deal with Firefox-related 404 errors
Duplicate of this bug: 381734
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.
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/

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 [R]

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

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

#rewrites whatsnew to
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule   ^([^/]+)/whatsnew$1/whatsnew  [R]

#rewrites firstrun to
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule   ^([^/]+)/firstrun$1/firstrun  [R]
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:

Attached file Patch to fix redirects
Here's the patch, it should solve the issues with the whatsnew, releasenotes, pre release pages, and firstrun redirects.
Attachment #382961 - Flags: review?(reed)
Comment on attachment 382961 [details]
Patch to fix redirects

Reed, could you please review this when you have a chance?  Thanks.
Duplicate of this bug: 501474
Duplicate of this bug: 501594
Duplicate of this bug: 504254
Raising priority.
Priority: -- → P1
Duplicate of this bug: 455427
Looks good to me, I'd just remove the 'index.html' from the [R] redirect.
Duplicate of this bug: Shiretoko
Duplicate of this bug: 513672
Duplicate of this bug: 513862
Duplicate of this bug: 514121
Assignee: nobody → reed
OS: Mac OS X → All
Hardware: x86 → All
Duplicate of this bug: 515607
Duplicate of this bug: 515738
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?
Severity: normal → major
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.
I just tested

and it redirects to

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.
Assignee: reed → franklin_yamamoto
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.
Closed: 13 years ago
Resolution: --- → FIXED
Component: → General
Product: Websites →
You need to log in before you can comment on or make changes to this bug.