Closed Bug 266816 Opened 21 years ago Closed 21 years ago

4 pages using meta refreshes instead of HTTP redirects

Categories

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

defect
Not set
minor

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: aguertin+bugzilla, Assigned: nb)

Details

http://www.mozilla.org/raptor/, http://www.mozilla.org/quality/help/smoketest.html, http://www.mozilla.org/projects/intl/xul-styleguide.html, and http://www.mozilla.org/projects/intl/xul-l10n.html (covered by Bug 266575) all use meta refreshes to redirect people instead of standard HTTP redirects. http://www.mozilla.org/quality/help/smoketest.html is linked to by http://www.mozilla.org/quality/help/index-to-tests.html and http://www.mozilla.org/status/2000-03-30.html (an old status update) http://www.mozilla.org/projects/intl/xul-styleguide.html is linked to by http://www.mozilla.org/projects/seamonkey/release-notes/m13-detail.html (M13 release notes) The redirects should all be fixed, and the index-to-tests page should be fixed, but IMO the status update and release notes should be left as-is as they're historical (not sure what the policy on that is though)
Assignee: mozilla.webmaster → nbebout
fixed.
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
This checkin has overwritten revision 1.27 from dbaron. dbaron, you said /products/firefox/start/ shouldn't redirect (301) to /products/firefox/. Is that still correct?
No, it shouldn't redirect at all. (And when it did redirect, it should have been a temporary redirect, not a permanent one.)
If something like this happens again, nbebout's webtree cvs access is likely to be disabled. You should be much more careful when messing with high-profile pages.
I've put the .htaccess in the root directory into the restricted frontpages partition, so only people who can edit the homepage can edit it.
Another page in need of a proper redirect: mozilla-org/html/support/thunderbird/index.html (redirecting to http://texturizer.net/thunderbird/).
I assume you meant that 302 doesn't work, since "permanent" is 301. Well, if "temp" doesn't work, just use no keyword at all. And what I was referring to here was the fact that my checkin was backed out when landing another checkin because merge conflicts were resolved incorrectly (and in fact, some of the >>>>>> were initially checked in).
Product: mozilla.org → Websites
Component: www.mozilla.org → General
Product: Websites → www.mozilla.org
You need to log in before you can comment on or make changes to this bug.