Closed Bug 731876 Opened 12 years ago Closed 12 years ago

Please add some MathML redirects

Categories

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

x86_64
Linux
defect
Not set
normal

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: karlt, Assigned: jlong)

References

Details

Attachments

(1 file)

The proposed patch is for svn+ssh://svn.mozilla.org/projects/mozilla.com/trunk

I don't have commit access to this repository, so please review and commit.
Attachment #601829 - Flags: review?(jlong)
Unfortunately it seems like Apache isn't like using the org-urls-301 file with the xhtml file type. It might see it as a static resource and is simply serving it up for some reason. The redirect does not work.

Can you convert them into normal RewriteRule's? Additionally, do you have mozilla.com running locally and can test them?

Thanks!
Attachment #601829 - Flags: review?(jlong) → review-
Comment on attachment 601829 [details] [diff] [review]
move MathML pages from xhtml to html so that entities do not depend on a DTD and move demo index to MDN r=fred.wang@free.fr b=728725

(In reply to James Long (:jlongster) from comment #1)
> Unfortunately it seems like Apache isn't like using the org-urls-301 file
> with the xhtml file type. It might see it as a static resource and is simply
> serving it up for some reason. The redirect does not work.

Did you test this for any xhtml files that have been removed?

Many of these xhtml files still exist (because the redirects are not yet in place) and so the org-urls-301 map will not be used until the files are removed.
http://viewvc.svn.mozilla.org/vc/projects/mozilla.com/trunk/.htaccess?view=markup#l641

> Additionally, do you have
> mozilla.com running locally and can test them?

I don't have mozilla.com running locally.

If that is a requirement, can you link to the configuration files, please?
Attachment #601829 - Flags: review- → review?(jlong)
I was checking it like that, and it wasn't redirecting. I played around with the htaccess file some more and fixed it. It was conflicting with other parts of the htaccess so wasn't working properly.

Should be working now though. Can you test on http://www-dev.allizom.org/ ? I have not pushed this live yet, please verify it first.
Assignee: nobody → jlong
Target Milestone: --- → 1.10
Target Milestone: 1.10 → 2.0
(In reply to James Long (:jlongster) from comment #3)
> It was conflicting with other
> parts of the htaccess so wasn't working properly.

I don't follow why
RewriteCond %{DOCUMENT_ROOT}/org%{REQUEST_URI} -f
would match a file that has been removed,
but thanks very much for sorting this out.

I tested on http://www-dev.allizom.org/ and the redirects are working as intended thanks.
They are actually effective even for files that still exist.
Thats fine with me, but the
RewriteCond %{REQUEST_FILENAME} !-f
lines may need adjusting to be effective.
That's not the line that does the redirects. You put redirects in the org-urls-301 file, which is pulled in with this:

RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond ${org-urls-301:$1} >""
RewriteRule ^(.*)$ ${org-urls-301:$1} [R=301,L]
I assume the block was moved because of

RewriteCond %{REQUEST_URI} .*\.(css|png|jpg|jpeg|pdf|csv|xsl|crt|xml|xhtml|txt)
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{DOCUMENT_ROOT}/org%{REQUEST_URI} -f
RewriteRule ^(.*)$ /org/$1 [L]

but I don't understand why the org-urls-301 rule needs to be before that (for files that don't exist).
Also, the org-url-301 rule is causing redirects in situations where the files do exist, but the rule looks designed to avoid that.
Attachment #601829 - Flags: review?(jlong)
It was moved up because the rule in comment 6 catches all xhtml extensions and serves them up as static files. If the redirects need to catch that, it need to be before it.

The lines to check of the files/dirs exist won't work because it needs to check in the /org folder. I'm not sure if that was the intention of that line, but it probably was. Are you sure that it should only redirect if the file doesn't exist?
(In reply to James Long (:jlongster) from comment #8)
> It was moved up because the rule in comment 6 catches all xhtml extensions
> and serves them up as static files.

Yes, but only it only catches when the files still exist, IIUC.

> If the redirects need to catch that, it need to be before it.

I expect I only need these particular redirects to be effective once files have been removed. (Removing some of the files is waiting for the redirects to be in place.)

(In reply to James Long (:jlongster) from comment #8)
> The lines to check of the files/dirs exist won't work because it needs to
> check in the /org folder. I'm not sure if that was the intention of that
> line, but it probably was. Are you sure that it should only redirect if the
> file doesn't exist?

No, I'm not sure.  I'm just guessing because I can't think of any other reason for that line to be there.  However, if the rule has never been effective, then it may not be worth the risk of enabling it now.

I had to use some plain rewrite rules for directories that will continue to exist because I thought the map was intended to work this way.  (Bug 728725 comment 10)
I expect the map would have been more efficient, so that may be another reason for not fixing the !-f line.

The main reason I'm commenting is that there may be a change in behaviour with moving the rule in comment 6:  Previously it took precedence over subsequent redirects if the files still existed; now it won't.  That change may be perfectly fine.
So basically: the rewrites to serve static files triggers if the file exists (for several type like xhtml). And after that, it redirects everything in the org-urls-301.

I actually think the !-f lines are there to protect the mozilla.org/firefox side of things. That site (used to be mozilla.com) is the primary codebase and that's what those rules match against (the org codebase resides in /org so those rules would bee that prefix). Bottom line: nothing in the 301 file should redirect an existing mozilla.org/firefox page.

Anyway, we're bike-shedding now, so let's put it back the way it was and just add the redirects for files that will be missing. Is the patch still up-to-date? It won't redirect xhtml files that exist.
(In reply to James Long (:jlongster) from comment #10)
> I actually think the !-f lines are there to protect the mozilla.org/firefox
> side of things.

Ah, OK, that makes sense.

> Anyway, we're bike-shedding now, so let's put it back the way it was and
> just add the redirects for files that will be missing. Is the patch still
> up-to-date?

If you are going to back out r102641, then the patch should apply fine, thanks.
There haven't been any substantial changes to these files.
I don't have any further redirect changes to make at this stage.

> It won't redirect xhtml files that exist.

That should be fine.  I plan to remove them.
Committed the original patch to dev. Test there and this will get pushed out next milestone (longer than usual because we're migrating some of the pages to Python right now).
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Whiteboard: r=103050 b=trunk
www-dev.allizom.org seems to be working as expected, thanks.

If I were to make changes now to files in svn+ssh://svn.mozilla.org/projects/mozilla.org/trunk/ , then I guess they would go live before the mozilla.com changes do?
(If so, then I'll wait for the redirects to go live.)
(In reply to Karl Tomlinson (:karlt) from comment #13)
> www-dev.allizom.org seems to be working as expected, thanks.
> 
> If I were to make changes now to files in
> svn+ssh://svn.mozilla.org/projects/mozilla.org/trunk/ , then I guess they
> would go live before the mozilla.com changes do?
> (If so, then I'll wait for the redirects to go live.)

Yep, that's right, but I can go ahead and push this.
pushed live in r103126
Whiteboard: r=103050 b=trunk
qa-verified-trunk

www-dev.allizom.org/projects/inspector  
Location: https://developer.mozilla.org/En/DOM_Inspector

www-dev.allizom.org/projects/javaconnect
Location: http://developer.mozilla.org/en/JavaXPCOM


www-dev.allizom.org/projects/marketing  
Location: http://contribute.mozilla.org/Marketing

www-dev.allizom.org/projects/mathml   
Location: https://developer.mozilla.org/en/Mozilla_MathML_Project

www-dev.allizom.org/projects/mathml/screenshots
Location: https://developer.mozilla.org/en/Mozilla_MathML_Project/Screenshots

www-dev.allizom.org/projects/mathml/fonts      
Location: https://developer.mozilla.org/en/Mozilla_MathML_Project/Fonts

www-dev.allizom.org/projects/minefield   
Location: http://www.mozilla.org/projects/firefox/prerelease.html

www-dev.allizom.org/projects/minimo   
Location: https://wiki.mozilla.org/Mobile


www-dev.allizom.org/projects/namoroka
Location: http://www.mozilla.com/firefox/channel/

www.mozilla.org/projects/inspector  
Location: https://developer.mozilla.org/En/DOM_Inspector

www.mozilla.org/projects/javaconnect
Location: http://developer.mozilla.org/en/JavaXPCOM


www.mozilla.org/projects/marketing  
Location: http://contribute.mozilla.org/Marketing

www.mozilla.org/projects/mathml   
Location: https://developer.mozilla.org/en/Mozilla_MathML_Project

www.mozilla.org/projects/mathml/screenshots
Location: https://developer.mozilla.org/en/Mozilla_MathML_Project/Screenshots

www.mozilla.org/projects/mathml/fonts      
Location: https://developer.mozilla.org/en/Mozilla_MathML_Project/Fonts

www.mozilla.org/projects/minefield   
Location: http://www.mozilla.org/projects/firefox/prerelease.html

www.mozilla.org/projects/minimo   
Location: https://wiki.mozilla.org/Mobile


www.mozilla.org/projects/namoroka
Location: http://www.mozilla.com/firefox/channel/
Status: RESOLVED → VERIFIED
Component: www.mozilla.org/firefox → www.mozilla.org
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.

Attachment

General

Created:
Updated:
Size: