Closed Bug 828455 Opened 12 years ago Closed 11 years ago

Stub installer of 18 didn't start downloading?

Categories

(Firefox :: Installer, defect)

18 Branch
x86
macOS
defect
Not set
major

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: joe, Unassigned)

References

()

Details

Attachments

(3 files)

I downloaded the stub installer from the linked URL on ftp.mozilla.org, but the download never started - it was just doing a side-to-side waiting to start downloading for a while.
Joe told me on IRC that he used the stub installer direct from FTP: ftp://ftp.mozilla.org/pub/firefox/releases/18.0/win32/en-US/Firefox%20Setup%20Stub%2018.0.exe

However, Bouncer still points at the 16.0.2 stub installer for some reason: /firefox/releases/stub/Firefox%2016.0.2%20Stub%20Installer.exe. We should probably update that, but it sounds like the 18.0 stub may be broken, so let's look into that first.

The firefox-latest entry (which the stub installer downloads from AFAIK), points at: /firefox/releases/18.0/win32/:lang/Firefox%20Setup%2018.0.exe

And http://download.mozilla.org/?product=firefox-latest&os=win&lang=en-US WFM.
Joe confirmed on IRC that the 16.0.2 stub installer worked fine. I think this means it's a problem with the stub installer code?
Component: Release Engineering → Installer
Product: mozilla.org → Firefox
Version: other → 18 Branch
Works with aurora and I couldn't find a latest-beta dir for a beta stub. I highly suspect there is something going on on the server side.
Note: I am fairly certain that the only difference in the stub between aurora and release at this time is branding.nsi which was included in the Firefox Setup Stub 18.0.exe or it wouldn't have sent the correct url or had the correct branding.
http://mxr.mozilla.org/mozilla-central/source/browser/branding/official/branding.nsi

Perhaps there is something different about the server support with the cdn that isn't a problem with the ftp mirror or a similar problem to the recent caching change that only comes into affect when redirecting to the cdn.
Also, the beta stub does successfully start the download which lends further reason to think it is a server side issue since the only differences between beta and release as far as the stub code goes are the url to download, the manual install url, and the value for channel which is used for the ping at the very end. Also, release and beta both use the cdn.
http://mxr.mozilla.org/mozilla-central/source/browser/installer/windows/nsis/stub.nsi#137

http://ftp.mozilla.org/pub/mozilla.org/firefox/releases/latest-beta/win32/en-US/Firefox%20Setup%20Stub%2018.0b7.exe
One difference is that the stub from Firefox 18.0 is only doing HEAD requests to download.mozilla.org whereas the 16.0.2 stub is doing GET requests. The stub doesn't seem to follow the Location header from the HEAD response.

18.0:
HEAD /?product=firefox-latest&os=win&lang=en-US HTTP/1.1
User-Agent: NSIS InetBgDL (Mozilla)
Host: download.mozilla.org
Content-Length: 0
Cache-Control: no-cache
Cookie: dmo=10.8.81.216.1357760166026654

HTTP/1.1 302 Found
Server: Apache
X-Backend-Server: bouncer1.webapp.phx1.mozilla.com
Cache-Control: max-age=15
Content-Type: text/html; charset=UTF-8
Date: Wed, 09 Jan 2013 19:45:46 GMT
Location: ?product=firefox-18.0&os=win&lang=en-US
Transfer-Encoding: chunked
Connection: Keep-Alive
X-Cache-Info: caching


16.0.2:
GET /?product=firefox-latest&os=win&lang=en-US HTTP/1.1
User-Agent: NSIS InetBgDL (Mozilla)
Host: download.mozilla.org
Connection: Keep-Alive

HTTP/1.1 302 Found
Server: Apache
X-Backend-Server: bouncer2.webapp.phx1.mozilla.com
Cache-Control: max-age=15
Content-Type: text/html; charset=UTF-8
Date: Wed, 09 Jan 2013 19:47:26 GMT
Location: ?product=firefox-18.0&os=win&lang=en-US
Keep-Alive: timeout=3, max=499
Connection: Keep-Alive
Set-Cookie: dmo=10.8.81.218.1357760846642694; path=/; expires=Thu, 09-Jan-14 19:47:26 GMT
X-Cache-Info: caching
Content-Length: 0

GET /?product=firefox-18.0&os=win&lang=en-US HTTP/1.1
User-Agent: NSIS InetBgDL (Mozilla)
Host: download.mozilla.org
Connection: Keep-Alive

HTTP/1.1 302 Found
Server: Apache
X-Backend-Server: bouncer5.webapp.phx1.mozilla.com
Cache-Control: max-age=15
Content-Type: text/html; charset=UTF-8
Date: Wed, 09 Jan 2013 19:47:18 GMT
Location: http://download.cdn.mozilla.net/pub/mozilla.org/firefox/releases/18.0/win32/en-US/Firefox%20Setup%2018.0.exe
Keep-Alive: timeout=3, max=500
Content-Length: 0
Connection: Keep-Alive
X-Cache-Info: cached
So the current status of stub installers is as following:

* Firefox 18.0.1 fails
* Firefox 19.0b2 works as expected
* Firefox 20.0a2 works as expected
* Firefox 21.0a1 works as expected

So it looks like that only the stub for releases is affected.
Severity: normal → major
(In reply to Henrik Skupin (:whimboo) from comment #8)
> So the current status of stub installers is as following:
> 
> * Firefox 18.0.1 fails
> * Firefox 19.0b2 works as expected
> * Firefox 20.0a2 works as expected
> * Firefox 21.0a1 works as expected
> 
> So it looks like that only the stub for releases is affected.

Server-side issue isn't going to allow us to get a regression window. And that isn't correct given bug 836044 is filed.

Both this bug and bug 836044 could possibly have a similar root cause. But it seems they are probably both server-side.
(In reply to Jason Smith [:jsmith] from comment #9)

> Server-side issue isn't going to allow us to get a regression window.

Please see comment 7 where the stub installer for version 16.0 found the correct 18.0 installer. At least when I have the HTTP responses interpreted correctly.

> And that isn't correct given bug 836044 is filed.

I tested it and it's working for me. So it might be a problem only for some of us. But lets continue on bug 836044.
Joe, is this still happening?
No reply to comment #11 for over a month and no other reports so resolving wfm
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: