Open Bug 860428 Opened 12 years ago Updated 9 years ago

use version independent links to firefox products on mozilla.org

Categories

(www.mozilla.org :: Bedrock, defect)

Production
defect
Not set
normal

Tracking

(Not tracked)

People

(Reporter: bhearsum, Assigned: pmac)

References

Details

Every time we ship we need to update mozilla.org to change the version number. Once a couple of bugs are fixed, we'll have an automatically updated product in bouncer that handles this. Switching mozilla.org to version-less links gets us closer to a single source of truth and also makes it easier to handle stranger one-off requests like single-platform releases.
Depends on: 860430
Depends on: 860431
Depends on: 818254
I thought a net installer like Google Chrome (Bug 322206) would resolve this longstanding issue.
This might have Metrics implications, cc'ing Daniel.
(In reply to Kohei Yoshino from comment #1) > I thought a net installer like Google Chrome (Bug 322206) would resolve this > longstanding issue. It's not clear when that's going to ship yet, and we still need to send links to the correct version of the stub installer itself. Also...it's Windows only.
Assignee: nobody → pmac
OS: Linux → All
Hardware: x86_64 → All
We currently ignore the firefox-latest hits in the logs and only pay attention to the version-full URL that is hit from the 302 that happens. Will this method work with the new version-less scheme? If not, what alternative do we have for counting the number of download requests by version?
(In reply to Daniel Einspanjer :dre [:deinspanjer] from comment #4) > We currently ignore the firefox-latest hits in the logs and only pay > attention to the version-full URL that is hit from the 302 that happens. > > Will this method work with the new version-less scheme? If not, what > alternative do we have for counting the number of download requests by > version? Not with the idea that's currently floating around. That idea is: * User clicks download button, which sends them to something like: http://download.mozilla.org/?product=firefox-latest&os=win&lang=en-US * Bouncer 302's to CDN path like: http://download.cdn.mozilla.net/pub/mozilla.org/firefox/releases/20.0/win32/en-US/Firefox%20Setup%2020.0.exe If Bouncer supported configurable alias' we could add an additional 302 in there, so it would look like: * User clicks download button, which sends them to something like: http://download.mozilla.org/?product=firefox-latest&os=win&lang=en-US * Bouncer 302's to http://download.mozilla.org/?product=firefox-20.0&os=win&lang=en-US * Bouncer 302's to CDN path like: http://download.cdn.mozilla.net/pub/mozilla.org/firefox/releases/20.0/win32/en-US/Firefox%20Setup%2020.0.exe I'm not sure if that has other downsides though.
Well, I know that every 302 incurs a round trip penalty and potentially can affect the acquisition funnel, so I won't recommend that approach if we can find an alternative. At the point in bouncer where the request for product=firefox-latest is received and it is about to send the redirect to the CDN, I assume there is server-side logic that calculates and crafts that redirect rather than something simple like an apache alias? If so, could we maybe inject some specific application logging to log the details of the download request outside of the default web server access logs? If that sounds doable, I would be happy to file a bug for it with more details. I think we need to block the roll-out of this feature on either the redirect or additional logging though because there are a lot of business processes that drive off of the download metrics we currently get from bouncer.
(In reply to Daniel Einspanjer :dre [:deinspanjer] from comment #6) application logging is doable, and I agree should be part of the requirements for this. A specific bug against bouncer for this would be great I think, but take my opinions with a large grain-of-salt as I'm not a maintainer of bouncer (yet ;).
(In reply to Daniel Einspanjer :dre [:deinspanjer] from comment #6) > Well, I know that every 302 incurs a round trip penalty and potentially can > affect the acquisition funnel, so I won't recommend that approach if we can > find an alternative. Yeah, sounds like it's out of the question. > At the point in bouncer where the request for product=firefox-latest is > received and it is about to send the redirect to the CDN, I assume there is > server-side logic that calculates and crafts that redirect rather than > something simple like an apache alias? There's a database lookup, if you call that a calculation. > If so, could we maybe inject some specific application logging to log the > details of the download request outside of the default web server access > logs? I'll have to defer to Laura or Brandon, but I would imagine this is possible.
Flags: needinfo?(laura)
Component: Pages & Content → Bouncer
Product: www.mozilla.org → Webtools
Version: unspecified → 2.0
:laura, this bug is about changing the buttons on mozilla.org to use the new version-less products. There are other bugs about getting these links working in bouncer. I therefore believe this does belong in the www.mozilla.org product.
sorry pmac, feel free to change it back.
Flags: needinfo?(laura)
Component: Bouncer → Bedrock
Product: Webtools → www.mozilla.org
Version: 2.0 → Production
Depends on: 1324579
You need to log in before you can comment on or make changes to this bug.