News (usenet) posts with .au domains display corrupt QuickTime plugin instead of text.

RESOLVED FIXED in mozilla1.2beta

Status

()

Core
Plug-ins
P2
major
RESOLVED FIXED
15 years ago
15 years ago

People

(Reporter: Dash, Assigned: Peter Lubczynski)

Tracking

({regression})

Trunk
mozilla1.2beta
regression
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [PL2:NA], URL)

Attachments

(4 attachments, 3 obsolete attachments)

(Reporter)

Description

15 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2b) Gecko/20020920
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2b) Gecko/20020920

Random (to each execution of Mozilla), some plain-text Usenet posts display a
QuickTime plugin that failed to load, instead of the content.

Source of the message (have to use View.Message Source, Ctrl+U fails on these
messages) is seemingly normal with nothing out of the "norm".  Message often
viewable after restarting Mozilla.

QuickTime 5.0.2 Pro installed.

Reproducible: Sometimes

Steps to Reproduce:
1. Load Usenet.
2. Subscripe to any newsgroup.
3. Browse messages until locate.

Actual Results:  
See details.

Expected Results:  
Display a plain-text message.
Unable to test binary messages.

Updated

15 years ago
QA Contact: olgam → stephend

Comment 1

15 years ago
win32 trunk build 2002092404, win98se

I see this, too, particularly on posts from one particular person ("rf", a
regular poster in alt.html.critique and some c.i.w.a.* groups).  Pretty much all
keyboard shortcuts appear to be disabled while this message is in view, too, but
the mouse works OK, so View Source is available from the menu.  Will attach the
source of one of these posts.  The posts from this individual display just fine
in the 2002091008 build.  The saved .eml file also displays fine in the browser
window, even on the 0924 build.

Comment 2

15 years ago
Created attachment 100540 [details]
source of an offending message
(Reporter)

Comment 3

15 years ago
Created attachment 100560 [details]
Another sample

This is a random message that generates the bug, I can't see anything wrong
with it's source.

Comment 4

15 years ago
Created attachment 100663 [details]
screenshot showing the problem

Looks like the problem starts with the 2002091808 build.  0917 looks fine.

I see the broken QT plugin instead of the message text on all posts for
particular individuals.  The common denominators between them are:

1. Newsreader MS OE v6
2. NNTP posting host somewhere in Australia

Probably coincidence, but it was pretty odd.

Comment 5

15 years ago
Seems the Aussie connection is more than just coincidence.  Go into QuickTime
Preferences, Browser Plug-in MIME settings and uncheck Audio type:
uLaw/AU audio file (au,snd,ulw)

The message text for the broken posts starts displaying normally.
BTW, I also have QuickTime 5.02.

So, steps to reproduce are:
1. Install QT plug-in, check Browser plug-in Audio MIME type for "au"
2. Start mail-news (plugins disabled in mail-news may also be relevant)
3. View a post that originated on an Australian server*.
The expectation is that the message text displays, actual result is a broken QT
plug-in.

* This probably happens with mail or news, but I don't correspond with anyone
from Australia so I can't verify mail.  I found 3 Australian posters, including
"rf", on Usenet newsgroup alt.html.  All of their posts showed the broken QT
plug-in before changing the MIME type, all displayed normally afterwards.

BTW, I would change this bug's status from Unconfirmed to New, but I am not
authorized to do so.
Confirming.  I can't even read the message in the client, although I can see the
message in the source.

news://news.mcom.com:119/ks9h9.9695$Ee4.23266@news-server.bigpond.net.au is an
example of one.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: nsbeta1

Comment 7

15 years ago
Confirmed Win98se Mozilla build 2002092904

Also confirming the Australian connection as well for whatever odd reason.
Jay, it's most likely because the top level domain of .au is being read as the
Quicktime file extension .au.  See comment 5.

Comment 9

15 years ago
I see this on OS/2 and can confirm that the issue is the ".au" extension.

On OS/2, we have a separate audio plugin looking for .au and it gets loaded in
these cases.
OS: Windows 2000 → All
Hardware: PC → All

Comment 10

15 years ago
This happened between 9/17 and 9/18

The bug referenced in peterl's checkin to nsPluginHostImpl.cpp is incorrect.

Looks suspicious.

copying peterl

Comment 11

15 years ago
possible regression from bug 163568?

Comment 12

15 years ago
Mozilla build ID 2002092704 on Win98 SP1

one more news from australia displays corrupt QuickTime plugin:
snews://secnews.netscape.com:563/3D942C75.69935997@labyrinth.net.au

BTW, context menu is missing some functions with snews://
i.e. Open Link in New Window, Open Link in New Tab, Save Link Target As ...
Ctrl-U doesn´t work, but View/PageSource does.

Comment 13

15 years ago
Peter:   Yes, backing out the patch for bug 163568 does indeed fix this bug.
-> Plugins
Assignee: sspitzer → beppe
Component: Mail Window Front End → Plug-ins
Keywords: regression
Product: MailNews → Browser
QA Contact: stephend → shrir

Comment 15

15 years ago
hmm, handing this over to Peter since the patch back out fixes the problem
Assignee: beppe → peterl
Priority: -- → P2
Whiteboard: [PL2:NA]
Target Milestone: --- → mozilla1.3alpha

Comment 16

15 years ago
I'm a little disappointed in the target here. This is a pretty huge regression.

Comment 17

15 years ago
Ummm yes I agree with Michael.  This bug prevents me from using any trunk
builds, and if it continues I won't even be able to use 1.2beta.  Why isn't the
bad code being backed out?  I don't think anyone really needs to go to
http://www.exoticeroticball.com/ =)

Comment 18

15 years ago
Created attachment 101798 [details] [diff] [review]
patch v.1

Here's the fix. Please review.

Updated

15 years ago
Status: NEW → ASSIGNED
Keywords: patch
Target Milestone: mozilla1.3alpha → mozilla1.2beta

Comment 19

15 years ago
Comment on attachment 101798 [details] [diff] [review]
patch v.1

r=av
Attachment #101798 - Flags: review+

Comment 20

15 years ago
Hm...this seems to be working just fine without the last patch in the build I
just made. I think something checked in this weekend, possibly the fix from bug
157135, fixed this. Marking WFM.
Status: ASSIGNED → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → WORKSFORME

Comment 21

15 years ago
Still seeing it on nightly build 2002100714 (winxp)
(Reporter)

Comment 22

15 years ago
I'm also still seeing it, using the same build (2002100714) Win32.
*** Bug 173207 has been marked as a duplicate of this bug. ***
Reopening.  
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---

Comment 25

15 years ago
Created attachment 102197 [details] [diff] [review]
patch v.2

I must have had a bad build. I see the problem again today.

Here's a new patch that makes http://www.exoticeroticball.com/ and
news://news.mcom.com:119/ks9h9.9695$Ee4.23266@news-server.bigpond.net.au work
in todays build.
Attachment #101798 - Attachment is obsolete: true

Comment 26

15 years ago
Comment on attachment 102197 [details] [diff] [review]
patch v.2

So, the patch leaves out those schemes which do not implement |nsIStandardURL|,
r=av

Updated

15 years ago
Attachment #102197 - Flags: needs-work+

Comment 27

15 years ago
Comment on attachment 102197 [details] [diff] [review]
patch v.2

peterl:

why is that you want to only do this for URLs that happen to implement
nsIStandardURL?  i don't understand the connection.  doing this kind of
filtering seems very fragile.  what are you really trying to get at here? 
would a whitelist of URI schemes make more sense?

i would only consider this patch as a temporary, last-resort sort of solution.
*** Bug 173730 has been marked as a duplicate of this bug. ***
Summary: Random usenet posts display corrupt QuickTime plugin instead of text. → News (usenet) posts with .au domains display corrupt QuickTime plugin instead of text.

Comment 29

15 years ago
What bothers me is that the plugin programm is started even though my
preferences say that plugins shouldn't be started for mail and news. Is this
addressed with the current patch or could some evil person still manage to get a
plugin executed?
Edit | Advanced | Scripts & Plugins.

Is "Mail & Newsgroups" checked under "Enable Plugins for"?

For me, it is, which is no surprise why this is then behaving like this. 
However, I thought that we wanted to disable plugin support in mail.  I verified
the bug on disabling JS in mail, but not plugins (if there indeed was such a bug).

Yulian/Scott, do you remember such a bug?

Comment 31

15 years ago
I believe Plugins are disabled for Mail/News by default.
That's how it is on my machine (unchecked)

Yet the newsposts from .au will all cause the Quicktime Plugin to load.

Comment 32

15 years ago
It isn't checked, so plugins shouldn't be enabled.

Comment 33

15 years ago
additional to comment 30 : I haven't activated plugins (and JS) for Mail&News
and use "show message body"=>"Plain text".. I see QT too. Another person of
de.comm.software.mozilla sees another plugin that's related to .au - files  on
his computer.
(using nightly 20021008-08)

Comment 34

15 years ago
It appears that the underlying problem is not restricted to QuickTime.
This message: <87d6qbpqsj.fsf@my.vilmos.lan> tried to load a plugin (LA? some
sort of audio file) as well. This is with build 2002092408.

Comment 35

15 years ago
Created attachment 103017 [details] [diff] [review]
patch v.3

This patch limits the fix from bug 163568 to only HTTP channels that have
succeeded so mail/news souldn't be effected. File channels are taken care of
somehwere else and we can add other type as needed.

Updated

15 years ago
Attachment #102197 - Attachment is obsolete: true

Comment 36

15 years ago
I just had a look over at bug 163568 and the "fix" offered there seems to be the
cause of this problem.  Did this whole problem occur because of a mis-configured
web server?  

If I understand that correctly then I don't understand.  Why would any effort be
expended on the part of the browser to attempt to compensate for a misconfigured
web server?

The proper action would be to *always* rely on the content type as specified by
the server for any items "served".  The much less reliable name extension should
only be used in the case of local items for which there is no other source for
determining the content type.  

If a user is inconvenienced by a misconfigured web server it's not the concern
of the browser in any way.  The web server is the offender, and the problem
should be fixed on that end.  

Trying to do what I think I see being done here is just begging for trouble. 
We've already seen one unfortunate aspect of it.  What happens when malicious
payload is suitably named and served?

Comment 37

15 years ago
Every other browser works fine with the testcase in bug 163568 so we should too
rather than trying to evanglize. 4.x plugins specifically list which URL
suffixes to look for. The last patch here only does that for http channels which
I think will fix both of these bugs.

Comment 38

15 years ago
Comment on attachment 103017 [details] [diff] [review]
patch v.3

ok, this is marginally better.	i still think the correct solution is to fix
the mailnews URL parsing, but i'm OK with this patch in light of the fact that
the mailnews changes are likely non-trivial.  please make sure there is a bug
filed against mailnews to cleanup their URL parsing.  thx!!

sr=darin
Attachment #103017 - Flags: superreview+

Comment 39

15 years ago
thanks for the review darin! bug 175344 has been opened
Status: REOPENED → ASSIGNED
Keywords: mozilla1.2

Comment 40

15 years ago
Comment on attachment 103017 [details] [diff] [review]
patch v.3

r=av
Attachment #103017 - Flags: review+
Why in the world are we ignoring MIME types in favor of extensions?
Sorry, even with that patch this whole thing is unacceptable due to the
regression bug 175368.

We should only be triggering off the extesion if there is no registered handler
(content handler, plugin, helper application, etc) for the content type.  That
solution would still fix bug 163568 without breaking the world.

If we have to not trust the content-type, we should be trusting sniffing of
content data over extension, imo.
Blocks: 175368

Comment 43

15 years ago
Created attachment 103384 [details] [diff] [review]
patch v.4

bug 163568 has started working without this code and since it seems to break
stuff, here's a patch to back it out

Updated

15 years ago
Attachment #103017 - Attachment is obsolete: true
Comment on attachment 103384 [details] [diff] [review]
patch v.4

sr=bzbarsky.

Perhaps there's a way we can have the external helper app service detect the
plugin and do the right thing?	Not sure how possible or not that is...
Attachment #103384 - Flags: superreview+

Comment 45

15 years ago
Comment on attachment 103384 [details] [diff] [review]
patch v.4

r=darin for backout
Attachment #103384 - Flags: review+

Comment 46

15 years ago
*** Bug 175433 has been marked as a duplicate of this bug. ***
Comment on attachment 103384 [details] [diff] [review]
patch v.4

a=dbaron for trunk checkin.

Please make sure there's a bug filed on the bad parsing of the mailnews URI
types as well.
Attachment #103384 - Flags: approval+

Comment 48

15 years ago
Filed bug 175344 about the urls. 

patch in trunk, marking FIXED
Status: ASSIGNED → RESOLVED
Last Resolved: 15 years ago15 years ago
Resolution: --- → FIXED

Comment 49

15 years ago
Thanks, it WFM now in nightly build 2002102104.

Comment 50

15 years ago
*** Bug 175923 has been marked as a duplicate of this bug. ***

Comment 51

15 years ago
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.  The misinterpreting of the ".au" TLD is
among the sillier consequences.  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
It sounds like _a_ mozilla developer snuck something like that in, yes... did
you even read this bug?

(Though we're about to run into the issue of whether text/plain for .dmg.gz
files is or is not really text/plain... this may become a necessity because no
web server I have ever seen serves OSX binaries with the right mime type.... 
standards are nice, but not if they mean you can access 0% of the content out
there.  As I mentioned in this bug already, if we have to guess at the type, we
should look at magic numbers, not extensions.)

Comment 53

15 years ago
In standard Apache setups, a webmaster can set up MIME types for any particular
subdirectory via .htaccess files.  While some hosting sites disable this, they
are in the minority.  Thus, the majority of site developers are capable of
serving their sites with proper MIME types regardless of the content types or
file extensions they may wish to use.  If they don't trouble themselves to do
so, is it the job of the browser to second-guess it even though this may well
cause other perfectly legitimate sites to break, or even worse, provide a back
door for virus or trojan-horse programs to get themselves executed?
This is all true.  And if people actually update their mime types, we don't have
to do anything.  That would be very nice, since I would much prefer not to have
to muck with this.

Comment 55

15 years ago
Although some new servers come nicly configured for some mime types, that's
usually not that case for plugins which have more exotic mime types and
especially not the case with some really old non-configurable servers or web
applications which are probably not going to change for a very long time. The
web is not perfect and we've got to adapt rather than encourage behavior that
*forces* the average user to switch to another browser to view the page.

At the macdev meeting, someone suggested sniffing for a binary null in the first
1k of a stream for displayable mime types as a possible means of falling back to
the extension.

Comment 56

15 years ago
Here's what the W3C has to say about MIME-type second guessing:

The architecture of the Web depends on applications making 
dispatching and security decisions for resources based on their 
Internet Media Types and other MIME headers. It is a serious 
error for the response body to be inconsistent with the 
assertions made about it by the MIME headers. Web software SHOULD 
NOT attempt to recover from such errors by guessing, but SHOULD 
report the error to the user to allow intelligent corrective 
action.
http://www.w3.org/2001/tag/2002/0129-mime

Here's somebody's test suite for MIME type handling:
http://entropymine.com/jason/testbed/mime/

I hope Mozilla doesn't plan on turning over to the Dark Side of the Force by
imitating the Evil Empire's browser in its disregarding of standards, something
that has the pernicious consequence of encouraging sloppy server configuration,
where webmasters say "It works in MSIE, so it must be the other browser's fault
if it won't render."  Even worse, it creates openings for malicious content to
slip through firewalls and proxies that screen based on MIME headers.  It also
frustrates Web developers whenever they are attempting to do a valid but rare
thing, like serve plain text via a URL ending in some extension other than .txt
(especially common for output of CGI scripts), and the browser refuses to take
it at face value.
Dan, please stop ranting.  We all know what that part of the spec says.  We all
know about the entropymine test suite (certainly anyone who's working on MIME
stuff in Mozilla does).  You obviously failed to read the part of my comment
that said that _if_ (and that's a huge if) we start not trusting content-types
then we should use data-sniffing, not extensions.

Get a grip man.  There is no sinister conspiracy to do anything.  There are just
people who want the browser to 1) follow the standards and 2) be usable.  When
those two are in direct conflict, one must tread carefully.
(Reporter)

Comment 58

15 years ago
Confirmation that everything works in Win32 build 2002102204.

The major problem with second guessing is the security issue.  I feel my
computer is safe when I use Mozilla.  Mainly because it doesn't second guess -
or so I thought!

Comment 59

15 years ago
I apologize if I'm offending anyone by my rants, which show that in my own
psychology I do think of this sort of thing as a religious issue... but I guess
I shouldn't try to impose my religion on others.

I'd like to know more about this "OSX binary" problem alluded to... the
execution of binary programs of any sort is obviously a significant security
risk, so if the capability of doing so is to be present in a Web browser it
needs to be implemented very, very carefully... any setup that might cause the
browser to start executing something when and where the user does not expect it
can be a severe problem.

And I will note that my observations of MSIE are that it, too, attempts some
sort of "smart" content sniffing, for which the file extension is not the only
(or even the most important) factor, though it is one of the things looked at. 
Thus, Mozilla would be heading down the same road as MSIE if it were to start
analyzing data content and disregarding MIME types in some cases, and this
approach does cause MSIE to fail in some cases where a standards-compliant
browser succeeds.
These are not executable we would execute but ones the user wants to download
(the standard format for OSX packages are these .dmg.gz files that Apache will
serve as text/plain with content-encoding:gzip).  The Windows equivalent would
be showing all .exe files as plaintext.  The Linux equivalent would be showing
all .tar.gz files as plaintext (or all .rpm files).

See bug 175848 for the discussion on that, and please do not spam it with "this
is evil" comments... everyone involved already knows that.  The question is how
to resolve a real-life problem at the same time.
*** Bug 177673 has been marked as a duplicate of this bug. ***

Comment 62

15 years ago
*** Bug 178673 has been marked as a duplicate of this bug. ***
*** Bug 179101 has been marked as a duplicate of this bug. ***

Comment 64

15 years ago
*** Bug 179345 has been marked as a duplicate of this bug. ***

Comment 65

15 years ago
*** Bug 179806 has been marked as a duplicate of this bug. ***

Comment 66

15 years ago
*** Bug 172536 has been marked as a duplicate of this bug. ***
*** Bug 180511 has been marked as a duplicate of this bug. ***

Comment 68

15 years ago
*** Bug 181433 has been marked as a duplicate of this bug. ***
*** Bug 181439 has been marked as a duplicate of this bug. ***
*** Bug 181718 has been marked as a duplicate of this bug. ***

Comment 71

15 years ago
*** Bug 182120 has been marked as a duplicate of this bug. ***

Comment 72

15 years ago
*** Bug 188589 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.