Closed
Bug 46655
Opened 25 years ago
Closed 23 years ago
"Downloading" dialog displays incorrect MIME type
Categories
(Core Graveyard :: File Handling, defect, P3)
Core Graveyard
File Handling
Tracking
(Not tracked)
mozilla0.9.9
People
(Reporter: jason1, Assigned: mscott)
References
()
Details
(Keywords: intl)
Attachments
(2 files)
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
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
Comment 2•25 years ago
|
||
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
Assignee | ||
Comment 3•24 years ago
|
||
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
Comment 5•24 years ago
|
||
nsbeta3-, not enough time left for this one.
Whiteboard: [nsbeta3+] → [nsbeta3-][cut 9/11]
Target Milestone: M18 → Future
Updated•24 years ago
|
OS: Windows 95 → All
Hardware: PC → All
Comment 7•24 years ago
|
||
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•24 years ago
|
||
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?
Reporter | ||
Comment 9•24 years ago
|
||
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 11•24 years ago
|
||
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 14•24 years ago
|
||
mscott: If you don't have time for this, any chance of some implementation notes? You said it was easy... Gerv
Comment 15•24 years ago
|
||
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•24 years ago
|
||
Comment 18•24 years ago
|
||
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•24 years ago
|
||
Comment 20•24 years ago
|
||
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•24 years ago
|
||
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
Updated•23 years ago
|
Updated•23 years ago
|
Target Milestone: --- → mozilla0.9.4
Assignee | ||
Comment 24•23 years ago
|
||
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
Comment 26•23 years ago
|
||
adding nsbranch- to keep track of it for future releases
Keywords: nsbranch-
Comment 27•23 years ago
|
||
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
Comment 28•23 years ago
|
||
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•23 years ago
|
||
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•23 years ago
|
||
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 32•23 years ago
|
||
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 35•23 years ago
|
||
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•23 years ago
|
||
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
Comment 37•23 years ago
|
||
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
Updated•8 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•