46655 - "Downloading" dialog displays incorrect MIME type

Status: VERIFIED DUPLICATE of bug 78943

(Core Graveyard :: File Handling, defect, P3)

Description

[Jason Summers]

From Bugzilla Helper:
BuildID:    2000072704

When downloading a file via HTTP, Mozilla appears to be attempting to 
manufacture a MIME type based on the URL, rather than simply using the MIME type 
that it received from the web server.  It uses this potentially incorrect MIME 
type to determine a helper application.

Reproducible: Always
Steps to Reproduce:
1. Go to http://home.mieweb.com/jason/testbed/mime/
2. Click on file.html in the application/zip row (for example)

Actual Results:  Mozilla reports a MIME type of text/html, asserts that it 
cannot view text/html, and offers to open using "htmlfile".

Expected Results:  Browser reports a MIME type of application/zip, and possibly 
offers to run a ZIP helper app.

Even if the "file extension" is not recognized at all by Mozilla, it still tries 
to make up a MIME type. A URL that ends in ".foo" will result in a nonsensical 
"foo/foo" type.

This behavior does not occur when typing a URL into the location bar, or when a 
URL has no extension. A totally different dialog box is shown instead, with the 
correct MIME type.

This behavior does not occur if the MIME type is application/octet-stream, 
regardless of the extension.

Comment 1

[Gagan]

Hmm... seems like a problem with the default MIME type selection. This is mscott 
I believe...

Comment 2

[Peter 'Rufus' Nelson]

confirming.  this doesn't happen for all of the files, but does for enough to be
a problem.  One strange behavior, if you just click on file.gif in the zip row,
it says it's an image/gif, but if you "Open Link in New Window" it recognizes
the application/zip mime fine.

Comment 3

[Scott MacGregor]

I think this exposes a bug in the logic of the external app handler where if we
can't find a helper app for the content type we were told the document had, then
I fall back and try to get a content type based on file extension.

I don't think I should fall back and do the file extension guessing after
missing a lookup for the specified content.

The fix is easy and I have a feeling it's going to bite us with bigger problems
than just this. 

Comment 4

[Scott MacGregor]

nsbeta3+ per triage meeting.

Comment 5

[selmer (gone)]

nsbeta3-, not enough time left for this one.

Comment 6

[Henrik Gemal]

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

Comment 7

[[e-mail]]

What looks really silly is if you download an attachment that names "LOG.TXT"
but whose content type is "application/octet-stream". The resulting downloading
message complains that Mozilla can't handle plain text files :-(

Comment 8

[sairuh (rarely reading bugmail)]

clearing milestone, adding beta1 and catfood kw's for reconsideration. tever,
i'll take this off your hands for the nonce. :)

still occurs using 2001.03.29.08 bits: the incorrect MIME type is being
displayed in the Downloading dialog.

Jason, your testbed is amazing! would you mind if i posted it to my testcases on
mozilla.org?

Comment 9

[Jason Summers]

Thanks. You're welcome to list it there, of course. I have also put the whole 
thing in a zip file for anyone to download and install on their own 
suitably-configured web server, if desired.

Comment 10

[Boris Zbarsky [:bzbarsky]]

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

Comment 11

[Gervase Markham [:gerv]]

mscott: This is causing issues after the XUL syntax change, because Mozilla 
claims it can't handle "application/vnd.mozilla.xul+xml" when it gets sent 
illegal text/xul. This is horribly confusing.

You said the fix was easy, is there any chance of getting it?

Gerv

Comment 12

[David Hyatt]

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

Comment 13

[Gervase Markham [:gerv]]

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

Comment 14

[Gervase Markham [:gerv]]

mscott: If you don't have time for this, any chance of some implementation
notes? You said it was easy...

Gerv

Comment 15

[Boris Zbarsky [:bzbarsky]]

OK.  I found it exruciatingly difficult to work on some other bugs due to this
one, so.. patch coming up.  reviews anyone?  The patch also fixes some comments
to agree with reality.

Comment 16

[Boris Zbarsky [:bzbarsky]]

Attachment: Patch to remove the extension-guessing

Comment 17

[timeless]

should we put that code into #if 0 instead of removing it?

Comment 18

[Boris Zbarsky [:bzbarsky]]

Hmm.  That might be a good idea.  If so, I suggest coming up with a define name
and using #ifdef, since if the symbol is defined some of the code I added can go
away.  So the code will look like:

#ifdef GUESS_MIMETYPE_FROM_EXTENSION
 // Guessing code here
#endif // GUESS_MIMETYPE_FROM_EXTENSION
// some code
#ifndef GUESS_MIMETYPE_FROM_EXTENSION
 // get the filename here
#endif // GUESS_MIMETYPE_FROM_EXTENSION
// more code

How does that look?  Will create a new patch later today.

Comment 19

[Boris Zbarsky [:bzbarsky]]

Attachment: Better patch

Comment 20

[Bill Law]

Much of this is fixed, I think, as part of the patches attached to bug 52454.
At least it fixes the problem related to the mime-type being reported
incorrectly in the dialog.

There still might be an unresolved issue with doing the OS lookup with
preference given to the file extension rather than the real mime-type from the
server.  But I'd like to see that fixed in context of the new code, rather than
a patch to the old.

Comment 21

[Boris Zbarsky [:bzbarsky]]

adding dependency on bug 52454.  The patch there does indeed fix the problem we
are seeing with the dialog.  In fact, the behavior that patch leads to is OK
with me....

Comment 22

[Keyser Sose]

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

Comment 23

[basic]

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

Comment 24

[Scott MacGregor]

I haven't had a chance to look at this patch yet. I'll look at it in .9.5

Comment 25

[Scott MacGregor]

not for the eMojo branch. adjusting nsBranch status.

Comment 26

[msanz]

adding nsbranch- to keep track of it for future releases

Comment 27

[sairuh (rarely reading bugmail)]

spam: over to File Handling. i have not changed the assigned developer [or the
other fields for that matter], so if anyone realizes that a bug should have a
more appropriate owner, go ahead and change it. :)

Comment 28

[Dan Tobias]

I'm disappointed that Mozilla does any MIME type second-guessing at all... I've
been critical of Microsoft for years for its own flouting of the standards in
this regard.  Mozilla at least doesn't try to second guess "text/plain", or any
other type it supports, but apparently it's trying to "sniff" other types still,
a bad idea.

Comment 29

[Boris Zbarsky [:bzbarsky]]

We only sniff on something without a type or application/octet-stream.  Reason
is, application/octet-stream is a pretty useless type for actually doing
anything with.  So sniffing that makes some sense.

Comment 30

[Bradley Baetz (:bbaetz)]

We have to do entention-matching if a content type isn't present, and the way
the code triggers the downloading dialog is by pretending that a content type
header wasn't sent. We don't sniff.

The way we do this currently is wrong; hence this bug.

Comment 31

[Bradley Baetz (:bbaetz)]

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

Comment 32

[Spiros Ioannou]

I just noticed this bug with my mp3 server:

I send "Content-Type: audio/mpeg-url" but the dialog box asks what to do with the "audio/mpegurl" mime type (without the "-"). The extention of the .cgi is ".m3u"

Comment 33

[Boris Zbarsky [:bzbarsky]]

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

Comment 34

[scottputterman]

moving to 0.9.9

Comment 35

[Bill Law]

I think that this was fixed per bug 52454...

...except for the fact that part of 52454 was backed out, as discussed in bug
78943.  78943 has a patch attached which fixes this problem (although it happens
to expose another problem in the uriloader in one special case; or did a long
time ago).

Can we close this bug as a dup of bug 78943?

Comment 36

[Boris Zbarsky [:bzbarsky]]

resolving duplicate....  I think this now behaves in a reasonable way.

*** This bug has been marked as a duplicate of 78943 ***

Comment 37

[sairuh (rarely reading bugmail)]

mass verification of duplicate bugs: to find all bugspam pertaining to this, set
your search string to "DuplicateBugsBelongInZahadum".

if you think this particular bug is *not* a duplicate, please provide a
compelling reason, as well as check a recent *trunk* build (on the appropriate
platform[s]), before reopening.