Closed Bug 266816 Opened 20 years ago Closed 20 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: 20 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.