From bug 394364: I would like for us to drop our geolocation garbage so we don't prefix all our websites with "ab-CD." (such as en-US.www.mozilla.com), as the same issue is being seen on https://en-us.www.mozilla.com for Safari users (and probably other browsers that aren't as lax as we are about this issue). The NetScaler doesn't take it into account at all when geo-loadbalancing currently, as it does its balancing based on the IP address requesting the site, which makes much more sense. Getting rid of the ab-CD portion in the subdomain would fix this issue, and it would fix a lot of other problems we've had in the past due to having to accommodate this useless part of the domain (such as swapping to the appropriate subdomain based on which part of the site you're using). If we decide (and I hope we do) to drop requiring the ab-CD part in the subdomain, we can drop the addition of it in all our products, too, as long as we set up redirects for *.www.mozilla.com to www.mozilla.com, which isn't hard at all. In relation to the NetScaler not caring about what hostname is used, mrz answered: "That's true but the original reason for doing $locale.www.mozilla.com was for future flexibility. Just because we use GSLB today doesn't mean we always will and this gives the ability to assign different IP addresses outside of GSLB." Since GSLB is the right way to go with this (doing checks based on _IP_ addresses the users come from instead of whatever hostname is used to connect to), I don't even see a reason to keep the locale-based subdomains around at all. Other companies don't use this format at all when needing to globally load-balance something, and it just seems unreasonable since one could easily be living in America but be using a German build that uses de.www.mozilla.com.

For the sake of backstory, the original reason this format was used is in bug 347944, comments #6 and #8. Also, I support dropping the locale-based subdomains.

So, I spoke with Justin today, and he said the decision probably rests with WebDev on this issue. I spoke with Wil later, and he said he's ok with the change but that other people should be involved. I'm adding people from bug 347944 to the CC list for comments. Fixing this bug would also take care of fixing bug 399148, as that would not be a problem anymore. As I mentioned in comment #0, I think removing the locale-based subdomains from the URI scheme for services is the way to go here, as it will ease up on the SSL problems due to wildcard certificates and also help to deal with bugs like bugs 385505, 378677, and 384082 (along with other issues we've had). These subdomains have been a real pain, and no actual gain or plus has been gathered from their inclusion besides the ability to assist in the future, but even that seems unlikely considering IP-based checking is much better at accurately picking the proper Netscaler to use to send traffic to that user rather than doing the matching based on what hostname somebody uses to get to the site. If this change is ok, I can deal with updating all the various products, various websites, and anything that uses the locale-based subdomains.

We went for the duplicate notion as a matter of precaution in our Toronto meeting, I recall that schrep made the call there. IIRC, it was a "yeah, it's redundant, but better safe than sorry". As for dropping the certificates, that will likely not be possible, we have those links in existing profiles, bookmarks.html, and we can't update those links. Well, "can't" is a big word, but it'd require time and code and time, or something. Let's move that out to a different bug. As for not doing that in the future, I'm fine with that, from a totally non-technical point of view, I think they're more in the way of my daily work than helping.

To be clear: I'd make this schrep's call.

I wouldn't worry about old bookmarks and things that use the locales in the FQDN. From looking at http://mxr.mozilla.org/mozilla/source/browser/locales/en-US/profile/bookmarks.html, it looks like only one of the links uses https:// with the URL, and that will actually work fine in Firefox since bug 159483 isn't fixed yet. However, it would be easy to change the related prefs for Firefox 2 and remove the "%LOCALE%." from the URLs. Besides that, I'm mostly concerned with moving forward. We'll have to support the locale-based subdomains forever since there are so many links in the wild, but we can have them just redirect to the normal version (e.g., en-us.www.mozilla.com to www.mozilla.com) instead of having to worry with the subdomain anymore.

Schrep, can you comment please?

I'm for removing the subdomains if there is no longer a need for it. But I'd like to see a plan for changing in product links that have that info, and we'll have to QA it properly before flipping the switch of course.

Note that, even if we switch new users to the non-locale domains, existing bookmarks would have the old domains and can't be upgraded (or at least, not in any straightforward manner).

As I mentioned in comment #5, I don't think we really need to worry about the bookmarks. There's only one https url in them that would be affected by the wildcard SSL certificate issue, and all the other urls in the bookmarks can just be made to redirect to the non-locale-based-subdomain way.

Are we (Justin/Mrz/Aravind/Wil/Axel) confident that we'll never want to do DNS-based geo-load balancing solutions? I ask because if we back this out of the product putting it back in will be significant work (and lag at least 6 months as people upgrade). I understand it is not pretty - but it is not clear to me what specific problem it is causing. Buying a second wilcard cert for amo does not seem to be a big deal - are there other issues I'm not seeing?

You'll also need a wildcard SSL cert for *.www.mozilla.com, too. Also, IT will need to generate more wildcard SSL certs for the staging environment to match all the possible combinations that we currently support. By cutting out the locale from the subdomain, we really ease the workload needed to support this fully. We (as Firefox users) don't see the badness caused by this (due to bug 159483), but for other browsers that correctly implement RFC 2818, we really hurt them since they fail to access pages that use an invalid wildcard SSL cert (e.g., using *.mozilla.com for en-us.www.mozilla.com).

Would require another IP address but that's not a real issue. As best as I can tell, none of the $locale.addons URLs are https (except one but that URL only works in < Fx2 (fails in IE7 & Safari)). Right now all the $locale.addons URLS redirect to https://addons.mozilla.org/$locale and that could someday be changed to https://addons-eu.mozilla.org/$locale. So maybe it depends on whether we'll ever have https://$locale.addons .

(In reply to comment #12) > Would require another IP address but that's not a real issue. Well, multiple IP addresses because of the staging environment. > So maybe it depends on whether we'll ever have https://$locale.addons . Well, we do treat it like we actually do that, though... See bug 384897. We use https://%LOCALE%.add-ons.mozilla.com/%LOCALE%/%APP%/%VERSION%/.../ for things inside the browser.

I am not 100% confident we'll never want to go back. This can be solved in one of two ways: 1) buy a *.www.mozilla.com and *.addons.mozilla.com cert (at a significant cost per year) 2) change the first run and mozilla-europe links which point to the localized hostnames (total of 3 which refer to https) Staging will continue to use internally generated certs.

(In reply to comment #14) > 2) change the first run and mozilla-europe links which point to the localized > hostnames (total of 3 which refer to https) Not sure where you're getting 3 from... reed@jarodplus:~/mozilla/www/mozilla.com/trunk$ grep -rn "https://" * | grep "add-ons.mozilla.com" | grep -v ".svn" | wc -l 1324 reed@jarodplus:~/mozilla/www/mozilla-europe.org/trunk$ grep -rn "https://" * | grep "add-ons.mozilla.com" | grep -v ".svn" | wc -l 680

(In reply to comment #15) > Not sure where you're getting 3 from... > > reed@jarodplus:~/mozilla/www/mozilla.com/trunk$ grep -rn "https://" * | grep > "add-ons.mozilla.com" | grep -v ".svn" | wc -l > 1324 > > reed@jarodplus:~/mozilla/www/mozilla-europe.org/trunk$ grep -rn "https://" * | > grep "add-ons.mozilla.com" | grep -v ".svn" | wc -l > 680 Uh, this grep will catch links to https://add-ons.mozilla.com, which are not in question. Also, I was referring to links in the format of "https://%locale%.www.mozilla.com".

(In reply to comment #16) > Uh, this grep will catch links to https://add-ons.mozilla.com, which are not in > question. Also, I was referring to links in the format of > "https://%locale%.www.mozilla.com". Ah, my regex was just more general (but still fine) because we don't use https://add-ons.mozilla.com anywhere: reed@jarodplus:~/mozilla/www/mozilla.com/trunk$ grep -rn "https://add-ons.mozilla.com" * | grep -v ".svn" | wc -l 0 reed@jarodplus:~/mozilla/www/mozilla-europe.org/trunk$ grep -rn "https://add-ons.mozilla.com" * | grep -v ".svn" | wc -l 0 Sorry if it confused you. However, the results posted above still stand firm and true. reed@jarodplus:~/mozilla/www/mozilla.com/trunk$ egrep -r "https://.*\.add-ons\.mozilla\.com" * | grep -v ".svn" | wc -l 1324 reed@jarodplus:~/mozilla/www/mozilla-europe.org/trunk$ egrep -r "https://.*\.add-ons\.mozilla\.com" * | grep -v ".svn" | wc -l 680 This requires https://<something>.add-ons.mozilla.com in order to match without me doing a full ab-CD locale check which isn't needed and would overload my tired brain right now. Does this help to convince you?

This bug blocks bug 399148 because we should decide the future of the locale subdomains before we decide what to do for Safari specifically.

+1 for removing subdomains. Removing locale based subdomains does not affect our ability to offer geo based DNS load balancing. Also, we should think about reassigning this bug.

Who needs to make the call on this?

To comment #10, our current geodns is based on static maps and uses a common hostname (www.mozilla.com) and with www.mozilla.com behind a CDN that's even less of an issue.

I'm brave enough to make the call on this that locale-based subdomains is not needed. There's been enough discussion in this bug more or less affirming that and looking toward the future, any geolocation magic will be done through geodns (at some level I'll have to keep a static map of which locale/IP goes to where, geodns is already doing that (and quite well I might add)). I'll also add that using multi-level hostname wrecks havoc when provisioning SSL and - requires separate wildcard certs, seperate IP addresses and in the case of CDNs, ginormous setup costs for what can essentially be handled by www.mozilla.com. So decision made. Who implements/tests this?

(In reply to comment #22) > So decision made. Who implements/tests this? I will implement it.

Can someone file bugs for the follow-up tasks? a) mozilla.com b) in-client URLs

(In reply to comment #24) > Can someone file bugs for the follow-up tasks? a) mozilla.com b) in-client > URLs I filed: A) Bug 454299 B) Bug 454300

filed bug #458210 for links in google snippets

How far are we here? I'm attacking bookmarks.html in bug 461979, and I'll add localization notes to a defines file mentioning the URLs. I'd prefer to use the new urls.

(In reply to comment #27) > How far are we here? I'm attacking bookmarks.html in bug 461979, and I'll add > localization notes to a defines file mentioning the URLs. I'd prefer to use the > new urls. Go ahead and use them... they aren't new, and they should work just fine.

Filed bug 462015 on amo redirects.

It's been a couple of months since the last comment in this bug. Does anyone know what the current status is?

It seems the result of how the invalid subdomains are being filtered is invoking the 'untrusted site' warning in Firefox and SeaMonkey (at very least). Is this really the impression we want to give Mozilla based software users? Do we want to tell them that Mozilla can't even keep it's own subdomains safe? Why would I then trust software provided by Mozilla?

Is there an example URL that fails in this manner?

I am not 100% sure if this is the issue discussed, but today Firefox told me: -------- Firefox has determined that the following add-ons are known to cause stability or security problems: Microsoft .NET Framework Assistant 1.1 Windows Presentation Foundation 3.5.30729.1 -------- I clicked "more information" to be greeted by: -------- This Connection is Untrusted en-gb.www.mozilla.com uses an invalid security certificate. The certificate is only valid for *.mozilla.com. (Error code: ssl_error_bad_cert_domain) -------- Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3 (.NET CLR 3.5.30729)

This is correct, the certificate is only valid for the immediate sub space. However *en-gb*.www.mozilla.com is already out of that space.

This bug took the appropriate measure in 2007, but in 2009 with Firefox 3.5 we had the first Vietnamese website, and the url was vi.www.mozilla.com :( Really sad. Hope that this will be completed fixed soon with the redirect.

Looks like a duplicate of bug 454299

This is a meta bug.

All clear.