This is the server-side part of bug 347944. Structure: http[s]://%LOCALE%.%SERVICE%.mozilla.[com|org]/%LOCALE%/ Basically, figure out what named / bind stuff needs to be done for the new URL structure and do it. :) There has been some discussion of using geo-based load balancing and just using the http[s]://%SERVICE%.mozilla.[com|org]/%LOCALE%/ structure instead.

We need to know what %SERVICE% is and where you want these requests sent to. Please list in this bug...

At this time we need www and addons. The URL's in the product will be: http://%LOCALE%.www.mozilla.com/%LOCALE%/firefox/%VERSION%/whatsnew/ http://%LOCALE%.www.mozilla.com/%LOCALE%/firefox/%VERSION%/firstrun/ http://%LOCALE%.add-ons.mozilla.com/%LOCALE%/%APP%/%VERSION%/add-ons/ http://%LOCALE%.add-ons.mozilla.com/%LOCALE%/%APP%/%VERSION%/plugins/ http://%LOCALE%.add-ons.mozilla.com/%LOCALE%/%APP%/%VERSION%/themes/ http://%LOCALE%.add-ons.mozilla.com/%LOCALE%/%APP%/%VERSION%/extensions/ http://%LOCALE%.add-ons.mozilla.com/%LOCALE%/%APP%/%VERSION%/search-engines/ And don't forget the safe browsing stuff from bug 348878

Ok - so as I understand it the app will handle the locale stuff based on the uri path, and we need to do the following in dns: *.www.mozilla.com -> www.mozilla.com (A record) *.addons.mozilla.org -> addons.mozilla.org (A record) Correct?

We also need "fxfeeds" for http://en-US.fxfeeds.mozilla.com/en-US/firefox/headlines.xml and http://en-US.fxfeeds.mozilla.com/en-US/firefox/livebookmarks/.

(In reply to comment #3) > Ok - so as I understand it the app will handle the locale stuff based on the > uri path, and we need to do the following in dns: > > *.www.mozilla.com -> www.mozilla.com (A record) > *.addons.mozilla.org -> addons.mozilla.org (A record) > > Correct? No. The way I understand it is this: *.www.mozilla.com --> www.mozilla.com *.www.mozilla.org --> www.mozilla.org *.add-ons.mozilla.com --> addons.mozilla.org *.add-ons.mozilla.org --> addons.mozilla.org *.fxfeeds.mozilla.com --> fxfeeds.mozilla.com

From bug 348165 we also need fxeeds. Where the full set of URLs we need working (for handy testing) is: http://%LOCALE%.www.mozilla.com/%LOCALE%/firefox/central http://%LOCALE%.www.mozilla.com/%LOCALE%/firefox/livebookmarks/ feed://%LOCALE%.fxeeds.mozilla.com/%LOCALE% http://%LOCALE%.www.mozilla.com/%LOCALE%/firefox/help/ http://%LOCALE%.www.mozilla.com/%LOCALE%/firefox/customize/ http://%LOCALE%.www.mozilla.com/%LOCALE%/firefox/community/ http://%LOCALE%.www.mozilla.com/%LOCALE%/firefox/about/ http://%LOCALE%.www.mozilla.com/%LOCALE%/firefox/%VERSION%/whatsnew/ http://%LOCALE%.www.mozilla.com/%LOCALE%/firefox/%VERSION%/firstrun/ http://%LOCALE%.add-ons.mozilla.com/%LOCALE%/%APP%/%VERSION%/add-ons/ http://%LOCALE%.add-ons.mozilla.com/%LOCALE%/%APP%/%VERSION%/plugins/ http://%LOCALE%.add-ons.mozilla.com/%LOCALE%/%APP%/%VERSION%/themes/ http://%LOCALE%.add-ons.mozilla.com/%LOCALE%/%APP%/%VERSION%/extensions/ http://%LOCALE%.add-ons.mozilla.com/%LOCALE%/%APP%/%VERSION%/search-engines/

(In reply to comment #6) > From bug 348165 we also need fxeeds. s/fxeeds/fxfeeds/ > feed://%LOCALE%.fxeeds.mozilla.com/%LOCALE% s/fxeeds/fxfeeds/

(In reply to comment #3) > Ok - so as I understand it the app will handle the locale stuff based on the > uri path, and we need to do the following in dns: > > *.www.mozilla.com -> www.mozilla.com (A record) > *.addons.mozilla.org -> addons.mozilla.org (A record) > > Correct? > Neither addons nor www currently understand the locales - so can we setup temporary redirects? For addons it will be some time before we have localized content (the site itself is not localizable). WWW will have content sooner - but certainly not before beta - so redirecting everyone to the existing .com pages on www would be a fine start.

Also from bug 348842: https://%LOCALE%.add-ons.mozilla.com/%LOCALE%/firefox/%VERSION%/dictionaries/ and from bug 348962: http://%LOCALE%.www.mozilla.com/%LOCALE%/ http://%LOCALE%.www.mozilla.com/%LOCALE%/firefox/ and from bug 348076: http://%LOCALE%.www.mozilla.com/%LOCALE%/blocklist/ http://%LOCALE%.www.mozilla.com/%LOCALE%/products/firefox/

aaaand one last one from bug 348076: http://%LOCALE%.www.mozilla.com/%LOCALE%/firefox/releases/

Verified with Schrep this should be *.add-ons.mozilla.org, not *.addons.mozilla.org.

Could we get a list of all the possible locales and version or a more specific regular expression for the rewrite rule? We want to avoid redirecting when we shouldn't. Let us know if this is possible...

(In reply to comment #12) > Could we get a list of all the possible locales and version or a more specific > regular expression for the rewrite rule? We want to avoid redirecting when we > shouldn't. Let us know if this is possible... > I would think that we want to redirect for all builds we do, not just for those which ship, thus, http://lxr.mozilla.org/mozilla/source/browser/locales/all-locales is the right list of locales, taken from the right branch/release tag. (If we'd only redirect for those locales we ship, there's a shipped-locales right next to it, but that'd just make testing unecessarily hard.) Regarding the add-ons dns's, I recall hearing they should be .com, too.

With respect to version 2.0.0.* is a good place to start

Woah! Is the add-ons domain going to be the one users have to remember, or is it something on the back end? As a main point of entry, I think the domain "add-ons.mozilla.com" is pretty "meh". It seems we are making an arbitrary change of an established namespace to something that is harder to type, and harder to remember. If it's for back-end stuff, then that's different story. Also, there's still the redirect for people who remember "addons" -- but again, it just seems unnecessary to me. So -- before we commit to changes like this that might affect users, I guess someone should at least ask: * What is the reasoning behind add-ons.mozilla.org|com? * Is it for tracking incoming links from clients, or is it intended to be a replacement for addons.mozilla.org eventually?

Yep, I agree that "add-ons" would be to hard to remember, especially for non-en-US users. If you can't make it <localized_word_for_add-ons>.mozilla.$TLD, at least leave the version without the dash working...

All of these rewrites have been set up to point to something. Hopefully they are pointing to the right locations.

I'd like to keep this open until localizers/coders have ran through the test cases and possible URLs...

Testing this is really a QA job, CCing Tim. Tim, can you reassign this bug as fits? Maybe a nagios module would be good to monitor the performance of the stuff we link to, that may be particularily interesting for external links like feeds.

Was hoping for the dev(s) of this code to do a simple and single functionality test to make sure that this was setup per the code - if incorrectly assigned, my apologies - please re-assign as needed.

LOCALE.add-ons.mozilla.org is set up correctly, but LOCALE.add-ons.mozilla.com is not working. We need it to work for use with several URLs. Thanks! :)

Reassigning to server-ops until comment #21 is handled.

Another one to add from bug 348165: http://en-US.add-ons.mozilla.com/en-US/firefox/bookmarks/

Looking at dig, those are real A entries and not CNAME aliases. Is that intentional? That kind-of determines whether we intend users to remember those links or not. CC'ing shaver and cbeard, too.

so these are the expanded test links to get everyone helping on the check out, right? .org now working.. https://bg.add-ons.mozilla.org/bg https://ca.add-ons.mozilla.org/ca https://cs.add-ons.mozilla.org/cs https://da.add-ons.mozilla.org/da https://de.add-ons.mozilla.org/de https://el.add-ons.mozilla.org/el https://en-GB.add-ons.mozilla.org/en-GB https://es-AR.add-ons.mozilla.org/es-AR https://es-ES.add-ons.mozilla.org/es-ES https://eu.add-ons.mozilla.org/eu https://fi.add-ons.mozilla.org/fi https://fr.add-ons.mozilla.org/fr https://fy-NL.add-ons.mozilla.org/fy-NL https://ga-IE.add-ons.mozilla.org/ga-IE https://gu-IN.add-ons.mozilla.org/gu-IN https://he.add-ons.mozilla.org/he https://hu.add-ons.mozilla.org/hu https://hy-AM.add-ons.mozilla.org/hy-AM https://it.add-ons.mozilla.org/it https://ja.add-ons.mozilla.org/ja https://ja-JP-mac.add-ons.mozilla.org/ja-JP-mac https://ko.add-ons.mozilla.org/ko https://lt.add-ons.mozilla.org/lt https://mk.add-ons.mozilla.org/mk https://mn.add-ons.mozilla.org/mn https://nb-NO.add-ons.mozilla.org/nb-NO https://nl.add-ons.mozilla.org/nl https://nn-NO.add-ons.mozilla.org/nn-NO https://pa-IN.add-ons.mozilla.org/pa-IN https://pl.add-ons.mozilla.org/pl https://pt-BR.add-ons.mozilla.org/pt-BR https://ro.add-ons.mozilla.org/ro https://ru.add-ons.mozilla.org/ru https://sk.add-ons.mozilla.org/sk https://sl.add-ons.mozilla.org/sl https://sq.add-ons.mozilla.org/sq https://sv-SE.add-ons.mozilla.org/sv-SE https://tr.add-ons.mozilla.org/tr https://zh-CN.add-ons.mozilla.org/zh-CN https://zh-TW.add-ons.mozilla.org/zh-TW .com... not working yet? https://bg.add-ons.mozilla.com/bg https://ca.add-ons.mozilla.com/ca https://cs.add-ons.mozilla.com/cs https://da.add-ons.mozilla.com/da https://de.add-ons.mozilla.com/de https://el.add-ons.mozilla.com/el https://en-GB.add-ons.mozilla.com/en-GB https://es-AR.add-ons.mozilla.com/es-AR https://es-ES.add-ons.mozilla.com/es-ES https://eu.add-ons.mozilla.com/eu https://fi.add-ons.mozilla.com/fi https://fr.add-ons.mozilla.com/fr https://fy-NL.add-ons.mozilla.com/fy-NL https://ga-IE.add-ons.mozilla.com/ga-IE https://gu-IN.add-ons.mozilla.com/gu-IN https://he.add-ons.mozilla.com/he https://hu.add-ons.mozilla.com/hu https://hy-AM.add-ons.mozilla.com/hy-AM https://it.add-ons.mozilla.com/it https://ja.add-ons.mozilla.com/ja https://ja-JP-mac.add-ons.mozilla.com/ja-JP-mac https://ko.add-ons.mozilla.com/ko https://lt.add-ons.mozilla.com/lt https://mk.add-ons.mozilla.com/mk https://mn.add-ons.mozilla.com/mn https://nb-NO.add-ons.mozilla.com/nb-NO https://nl.add-ons.mozilla.com/nl https://nn-NO.add-ons.mozilla.com/nn-NO https://pa-IN.add-ons.mozilla.com/pa-IN https://pl.add-ons.mozilla.com/pl https://pt-BR.add-ons.mozilla.com/pt-BR https://ro.add-ons.mozilla.com/ro https://ru.add-ons.mozilla.com/ru https://sk.add-ons.mozilla.com/sk https://sl.add-ons.mozilla.com/sl https://sq.add-ons.mozilla.com/sq https://sv-SE.add-ons.mozilla.com/sv-SE https://tr.add-ons.mozilla.com/tr https://zh-CN.add-ons.mozilla.com/zh-CN https://zh-TW.add-ons.mozilla.com/zh-TW https://bg.add-ons.mozilla.com/bg/firefox/bookmarks https://ca.add-ons.mozilla.com/ca/firefox/bookmarks https://cs.add-ons.mozilla.com/cs/firefox/bookmarks https://da.add-ons.mozilla.com/da/firefox/bookmarks https://de.add-ons.mozilla.com/de/firefox/bookmarks https://el.add-ons.mozilla.com/el/firefox/bookmarks https://en-GB.add-ons.mozilla.com/en-GB/firefox/bookmarks https://es-AR.add-ons.mozilla.com/es-AR/firefox/bookmarks https://es-ES.add-ons.mozilla.com/es-ES/firefox/bookmarks https://eu.add-ons.mozilla.com/eu/firefox/bookmarks https://fi.add-ons.mozilla.com/fi/firefox/bookmarks https://fr.add-ons.mozilla.com/fr/firefox/bookmarks https://fy-NL.add-ons.mozilla.com/fy-NL/firefox/bookmarks https://ga-IE.add-ons.mozilla.com/ga-IE/firefox/bookmarks https://gu-IN.add-ons.mozilla.com/gu-IN/firefox/bookmarks https://he.add-ons.mozilla.com/he/firefox/bookmarks https://hu.add-ons.mozilla.com/hu/firefox/bookmarks https://hy-AM.add-ons.mozilla.com/hy-AM/firefox/bookmarks https://it.add-ons.mozilla.com/it/firefox/bookmarks https://ja.add-ons.mozilla.com/ja/firefox/bookmarks https://ja-JP-mac.add-ons.mozilla.com/ja-JP-mac/firefox/bookmarks https://ko.add-ons.mozilla.com/ko/firefox/bookmarks https://lt.add-ons.mozilla.com/lt/firefox/bookmarks https://mk.add-ons.mozilla.com/mk/firefox/bookmarks https://mn.add-ons.mozilla.com/mn/firefox/bookmarks https://nb-NO.add-ons.mozilla.com/nb-NO/firefox/bookmarks https://nl.add-ons.mozilla.com/nl/firefox/bookmarks https://nn-NO.add-ons.mozilla.com/nn-NO/firefox/bookmarks https://pa-IN.add-ons.mozilla.com/pa-IN/firefox/bookmarks https://pl.add-ons.mozilla.com/pl/firefox/bookmarks https://pt-BR.add-ons.mozilla.com/pt-BR/firefox/bookmarks https://ro.add-ons.mozilla.com/ro/firefox/bookmarks https://ru.add-ons.mozilla.com/ru/firefox/bookmarks https://sk.add-ons.mozilla.com/sk/firefox/bookmarks https://sl.add-ons.mozilla.com/sl/firefox/bookmarks https://sq.add-ons.mozilla.com/sq/firefox/bookmarks https://sv-SE.add-ons.mozilla.com/sv-SE/firefox/bookmarks https://tr.add-ons.mozilla.com/tr/firefox/bookmarks https://zh-CN.add-ons.mozilla.com/zh-CN/firefox/bookmarks https://zh-TW.add-ons.mozilla.com/zh-TW/firefox/bookmarks

(In reply to comment #24) > Looking at dig, those are real A entries and not CNAME aliases. > Is that intentional? That kind-of determines whether we intend users to > remember those links or not. It...does? Clue me in here.

looks like at least a few of the locale-country code forms of the urls aren't working... if we are doing direct expansion of http://lxr.mozilla.org/mozilla/source/browser/locales/all-locales e.g. https://en-GB.add-ons.mozilla.org/en-GB https://es-AR.add-ons.mozilla.org/es-AR https://es-ES.add-ons.mozilla.org/es-ES are the ones I've checked so far...

(In reply to comment #26) > It...does? Clue me in here. Yeah, it probably doesn't. I got confused by how we do ab-CD.start.mozilla.com and what it does with that. wget -v helped me. Should the servers redirect to a memory-friendly URLs though?

(In reply to comment #28) > (In reply to comment #26) > > It...does? Clue me in here. > > Yeah, it probably doesn't. I got confused by how we do ab-CD.start.mozilla.com > and what it does with that. wget -v helped me. > > Should the servers redirect to a memory-friendly URLs though? The urls to which they would redirect do not exist yet, at least in terms of AMO. We're hard at work, though!

What is add-ons.mozilla.com supposed to be doing? Or how is it different than addons.mozilla.org

(In reply to comment #30) > What is add-ons.mozilla.com supposed to be doing? Or how is it different than > addons.mozilla.org LOCALE.add-ons.mozilla.com|org redirects to addons.mozilla.org Currently, only LOCALE.add-ons.mozilla.com is used, but eventually .org will be, too, I think. This is why having .com not working is very bad. :/ Basically, we need LOCALE.add-ons.mozilla.com|org to redirect to addons.mozilla.org

Still lacking comment #4 being completed.

it looks like this: https://en-US.add-ons.mozilla.com/en-US/firefox/3.0a1/search-engines/ is redirecting to: http://www.mozilla.comen-us/firefox/3.0a1/search-engines/ ^^^

(In reply to comment #30) > What is add-ons.mozilla.com supposed to be doing? Or how is it different than > addons.mozilla.org add-ons.mozilla.com should not do anything; only its per-locale subdomains need exist, and they should all redirect appropriately, as with "add-ons.mozilla.org"'s subdomains. (Today that means all of them redirect to the same place on addons.mozilla.org, but it will be different in the nearish future.) Similarly, I'm not sure where "addons.mozilla.com" came from, or why it's now redirecting to AMO.

addons.mozilla.com has been around since V1 I believe.

*** Bug 349444 has been marked as a duplicate of this bug. ***

*** Bug 349534 has been marked as a duplicate of this bug. ***

So what's supposed to happen for just $SERVICE.mozilla.com, without a $LOCALE? Is it treated like en-US? Is it up to the service owner?

I think defaulting to en-US is a pretty sensible behaviour, myself

This is a list of all the sites that I found in the bug and where they redirect to if they do redirect. Let me know what seems off.

Were there any recent changes made here? AMO theme install just busted a few hours ago (5pm PDT), looks like it's due to a bogus redirect from /js/install.js to /install.js, which doesn't exist.

ok, here's the rewrite rules I commented out (because it was breaking the theme install) # LOCALE STUFF #RewriteRule ^(\w{2}(-\w{2}(-mac)?)?)/?$ / [R] #RewriteRule ^(\w{2}(-\w{2}(-mac)?)?)/(.+?)/(.+?)/(.*)$ /$6 [R] #RewriteRule ^(\w{2}(-\w{2}(-mac)?)?)/(.*)$ /$4 [R] Suggested long-term fix is to add the following immediately in front of those: RewriteRule ^/js/ - [L] Which will match on the /js/ directory and do nothing, and stop executing any more rewrites after that. morgamic says js was the only directory matching the pattern that already existed, so that'll probably be enough. This hasn't been implemented yet because I want the people around who were working on this first to make sure it's not breaking something else when it goes live.

(In reply to comment #42) > ok, here's the rewrite rules I commented out (because it was breaking the theme > install) > > # LOCALE STUFF > #RewriteRule ^(\w{2}(-\w{2}(-mac)?)?)/?$ / [R] > #RewriteRule ^(\w{2}(-\w{2}(-mac)?)?)/(.+?)/(.+?)/(.*)$ /$6 [R] > #RewriteRule ^(\w{2}(-\w{2}(-mac)?)?)/(.*)$ /$4 [R] Can we not just use a regex that matches all the locales? I wrote this for use with www.mozilla.com: RewriteRule ^(?:af|ar|be|bg|ca|cs|da|de|el|en\-GB|en\-US|es\-AR|es\-ES|eu|fi|fr|fy\-NL|ga\-IE|gu\-IN|he|hu|hy\-AM|it|ja\-JP\-mac|ja|ko|lt|mk|mn|nb\-NO|nl|nn\-NO|nso|pa\-IN|pl|pt\-BR|pt\-PT|ro|ru|sk|sl|sq|sv\-SE|tr|xh|zh\-CN|zh\-TW|zu)/(.*)$ /$1 [NC,R] Of course, it might need some work to address all possible cases, but it is still better than relying on an actual pattern that may cause issues somewhere (like it did tonight).

I'm trying to avoid a huge or statement, so we do not have to edit a bunch of files if we add a new locale. How about something like this (?!(?:js|css))(\w{2,3}(?:-\w{2}(?:-mac))?) For addons at least that should give us what we need. Let me know what you all think. If this regex looks a little to crazy justdave's idea might be better.

oops... (?!(?:js|css))(\w{2,3}(?:-\w{2}(?:-mac)?)?) That should be better. Thanks to reed.

I don't understand why these redirect rules should *ever* affect addons.mozilla.org or anything other than the specific hostnames outlined in this bug. (Which does not include the locale-less "add-ons.mozilla.(com|org)" at this point, to my understanding.) Why don't we just have a vhost config that _only_ applies to *.add-ons.mozilla.(com,org), which can then perform the redirect based on the full URL? It could also ensure that the locale URL path matches the one in the hostname, for extra sanity. (Similarly for other redirects.) If done that way, I don't think you need a list of explicit locales or fragile exclusions, because we should never have conflicts that actually match the URL structure listed in this bug. The source of the problem seems to be that we're trying to configure the real service to also be the redirector, and I think that's a losing proposition. I can't speak for the other service owners, but I definitely do _not_ want the path portion of the standardized URLs here to be processed and redirected if they're used against https://addons.mozilla.org. I don't want my application structure to have to be aware of the product-link redirection structure, and I can't think of a good reason that it should have to.

*** Bug 349728 has been marked as a duplicate of this bug. ***

Get Extensions link (extension.GetMoreExtensionsURL) and Get Themes link (extension.GetMoreThemesURL) are both redirecting to https://addons.mozilla.org/firefox/. Shouldn't they be go to their respective areas; https://addons.mozilla.org/firefox/extensions/ and https://addons.mozilla.org/firefox/themes/ ? also Get More Search Engines is still 404 Not Found

Just a note - we haven't made any intentional changes to addons internal redirects - only the locale stuff, so none of this should be any different than it has been for months. If you are asking for changes to how addons redirects outside of the scope of l10n, I think we should get a different bug going for that - Shaver, thoughts? (In reply to comment #48) > Get Extensions link (extension.GetMoreExtensionsURL) and Get Themes link > (extension.GetMoreThemesURL) are both redirecting to > https://addons.mozilla.org/firefox/. Shouldn't they be go to their respective > areas; https://addons.mozilla.org/firefox/extensions/ and > https://addons.mozilla.org/firefox/themes/ ? > > also Get More Search Engines is still 404 Not Found >

> Just a note - we haven't made any intentional changes to addons internal > redirects - only the locale stuff, so none of this should be any different than > it has been for months. > > If you are asking for changes to how addons redirects outside of the scope of > l10n, I think we should get a different bug going for that - Shaver, thoughts? I think Tracy is saying something different. When I select "Get more search engines..." in the browser, it goes to https://en-US.add-ons.mozilla.com/en-US/firefox/2.0b2/search-engines/ which redirects to https://addons.mozilla.org/search-engines/ which is a 404. So I think Tracy's saying (and I agree) that the newly-added l10n redirect is pointing at the wrong place. But More Extensions and More Themes both work for me; Tracy, are you using en-US?

The search-engines redirect has been fixed.

Any futher action needed from ops on this ticket? If we don't heard anything in a few days, we'll close it out.

(In reply to comment #50) > But More Extensions and More Themes both work for me; Tracy, are you using > en-US? Sorry, Phil, comment slipped by me. let me describe what I am seeing in en-US, de, en-GB and fr. (so far what I've tested): -click the "Get extensions" link in the Add-ons Manager Tested results: The page that opens in a new tab shows: https://addons.mozilla.org/extensions/ in the location. The page loaded is the a.m.o Home tab. (https://addons.mozilla.org/firefox/) expected results: The page loads the a.m.o Extensions tab (https://addons.mozilla.org/firefox/extensions/) also... -click the "Get themes" link in the Add-ons Manager Tested results: The page that opens in a new tab shows: https://addons.mozilla.org/themes/ in the location. The page loaded is the a.m.o Home tab. (https://addons.mozilla.org/firefox/) expected results: The page loads the a.m.o Extensions tab (https://addons.mozilla.org/firefox/themes/) So are the Add-ons Manager links now incorrect and this needs to be filed against the app? Or should a.m.o handle with a redirect?

(In reply to comment #53) sorry for the spam/ > expected results: > The page loads the a.m.o Extensions tab > (https://addons.mozilla.org/firefox/themes/) should read: expected results: The page loads the a.m.o Themes tab (https://addons.mozilla.org/firefox/themes/)

I think this should be filed against the app. Let me know if this seems wrong to anyone else. (In reply to comment #53) > (In reply to comment #50) > > But More Extensions and More Themes both work for me; Tracy, are you using > > en-US? > > Sorry, Phil, comment slipped by me. > > let me describe what I am seeing in en-US, de, en-GB and fr. (so far what I've > tested): > > -click the "Get extensions" link in the Add-ons Manager > > Tested results: > The page that opens in a new tab shows: https://addons.mozilla.org/extensions/ > in the location. The page loaded is the a.m.o Home tab. > (https://addons.mozilla.org/firefox/) > > expected results: > The page loads the a.m.o Extensions tab > (https://addons.mozilla.org/firefox/extensions/) > > also... > > -click the "Get themes" link in the Add-ons Manager > > Tested results: > The page that opens in a new tab shows: https://addons.mozilla.org/themes/ in > the location. The page loaded is the a.m.o Home tab. > (https://addons.mozilla.org/firefox/) > > expected results: > The page loads the a.m.o Extensions tab > (https://addons.mozilla.org/firefox/themes/) > > So are the Add-ons Manager links now incorrect and this needs to be filed > against the app? Or should a.m.o handle with a redirect? >

Tracy, these redirects should work now.

they are 404ing now with BE nightlies

(In reply to comment #57) > they are 404ing now with BE nightlies "Get Extensions" redirects to https://addons.mozilla.org/2.0b2/extensions/ "Get Themes" redirects to https://addons.mozilla.org/2.0b2/themes/ So, basically, just need to get rid of the "2.0b2/" part from the redirect. :)

(In reply to comment #58) > So, basically, just need to get rid of the "2.0b2/" part from the redirect. :) After a second thought and words of advice from beltzner/morgamic, it seems the wrong part of the URL is just being stripped out. Basically: http://%LOCALE%.add-ons.mozilla.com/%LOCALE%/%APP%/%VERSION%/extensions/ should redirect to: https://addons.mozilla.org/firefox/extensions/ (same for themes)

Looks like it is fixed now.

Is there anything else I need to do on this?

verified that the Add-ons "Get" links are redirected correctly now.

As far as I can tell, this is now fixed. I did some quick tests on various URLs in this bug, and they all seemed to work fine. Any other issues will be opened in a new bug to save your sanity. Thanks so much! :)