Closed Bug 742998 Opened 10 years ago Closed 10 years ago

Web server redirect for Fx 3.6 users upgrading to version 12


( :: General, defect)

Not set


(Not tracked)



(Reporter: cmore, Assigned: jlong)




(1 file)

We would like to create a redirect on to send users that upgrade from 3.6 to version 12 to a special page instead of the normal What's New. Traditionally, we would not be able to know what version a user upgraded from from a perspective, but a patch landing in Fx 12 will allow this.

We need a redirect that will match the following URL+QueryString:


The redirect should be a regex that matches "/any-locale/firefox/12.0/whatsnew/?oldversion=3.6" and redirects to "/firefox/central/"

Here is a quick stab at the Redirect Match.

RedirectMatch ^(/[^/])+/firefox/12\.[0-9]*(\.[0-9])+/whatsnew/\?oldversion=3\.6\.[0-9]*$ /firefox/central/

This should match the What's New page for 12.x including 12.x.y users where the query string contains oldversion=3.6.x regardless if the locale at the start of the URL or not. Then it redirects any match to /firefox/central and that page's locale redirection can redirect again. If we wanted to be more clever, we could pass the locale to the central page by back references. 

I wouldn't copy/paste my RedirectMatch without reviewing it first as I did it between meetings. :)
So AFAIK, all the redirects are handled by the team and not IT. If that's not changed in the recent past, this bug needs to be put in Websites -> and the infra flag taken off.
Group: infra
fox2mike is correct... redirects on are currently managed by web dev. Moving!
Assignee: server-ops → nobody
Component: Server Operations →
Product: → Websites
QA Contact: phong → www-mozilla-org
Jlongster: Is this something you can help get set up and test on dev/stage?
Assignee: nobody → jlong
If it makes any difference, the GET of "/any-locale/firefox/12.0/whatsnew/?oldversion=3.6" will be on rather than And oldversion will run from 3.6.13 through 3.6.28, but the 3.6.* match suggested shouldn't cause any problems.
Looking into it now, but yes, we should be able to do this.
(In reply to James Long (:jlongster) from comment #5)
> Looking into it now, but yes, we should be able to do this.

Can you set up the redirect on dev this week as we are only a few weeks away from needing this in production? We could and should go live with this redirect ahead of the EOL of 3.6 since the querystring-based redirect will not affect anyone until Fx 12 lands.
Yep, I can do that this week. Probably tomorrow, or Thursday if I get really tied up with things.
Whiteboard: r=104396 b=trunk
Hi Everyone. Jlongster made the redirect on dev and you should test the link below with all of the variations of 3.6 versions:

James, can you adjust the redirect so that the third digit is optional? 

i.e. 3\.6\(\.[0-9]+)*
Sorry, I messed up a little here. Rather than sending oldversion=3.6.*, upgrades from Firefox 3.6 will actually end up at oldversion=rv:1.9.2.*, due to a quick in how the "old version" was stored prior to bug 728932 (in Firefox 12 and earlier).

So we're going to need to adjust the redirect so that it matches oldversion parameters that begin with "rv:1.9.2", rather than "3.6".
Attached patch patchSplinter Review
I believe this change would do the trick, but I haven't tested it!
Attachment #615607 - Flags: review?(jlong)
Ah, I missed a "." before the trailing *. But you get the idea!
James: Can you make these changes?
done, please test
Whiteboard: r=104396 b=trunk → r=104396,104427 b=trunk
Tested on Windows 7, Ubuntu 11.10, and Mac OSX 10.6:
Firefox 3.6.28 en-US:
Firefox 3.6.28 de:

Displays a page stating:
"You’re running an unknown version of Firefox."
Sorry, the 3.6.28 de URL is incorrect (copy didn't take from VM). The real URL was:
It's not live yet, you have to test on the dev site:
Comment on attachment 615607 [details] [diff] [review]

Review of attachment 615607 [details] [diff] [review]:

r- because it's missing the trailing ., but I've copied it and fixed it.
Attachment #615607 - Flags: review?(jlong) → review-
These links all behave as I would expect them to: [*]

[*] This link redirects me to the en-US central page, because my build's locale is en-US, and the redirect points to the locale-agnostic link (/firefox/central without the "de"), so the web-side locale detection kicks in. Should work fine with actual de builds.

Can we push this to production, and then have Anthony test the end-to-end path there with Nick's test snippets?
Yep, pushed to production r104436
Closed: 10 years ago
Resolution: --- → FIXED
Whiteboard: r=104396,104427 b=trunk

Please test this URL pattern:

As Gavin mentioned, the redirect is locale-agnostic and thus server-side locale detection will take over regardless of what locale you were at when redirection first took place.

I'm unable to test this end-to-end right now due to 3.6.{13-28} -> 11.0 EOL snippets being pushed to releasetest.
I repushed the test snippets so you can test end-to-end for 3.6.28 en-US/de.
Just tried Firefox 3.6.28 en-US -> 12.0 on releasetest. Build updated fine but I get the following URL on restart:

Tab 0:
Tab 1:
Excellent, that's the expected behavior.
Okay, good -- checking 3.6.28 de now.
Firefox 3.6.28 de -> 12.0 on releasetest:
Tab 0:
Tab 1:

Looks good to me.
Component: → General
Product: Websites →
You need to log in before you can comment on or make changes to this bug.