Closed Bug 46655 Opened 24 years ago Closed 23 years ago

"Downloading" dialog displays incorrect MIME type

Categories

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

Product:
Core Graveyard
Component:
File Handling
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED DUPLICATE of bug 78943
Milestone:
mozilla0.9.9

People

(Reporter: jason1, Assigned: mscott)

References

(
URL
)

Details

(Keywords: intl)

Attachments

(2 files)

Patch to remove the extension-guessing
2.31 KB, patch
Details | Diff | Splinter Review
Better patch
1.87 KB, patch
Details | Diff | Splinter Review 
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.
Hmm... seems like a problem with the default MIME type selection. This is mscott 
I believe...
Assignee: gagan → mscott
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
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.
Keywords: nsbeta3
Target Milestone: --- → M18
nsbeta3+ per triage meeting.
Whiteboard: [nsbeta3+]
nsbeta3-, not enough time left for this one.
Whiteboard: [nsbeta3+] → [nsbeta3-][cut 9/11]
Target Milestone: M18 → Future
*** Bug 58319 has been marked as a duplicate of this bug. ***
OS: Windows 95 → All
Hardware: PC → All
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 :-(
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?
Component: Networking → XP Apps
Keywords: nsbeta3 → nsbeta1, nsCatFood
QA Contact: tever → sairuh
Whiteboard: [nsbeta3-][cut 9/11]
Target Milestone: Future → ---
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.
URL: http://home.mieweb.com/jason/testbed/... → http://entropymine.com/jason/testbed/...
*** Bug 74510 has been marked as a duplicate of this bug. ***
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
*** Bug 77215 has been marked as a duplicate of this bug. ***
Blocks: 70939
*** Bug 76998 has been marked as a duplicate of this bug. ***
mscott: If you don't have time for this, any chance of some implementation
notes? You said it was easy...

Gerv
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.
Keywords: patch, review
should we put that code into #if 0 instead of removing it?
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.
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.
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....
Depends on: 52454
Keywords: 4xp
Blocks: 78106
Depends on: 78943
Blocks: 61408
*** Bug 78571 has been marked as a duplicate of this bug. ***
*** Bug 81418 has been marked as a duplicate of this bug. ***
Keywords: intl, nsBranch
Target Milestone: --- → mozilla0.9.4
I haven't had a chance to look at this patch yet. I'll look at it in .9.5
Target Milestone: mozilla0.9.4 → mozilla0.9.5
Blocks: 99230
not for the eMojo branch. adjusting nsBranch status.
Keywords: nsbeta1, nsbranch
Target Milestone: mozilla0.9.5 → mozilla0.9.6
No longer blocks: 99230
adding nsbranch- to keep track of it for future releases
Keywords: nsbranch-
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. :)
Component: XP Apps → File Handling
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.
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.
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.
*** Bug 104384 has been marked as a duplicate of this bug. ***
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"
Blocks: 107067
Keywords: nsbranch-
*** Bug 107470 has been marked as a duplicate of this bug. ***
moving to 0.9.9
Target Milestone: mozilla0.9.6 → mozilla0.9.9
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?
resolving duplicate....  I think this now behaves in a reasonable way.

*** This bug has been marked as a duplicate of 78943 ***
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
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.
Status: RESOLVED → VERIFIED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: