Either the "Redirect" directives in mozilla-org/html/support/.htaccess should be deleted or this should somehow be made to work correctly. Despite the obvious intent of that .htaccess file, the web site does *not* redirect you if you visit any of those URLs: http://www.mozilla.org/support/adblock.html Weirdly, similar Redirect directives elsewhere in the tree seem to work; see mozilla-org/html/bugs/.htaccess and then visit: http://www.mozilla.org/bugs/changes.html You'll be redirected to a page on www.bugzilla.org.
It looks like all of the rules in mozilla-org/html/bugs/.htaccess are duplicated in mozilla-org/html/.htaccess but not the rules in mozilla-org/html/support/.htaccess . That would account for the discrepancy in efficacy.
And here's the explanation: > The old URL-path is a case-sensitive (%-decoded) path beginning with > a slash. A relative path is not allowed. The new URL should be an > absolute URL beginning with a scheme and hostname, but a URL-path > beginning with a slash may also be used, in which case the scheme > and hostname of the current server will be added. from http://httpd.apache.org/docs/2.0/mod/mod_alias.html#redirect So, the /bugs and /support rules are ignored because the oldurl params aren't absolute. (the docroot's rules are absolute)
Aha. There are ten .htaccess files that contain bogus Redirects. In these 6 files, all the bogus Redirects are reproduced in non-bogus form either in the same file or somewhere else in the tree, except for the one marked *** below. - access/.htaccess (lines 2, 3, 6, 7, 10, 12, 13, 16, 17) - access/samples/.htaccess (lines 8 and 9 ***but look at line 8 and then look at line 10--they redirect to different places) - access/unix/.htaccess (lines 1, 2) - bugs/.htaccess (lines 1-3) - catalog/end-user/.htaccess (line 1) - docs/netlib/.htaccess (line 1) Each of these 2 files seems to be entirely redundant, because a higher-level redirect hides the whole directory. I think these files can just be "cvs remove"d. - download/.htaccess - products/mozilla1.x/download/.htaccess In these 2 files, there are bogus Redirects that I can't find in non-bogus form anywhere. - docs/dom/domref/.htaccess (line 3) - support/.htaccess (lines 3-12)
We'd like to start redirecting the support/firefox/ stuff to support.mozilla.com equivalents. If I understand the comments on this bug correctly, I'd have to put something like: Redirect permanent http://www.mozilla.org/support/firefox/options http://support.mozilla.com/kb/Options+window Is that correct?
Well... not quite. The first URL must start with a slash, like this: Redirect permanent /support/firefox/options http://support.mozilla.com/kb/Options+window ...only all on one line.
Seems to to work with /support/firefox/options.html, but not /support/firefox/options . <https://doctor.mozilla.org/?action=edit&file=mozilla-org/html/support/.htaccess>
I'm at a loss. Someone on freenode blames MultiViews, which almost makes sense, but then I would expect content, not a 404.
What functionality is lost by removing "Options +MultiViews"? I removed it, and the http://www.mozilla.org/support/firefox/options redirect is working.
I put it back. Turns out it broke all other URLs without ".html".
Product: mozilla.org → Websites
This is related to bug 408380. However, I think not only do the entries access/unix/.htaccess (lines 1, 2) need to be removed as was suggested previously, but the files that were migrated need to be removed as well. (In reply to comment #3) > Aha. There are ten .htaccess files that contain bogus Redirects. > In these 6 files, all the bogus Redirects are reproduced in non-bogus form > either in the same file or somewhere else in the tree, except for the one > marked *** below. > - access/.htaccess (lines 2, 3, 6, 7, 10, 12, 13, 16, 17) > - access/samples/.htaccess (lines 8 and 9 ***but look at line 8 and then look > at line 10--they redirect to different places) > - access/unix/.htaccess (lines 1, 2) > - bugs/.htaccess (lines 1-3) > - catalog/end-user/.htaccess (line 1) > - docs/netlib/.htaccess (line 1) > Each of these 2 files seems to be entirely redundant, because a higher-level > redirect hides the whole directory. I think these files can just be "cvs > remove"d. > - download/.htaccess > - products/mozilla1.x/download/.htaccess > In these 2 files, there are bogus Redirects that I can't find in non-bogus form > anywhere. > - docs/dom/domref/.htaccess (line 3) > - support/.htaccess (lines 3-12)
Created attachment 382996 [details] [diff] [review] Fixes redundant redirects in /access/.htaccess /access/.htaccess has some redundant redirects which do not work. This patch removes these, and in addition the following files must be removed or the redirects that remain will not work. Here is a list of files which must be removed: /access/xul-guidelines.html /access/dynamic-content.html /access/keyboard/tabindex.html /access/projects.html
There is a redirect for http://www.mozilla.org/access/samples/js-nsIAccessible.htm. In the .htaccess, there are two different URL's it is configured to redirect to. Which is the correct one, once I know I can fix the redirects in this. http://www.mozilla.org/access/qa/jstest.html http://support.mozilla.com/kb/Assistive+technology+compatibility
I just reread through the bug and it seems like there are two separate issues here. 1. The redirects in the Support directory aren't working correctly. 2. There are several .htaccess files across the site that contain bogus Redirects. (See comment #3 for details) If this is correct, I'd suggest opening a separate bug for cleaning up bogus redirects in general to avoid confusion (such as how broken redirects in the access directory are, or aren't, breaking things in the support directory).
Note that the discussion of redundant redirects outside of the support directory has been moved to bug 498666. cilias, are there redirects for support pages that are still not working correctly?
(In reply to comment #15) > cilias, are there redirects for support pages that are still not working > correctly? Support redirects are working.
Glad to hear support redirects are working. cilias, are you fine with closing this bug or is there anything else to do here?
I'm fine with closing it. Jason Orendorff filed it though. Jason, does this bug looked fixed to you?
Totally. However, take another look at comment 3--unless someone has fixed those up, there are still have some bogus directives in the tree that don't do anything, which is I guess not ideal.
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → FIXED
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.