394232 - .htaccess file in www.mozilla.org/support tries to redirect stuff, but it doesn't work

Status: RESOLVED FIXED

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

Description

[Jason Orendorff [:jorendorff]]

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.

Comment 1

[Jeremy Baron]

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.

Comment 2

[Jeremy Baron]

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)

Comment 3

[Jason Orendorff [:jorendorff]]

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)

Comment 4

[Chris Ilias [:cilias]]

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?

Comment 5

[Jason Orendorff [:jorendorff]]

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.

Comment 6

[Chris Ilias [:cilias]]

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>

Comment 8

[Jason Orendorff [:jorendorff]]

I'm at a loss.  Someone on freenode blames MultiViews, which almost makes sense, but then I would expect content, not a 404.

Comment 9

[Chris Ilias [:cilias]]

What functionality is lost by removing "Options +MultiViews"? I removed it, and the http://www.mozilla.org/support/firefox/options redirect is working.

Comment 10

[Chris Ilias [:cilias]]

I put it back. Turns out it broke all other URLs without ".html".

Comment 11

[franklin]

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)

Comment 12

[franklin]

Attachment: 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

Comment 13

[franklin]

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

Comment 14

[David Boswell]

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).

Comment 15

[David Boswell]

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?

Comment 16

[Chris Ilias [:cilias]]

(In reply to comment #15)
> cilias, are there redirects for support pages that are still not working
> correctly?

Support redirects are working.

Comment 17

[David Boswell]

Glad to hear support redirects are working.  cilias, are you fine with closing this bug or is there anything else to do here?

Comment 18

[Chris Ilias [:cilias]]

I'm fine with closing it. Jason Orendorff filed it though. Jason, does this bug looked fixed to you?

Comment 19

[Jason Orendorff [:jorendorff]]

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.

Comment 20

[David Boswell]

Re comment #19, those bogus redirects are being tracked in bug 498666.