Closed
Bug 205954
Opened 22 years ago
Closed 21 years ago
The file "text,file" is of type text/plain (Text File), and Mozilla does not know how to handle this file type.
Categories
(Core :: Networking, defect, P4)
Tracking
()
RESOLVED
FIXED
Future
People
(Reporter: neil, Assigned: bzbarsky)
References
()
Details
Steps to reproduce problem:
1. Follow URL
2. Gasp in astonishment
Comment 1•22 years ago
|
||
hmm.. that is odd. of course, i don't think "text" is a valid mime type. still
not sure how mozilla manages to determine that it is actually text/plain. that
is a bit odd.
Severity: normal → trivial
Target Milestone: --- → Future
![]() |
Assignee | |
Comment 2•22 years ago
|
||
The text/plain comes from the hashtable lookup in
nsExternalHelperAppService::GetFromMIMEType. The problem is that mMimeInfoCache
stores pointers to MIME info objects, with MIME types and extensions both used
as keys (so the text/plain object can be found under the keys "txt", "text", and
"text/plain"; see the defaultMimeEntries for the full list of what's in the
hashtable).
One solution to that issue would be to have separate tables for extension and
type lookups. Another would be to rethink this whole hashtable thing....
In any case, the issue of nsExternalHelperAppService being unable to kick a load
back to the URILoader if it discovers that the data is of a type we handle is a
known one (currently blocking implementation of a "view as text" option in the
helper app dialog, eg), and there should be existing bugs on it....
Comment 3•22 years ago
|
||
I have this bug happen as well to me, except with JPEG files.
Here is a URL that demonstrates the problem, which can be reproduced 100%.
(This site might require registration to access. No problem with spam, it's a
known good site.)
http://www.vpforums.com/forum/showthread.php?s=&threadid=25340
Click on the attachment that has been attached to the topmost message.
It is a JPEG image file.
MSIE will open that image in the browser, as it should.
Mozilla will put up a box, surprisingly, asking what to do with it!
The file "filenamehere.jpg.jpeg" is of type image/jpeg (JPEG Image), and Mozilla
does not know how to handle this file type.
It's a standard open-or-save dialog box, that appears when downloading files of
unknown MIME type. I'm not sure why Mozilla won't recognize JPEG images from
here. It handles JPEG images just fine on all other websites, though.
Notice how it wrongly appends ".jpeg" to the filename, which already has the
".jpg" extension!
Here's the headers from the server (generated from packet sniffer after clearing
Mozilla's cache and trying again). I changed the name of the filename (not the
extension) because it's very long and irrelevant here. The headers look pretty
standard to me.
HTTP/1.1 200 OK
Date: Thu, 26 Jun 2003 08:18:35 GMT
Server: Apache/1.3.19 (Unix) (Red-Hat/Linux) mod_gzip/1.3.19.1a mod_perl/1.24_0
1 PHP/4.2.1 FrontPage/5.0.2 mod_ssl/2.8.5 OpenSSL/0.9.6
X-Powered-By: PHP/4.2.1
X-Accelerated-By: PHPA/1.3.1pre3
Cache-control: max-age=31536000
Expires: Fri, 25 Jun 2004 08:18:35GMT
Last-Modified: Fri, 13 Jun 2003 13:18:42GMT
Content-disposition: atachment; filename=filenamehere.jpg
Content-Length: 99700
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: image/jpeg
Once again, this bug is 100% reproduceable on the latest Mozilla. MSIE properly
opens the same image without a problem.
Comment 4•22 years ago
|
||
Krellan: That's an error in the vbulletin board and they must update their
vbulletin version. see bug 183653
![]() |
Assignee | |
Comment 5•22 years ago
|
||
I should take this, I guess, unless biesi wants it... (and Matti is right --
comment 3 is completely irrelevant to this bug).
Assignee: darin → bzbarsky
Priority: -- → P4
Comment 6•22 years ago
|
||
Yeah, the browser's non-handling of the download is due to the
Content-disposition header. I used ethereal to spy on the Bugzilla install that
I was having trouble with, and compare it to this install of Bugzilla. Note the
"attachment" vs. "inline" in the Content-disposition header:
"Very old" version of Bugzilla:
HTTP/1.1 200 OK
Date: Mon, 14 Jul 2003 19:57:24 GMT
Server: Apache/1.3.12 (Unix) (Red Hat/Linux) AuthMySQL/2.20 ApacheJServ/1.1.1b2-dev
Content-disposition: attachment; filename=sampleStage3XML.xml
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/plain; name=sampleStage3XML.xml
bugzilla.mozilla.org as of July 14, 2003:
HTTP/1.1 200 OK
Date: Mon, 14 Jul 2003 20:02:15 GMT
Server: Apache/1.3.26 (Unix) mod_throttle/3.1.2
Content-Disposition: inline; filename=filebook.diff
Content-Length: 3275
Keep-Alive: timeout=15, max=97
Connection: Keep-Alive
Content-Type: text/plain; name="filebook.diff"
Comment 7•22 years ago
|
||
I'm not sure its the same problem, but try browsing to http://members.aol.com/royalef/gifmake.htm
This results in the impressive message that Mozilla Firebird does not know how to handle HyperText Markup Language.
Is there something wrong with my Moz install or with Moz itself? Workarounds?
FWIW I'm running Firebird nightly #20030701.
![]() |
Assignee | |
Comment 8•22 years ago
|
||
That looks like a different issue -- bug 213900 filed.
Comment 9•21 years ago
|
||
this got fixed when the hashtable in this code was removed, which was bug
212468 (fixed Jul 14 2003)
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•