Per bug 398938 (this bug would likely have to be fixed first before the functionality is removed), we should remove the locale-specific subdomains from Mozilla.com URLs. I'll let others with more knowledge/insight comment further.

How does this bug differ from bug 398938?

First part of this was done in r18714.

Most of this patch is tabbing but this is still going to need some serious testing.

Can I get this -w'd, please?

Comment on attachment 355081 [details] [diff] [review] no more locale based urls er, sorry, I meant I'll review this one, but I'd like to see -w just for my reference.

Comment on attachment 355081 [details] [diff] [review] no more locale based urls >-RewriteRule ^(.*)$ /%1${toupper:%2}/$1 [R=permanent,L] >+RewriteRule ^(.*)$ http://%4/%1${toupper:%2}/$1 [R=permanent,L] Why force http:// here? Will this have any affect on somebody going to the site using https://? Wouldn't want to redirect anybody from https:// to http://.

I think it would but I don't think it's a big deal (it only affects https for hostnames with the locale in them). I'm open to alternatives.

(In reply to comment #8) > I think it would but I don't think it's a big deal (it only affects https for > hostnames with the locale in them). I'm open to alternatives. RewriteCond %{SERVER_PORT} 80 RewriteRule ^(.*)$ http://%4/%1${toupper:%2}/$1 [R=permanent,L] RewriteRule ^(.*)$ https://%4/%1${toupper:%2}/$1 [R=permanent,L] or RewriteCond %{ENV:HTTPS} on RewriteRule ^(.*)$ https://%4/%1${toupper:%2}/$1 [R=permanent,L] RewriteRule ^(.*)$ http://%4/%1${toupper:%2}/$1 [R=permanent,L]

We talked on IRC but I don't think we concluded anything. Anyway, rewriterules don't stack like that and the rewriteconds wouldn't affect the second rule at all. We could make it work if we duplicated all the rewritecond rules and added the ENV:HTTPS rule, but I was trying to avoid that.

What is the priority here? bug 505031 is a pretty serious problem in my opinion and needs to be fixed soon.

That does look bad and I wasn't aware of that bug. Long term fix: fix this bug Short term fix: pull up a *.www.mozilla.com site with a proper wildcard certificate. Suppose it depends on the ETA on this bug.

So can we get an ETA here? We really need bug 505031 fixed

I'll try to review this today.

bug 522864 is critical and depends on this, so that makes this critical.

(In reply to comment #14) > I'll try to review this today. Fell asleep accidentally last night, so I'll be reviewing the patch this afternoon in a few hours.

Comment on attachment 355081 [details] [diff] [review] no more locale based urls >+RewriteRule ^(.*)$ http://%4/%1${toupper:%2}/$1 [R=permanent,L] I still think we need to do something about this... What do you think? We could just go with comment #10 and duplicate the rules into two sections for HTTPS on and off unless you have a better idea. I do think we should stay on SSL if we can, though. My testing of the other code seems to be ok. Things are redirecting as I would think they would, which is good. I've tested a number of different situations that could occur. So, r=me if we can find a solution to the http:// issue in .htaccess.

Ok, this is in SVN in r53668. I duplicated the rules for SSL although we could probably do something cleaner with PHP (or maybe another way in the .htaccess). Anyway, I can't test the ssl<->non-ssl redirects on my dev box though so this needs to be tested on stage before going live. ->QA

I'm backing out the changes that landed to fix bug 524884.

(In reply to comment #19) > I'm backing out the changes that landed to fix bug 524884. You're backing out the .htaccess change that accidentally made its way to stage and production, you mean? The patch for this bug should still remain on trunk.

Yes, only backed out on production and stage.

QA, we need feedback on this

(In reply to comment #22) > QA, we need feedback on this Could you be more specific on what kind of feedback you need?

Talked to Wil on IRC; we need to make sure things like: http://en-us.www-trunk.stage.mozilla.com/en-US/firefox/3.5.3/firstrun/ http://sv-SE.www-trunk.stage.mozilla.com/en-US/firefox/3.5.3/firstrun/ (for What's New, Release Notes, First Run, and the Getting Started pages, at least (http://sv-SE.www-trunk.stage.mozilla.com/en-US/firefox/central)). Let's test this for at least the top 5 locales. Vishal/Raymond, you in?

I pasted the wrong links, obviously; they shouldn't have /en-US/ after them. So, this is broken: http://sv-se.www-trunk.stage.mozilla.com/firefox/3.5.3/firstrun/ redirects you to https://www-trunk.stage.mozilla.com/en-US/firefox/3.5.3/firstrun/, which is just wrong.

(In reply to comment #25) > http://sv-se.www-trunk.stage.mozilla.com/firefox/3.5.3/firstrun/ redirects you > to https://www-trunk.stage.mozilla.com/en-US/firefox/3.5.3/firstrun/, which is > just wrong. However, https://sv-se.www-trunk.stage.mozilla.com/firefox/3.5.3/firstrun/ works fine redirecting to https://www-trunk.stage.mozilla.com/sv-SE/firefox/3.5.3/firstrun/ Is |SetEnv HTTPS on| present in the https vhost on stage? oremj?

> (In reply to comment #25) > Is |SetEnv HTTPS on| present in the https vhost on stage? oremj? No, right now the load balancer is pointed to port 80 for http and https. We'll need to: * point https traffic to port 81 on the webheads * set up a vhost for port 81 w/ SetEnv HTTPS on(In reply to comment #26)

(In reply to comment #27) > > (In reply to comment #25) > > Is |SetEnv HTTPS on| present in the https vhost on stage? oremj? > > No, right now the load balancer is pointed to port 80 for http and https. We'll > need to: > * point https traffic to port 81 on the webheads > * set up a vhost for port 81 w/ SetEnv HTTPS on(In reply to comment #26) Can we get that done so we can test this? One of the bugs dependent on this bug just got blocking‑firefox3.6+

For the record, this is backed out in favor of the patch on bug 505031