Closed Bug 175368 Opened 18 years ago Closed 18 years ago

Mozilla cannot view text/html pages with a non-standard extension when "plugger" installed


(Core :: Plug-ins, defect)

Not set





(Reporter: dj, Assigned: rubydoo123)





(2 files)

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:
the page sends the CORRECT mime-type (text/html: tested with wget, lynx, 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
Ever confirmed: true
OS: Linux → All
Hardware: PC → All
Attached file http log
Depends on: 169991
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
Blocks: 175582
*** 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:
The backout from comment #6 has cured bug 175688, see comment #7.
This is fixed.  Dan, way to lump "mozilla developers" together, dude.
Closed: 18 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
You need to log in before you can comment on or make changes to this bug.