Closed Bug 823302 Opened 12 years ago Closed 12 years ago

[Bedrock] /b/ redirect for new /en-US/firefox/new-b/ page

Categories

(Infrastructure & Operations Graveyard :: WebOps: Other, task)

x86
macOS
task
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: cmore, Assigned: nmaul)

References

Details

We are going to be launching a new page that will at the following URL: https://www.mozilla.org/en-US/firefox/new-b/ The page is not on production yet, but it will be pushed this Thursday, December 20th in the AM. This page is for en-US only and thus all other locales should redirect to it. RewriteRule ^/en-US/firefox/new-b/(.*)$ /b/en-US/firefox/new-b$1 [PT] RewriteRule ^/(\w{2,3}(?:-\w{2}(?:-mac)?)?/)?firefox/new-b(.*)$ /en-US/firefox/new-b$2 [L,R=302] First dev, stage, and the demo servers. Ping in #www for us to verify and then we can give the green light for production.
Blocks: 814203
No longer depends on: 797236
This is committed to puppet for dev/demo and stage. It should be live within 30 minutes.
Assignee: server-ops-webops → nmaul
Some sort of redirect loop here, but I'm not sure where it's coming from. Here's a sample: curl -v 'https://www-demo2.allizom.org/firefox/new-b/' < HTTP/1.1 302 Found < Location: https://www-demo2.allizom.org/en-US/firefox/new-b/ curl -v 'https://www-demo2.allizom.org/en-US/firefox/new-b/' < HTTP/1.1 301 MOVED PERMANENTLY < Location: https://www-demo2.allizom.org//en-US/firefox/new-b/ curl -v 'https://www-demo2.allizom.org//en-US/firefox/new-b/' < HTTP/1.1 301 MOVED PERMANENTLY < Location: https://www-demo2.allizom.org//en-US/firefox/new-b/ The initial 302 is caused by the second new rule in comment 0... there's a tiny problem there, in that the trailing slash is handled oddly- it's not captured in the source (.*), and also not hard-coded in the destination. That'll lead to the slash being omitted, passing things like "firefox/new-bwhatever" to django instead of "firefox/new-b/whatever" on any sub-pages that are later created. But I think this is not relevant to the redirect loop. I note that the 302 (definitely from Apache / mod_rewrite) is in lower-case, and the 301 loop is in upper-case. I don't think Apache yells like that, which makes me suspect the 301 comes from somewhere else... django/mod_wsgi or even PHP. I get a 404 if I make requests like this: https://www-demo2.allizom.org/en-US/firefox/new-b/afsdfa https://www-demo2.allizom.org/en-US/firefox/new-b//afsdfa I get a 200 if I make requests like this: https://www-demo2.allizom.org/b/en-US/firefox/new-b/
I see a couple potential problems with the rules: RewriteRule ^/en-US/firefox/new-b/(.*)$ /b/en-US/firefox/new-b$1 [PT] This one captures after the final slash, but does not put the slash in the destination which could cause 404s. Should be: RewriteRule ^/en-US/firefox/new-b/(.*)$ /b/en-US/firefox/new-b/$1 [PT] Then this next one seems to be a loop as the rule would match itself, or even try to 302 to en-US when you came from en-US. RewriteRule ^/(\w{2,3}(?:-\w{2}(?:-mac)?)?/)?firefox/new-b(.*)$ /en-US/firefox/new-b$2 [L,R=302] I also think this one is superfluous as the l10n system will force en-US because no other lang files have been activated for this page's template. My suggestion is to fix the first rule and remove the 2nd.
Actually I'm wrong again. The rule should be: RewriteRule ^/(\w{2,3}(?:-\w{2}(?:-mac)?)?/)?firefox/new-b(.*)$ /b/$1firefox/new-b$2 [PT] This lets bedrock handle the locale redirecting and fixes the trailing slash mess.
Removed the original 2, committed the rule in comment 4 (to dev/demo and stage). Should be live in 30min or less.
Approved by :cmore and :pmac via IRC, deployed to prod.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Component: Server Operations: Web Operations → WebOps: Other
Product: mozilla.org → Infrastructure & Operations
Product: Infrastructure & Operations → Infrastructure & Operations Graveyard
You need to log in before you can comment on or make changes to this bug.