Closed Bug 402141 Opened 17 years ago Closed 15 years ago

sentry incorrectly flagging mirrors as having files available that don't

Categories

(Webtools :: Bouncer, defect)

defect
Not set
critical

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: joduinn, Assigned: justdave)

Details

Attachments

(1 file)

(not sure if this is correct component, please reassign as needed)

From IRC with justdave, seems the following 11 mirrors need a gentle nudge about how they handle mac .dmg files. The theory is that these mirrors are not uptaking mac download files, because they have incorrectly set this filetype to be text/html. Intead dmg should be either application/octet-stream or preferably application/x-apple-diskimage.


http://ftp.chg.ru/pub/WWW/mozilla/firefox/releases/2.0.0.9/mac/en-US/Firefox%202.0.0.9.dmg
http://mozilla.mirrors.hoobly.com/firefox/releases/2.0.0.9/mac/en-US/Firefox%202.0.0.9.dmg
http://mirrors.xmission.com/mozilla.org/firefox/releases/2.0.0.9/mac/en-US/Firefox%202.0.0.9.dmg
http://www.artfiles.org/mozilla.org/firefox/releases/2.0.0.9/mac/en-US/Firefox%202.0.0.9.dmg
http://mozilla.mirror.pacific.net.au/firefox/releases/2.0.0.9/mac/en-US/Firefox%202.0.0.9.dmg
http://ftp.heanet.ie/mirrors/ftp.mozilla.org/pub/mozilla.org/firefox/releases/2.0.0.9/mac/en-US/Firefox%202.0.0.9.dmg
http://mirror.mcs.anl.gov/mozilla.org/firefox/releases/2.0.0.9/mac/en-US/Firefox%202.0.0.9.dmg
http://mozilla.ftp.iij.ad.jp/pub/mozilla/mozilla.org/firefox/releases/2.0.0.9/mac/en-US/Firefox%202.0.0.9.dmg
http://mirrors.yocum.org/mozilla/firefox/releases/2.0.0.9/mac/en-US/Firefox%202.0.0.9.dmg
http://mirrors.linux.edu.lv/mozilla.org/firefox/releases/2.0.0.9/mac/en-US/Firefox%202.0.0.9.dmg
http://ftp.yz.yamagata-u.ac.jp/pub/network/mozilla/firefox/releases/2.0.0.9/mac/en-US/Firefox%202.0.0.9.dmg
They're actually all 404.  The text/html you saw is the content-type of the 404 error message (when it gets that, the script was dumping the headers, so you could see the 404 below it).

The mirrors that were scanned were the ones by sentry as successfully serving Win32 files.  So these servers are either not pulling Mac bits or only pulling Windows bits (or sentry is broken and not removing people that don't have Windows, either, which is the case for at least ftp.chg.ru from a casual look)
Group: mozillaorgconfidential
Assignee: server-ops → justin
Component: Server Operations → FTP: Mirrors
QA Contact: justin → justdave
From my even more casual looking, I'd guess either sentry is broken, or the state of the mirrors varies a great deal with time, or both: at this very second, from my random choice of two, mozilla.mirror.pacific.net.au is serving application/x-apple-diskimage, and mirrors.yocum.org doesn't have a single 2.0.0.9 file for any OS, though it serves 2.0.0.8 as application/octet-stream just fine.
yeah, based on the criteria used to generate this list, if the windows files aren't present on that machine, bouncer never should have given me the URL, and sentry's busted.

Revised list coming up shortly.
Assignee: justin → morgamic
Severity: normal → critical
Component: FTP: Mirrors → Bouncer
Product: mozilla.org → Webtools
QA Contact: justdave → bouncer
Summary: dmg filetype incorrectly handled as text/html on 11 of 36 mirrors → sentry incorrectly flagging mirrors as having files available that don't
This report is generated using the following URL as a source of mirror urls:

https://download.mozilla.org/admin/mirror-list.php?product_id=316&os_id=2&submit=Update
(note that requires an admin login for bouncer to access that URL)

The product_id=316 and os_id=2 I was told by Morgamic is the standalone Firefox
2.0.0.9 download for Windows.  Several of these are coming up 404 for the Mac
version.  OK, so maybe people are excluding those.  But on spot-checking them,
several of them also don't have the Windows version, which is what sentry was
supposed to have assured already before generating that list of source mirrors.
how to read the report:

Each successful file retrieval will show:

mirror name      file size, timestamp, mime type

Each failed file retrieval will show:

mirror name       0  text/html

followed by the full URL of the file being attempted to retrieve, and the response headers generated by the server.

So a successful hit will only show one line, and a failed one will have several.

There's also the issue of people who do have it that have bad mime types, but that's less important here.
The 404s listed work now, and I need a better test case.  For the most part, 404s have not been an issue -- will have to take a closer look during the next release.  Has this been a problem for the releases since 2.0.0.9?
Status: NEW → ASSIGNED
I think we fixed this by having sentry treat a 200 response with a text/html content type as if it were 404.

If anyone has new occurrences of this please file a new bug.
Assignee: morgamic → justdave
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: