I am using Mozilla 1.2b on Linux with the latest version of the "plugger" plugin. If I have plugger installed, I am unable to view text/html pages which have a binary extension. E.g. .dat or .rpm. When I attempt to view a page with such an extension, the browser calls plugger to handle it, which of course it can't, and produces: Plugger: No appropriate application for type text/html found! This didn't happen with previous releases of mozilla. For an example, view the following URL with plugger installed: http://prdownloads.sourceforge.net/webadmin/webmin-1.020-1.noarch.rpm?download
the page sends the CORRECT mime-type (text/html: tested with wget, lynx, mozilla.org websniffer and it works in NS4.7x) confirming with win2k build 20021017.. we suck because we should handle the mime-type correctly !
Severity: normal → major
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Linux → All
Hardware: PC → All
To clarify what's going on: The patch for bug 163568 is biting us here. We're ignoring a type we can handle internally and that's correctly set by the server, inferring a completely bogus type based on an extension that is commonly associated with two completely different types, and trying to launch a plugin (plugger or realplayer) on HTML content. Worse yet, we are not even resetting the content-type on the channel to the type that corresponds to the extension! So we either get the wrong plugin or no plugin at all or best case feed completely bogus data to a plugin. I would suggest that bug 163568 be backed out until it can be fixed in a way that does not seriously regress normal web-browsing... (eg, having the realplayer plugin installed should _not_ keep me from downloading RedHat Package Manager packages that have the right type sent by the server!).
Severity: major → critical
Keywords: mozilla1.2, nsbeta1
*** Bug 175622 has been marked as a duplicate of this bug. ***
patch for bug 163568 has been backed out by check in for bug 169991 on 2002-10-20 21:08, so this regression should be gone, please confirm.
*** Bug 175688 has been marked as a duplicate of this bug. ***
It sounds like the Mozilla developers have snuck in a form of MIME-type second-guessing, a la MSIE, something that is very much against the standards and can have nasty consequences. In this case, the presence of anything at the end of a URL that looks like the file extension of a plugin data type triggers the plugin whether appropriate or not. One of the sillier results is the inability to read newsgroup posts from Australia, because the ".au" TLD resembles the file extension of a type of audio file. One can wonder / fear that a future version might attempt to execute anything from a .com domain under MS-DOS, since .com is an extension for DOS executables. I've got a test script in my site that detects some of this sort of MIME second-guessing (it trips up MSIE sometimes); the output of the following URLs is always of type text/plain, and a standards-compliant browser should show it that way: http://webtips.dan.info/cgi-bin/plaintext.pl http://webtips.dan.info/cgi-bin/plaintext.pl/test.html http://webtips.dan.info/cgi-bin/plaintext.pl/test.gif http://webtips.dan.info/cgi-bin/plaintext.pl/test.au http://webtips.dan.info/cgi-bin/plaintext.pl/test.swf http://webtips.dan.info/cgi-bin/plaintext.pl/test.exe
This is fixed. Dan, way to lump "mozilla developers" together, dude.
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED
OK, I should have been more careful and said "*some* Mozilla developer" rather than "Mozilla developers". My outrage at seeing such an abomination before the Lord as MIME-type second-guessing turn up in Mozilla blinded me, I guess.
*** Bug 179425 has been marked as a duplicate of this bug. ***
*** Bug 181594 has been marked as a duplicate of this bug. ***
Marking this Verified Fixed Build ID 20030515
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.