149705 - full page plugins don't work by file extension

Status: RESOLVED WONTFIX

(Core Graveyard :: Plug-ins, defect, P3)

Description

[shrirang khanzode]

this is a re-incarnation of bug 47712

on 0604 brnch, have flash plugin installed

load the above url, observe ascii text /garbage load in the content window 
instead of a helper app launching.

Comment 1

[Matthias Versen [:Matti]]

Are you sure that the bug is valid ?
If the server sends Text/plain for the swf this is invalid (or not?)
(BTW: I hate internal test-cases :-) )

Comment 2

[shrirang khanzode]

eeks..let me check then :)

Comment 3

[Peter Lubczynski]

Plugins are special, they need to given a chance to override.

Comment 4

[shrirang khanzode]

matti, here's a test url from a site.  

http://multimedia.ogrish.com/download.php?filename=danielpearl.asf

Comment 5

[Peter Lubczynski]

Nope Shrir, that testcase is invalid because it's a PHP link cgi link. In that
testcase, the server really is misconfigured. In the case of slip, it's directly
pionting at a swf that the server is says is text/plain.

Comment 6

[shrirang khanzode]

uh ok

Comment 7

[Boris Zbarsky [:bzbarsky]]

What makes plugins special?  That is, if we show .html files served as
text/plain in plaintext, why should our actions for .swf files be any different?

Comment 8

[Peter Lubczynski]

Because how can a .swf file ever be displayed as plain text and be useful? It's
just a binary mess. Besides, plugins were designed to be mapped to an extension
or mime type.

Also:
It doesn't look right
It's not what the user expects
It's not what our competition, IE, does.

Comment 9

[Matthias Versen [:Matti]]

>Also:
>It doesn't look right

Correct, also a HTML file serverd as text/plain or a non working CSS File
becuase of the wrong CSS mime-type looks not right.

>It's not what the user expects

I agree

>It's not what our competition, IE, does.

IE violates the HTTP standards with this and I help mozilla.org because i want a
better browser and not such piece of crap.
(i hate it also if i click on a file link [like .mp3] and I get a rendered
binary file instead of a download link but that is the fault of the web-master)
The Client must use the served mime-type or he violates the standards.
The Client can use Content-sniffing or use the file extension if the server
sends no mime-type (all http/0.9 servers).

Why are plugins special ?

Comment 10

[av (gone)]

1. Plugins are what makes surfing a joy
2. Most users don't care about following standards, they want to see an animation
3. The only thing they can say and the only thing they can base their judgement
on is: "browser A shows the clip, but browser B does not". 

Question: What is this user going to choose?

Comment 11

[Sören 'Chucker' Kuklau (gone)]

Re: Comment #10 From av 2002-06-07 12:46
> 1. Plugins are what makes surfing a joy

Possibly.

> 2. Most users don't care about following standards, they want to see an
> animation

Mozilla does care about standards, at least that's what we all have been
claiming since the project originally started. If users want to see the
animation, they should file Tech Evangelism bugs. That's how it always worked
and I don't see why we should make a difference for plug-ins.

> 3. The only thing they can say and the only thing they can base their judgement
> on is: "browser A shows the clip, but browser B does not". 

Yeah. Right. That's the problem with following standards, and not a problem
especially with plug-ins.

> Question: What is this user going to choose?

The dumb user is going to choose Browser A.

The clever user is going to complain at the webmaster.

Comment 12

[Kai Lahmann (is there, where MNG is)]

does this file come as text/plain or as the valid mimetype? If it's the first,
it has to be displayed as text/plain. Guess what would happen, if this .swf
would be a HTML-file and comes as text/html.....

And: could the Netscape-Prople in here remember, that non-Netscape people are
reading here?

Comment 13

[av (gone)]

>Mozilla does care about standards, at least that's what we all have been
>claiming since the project originally started.

That's exactly what I mean. Mozilla follows standards accurately. But not all
possible situations are standard. What to do in such a case depends on many
things,  and there will be as many opinions as there are people. And this is one
of them.

>Yeah. Right. That's the problem with following standards, and not a problem
>especially with plug-ins.

True. But plugins are very visible. They are pretty much everywhere nowadays.

Comment 14

[serge (gone)]

well, of course, we won't violate the standards just because IE does it,
beside there are a lot of different mapping between mime-type & file exension on
the modern web, e.g. audio/x-pn-realaudio-plugin ==> RealPlayer(tm) as Plug-in
(*.rpm) and linux red hat package manager *.rpm files, which we cannot serve to
the real plugin, but we do if server tells us a wrong mime-type, and there is a
bug on that.
I'm tying to say there is no simple solution for such kind of discrepancy,
and we probably won't be able to solve this w/o users interaction,
the same way we handle unknown mime-type,
just bring up the download dialog (actually same extension of that dialog, which
has to be implemented) and get users decide what to do.

Comment 15

[Sören 'Chucker' Kuklau (gone)]

Re: Comment #13 From av 2002-06-07 13:21
> Mozilla follows standards accurately. But not all possible situations are
> standard. What to do in such a case depends on many things, and there will be as
> many opinions as there are people. And this is one of them.

Okay.

> >Yeah. Right. That's the problem with following standards, and not a problem
> >especially with plug-ins.

> True. But plugins are very visible. They are pretty much everywhere nowadays.

Okay, but same goes for stylesheets. We don't tolerate CSS style sheets *not*
served as text/css in strict mode. Unluckily, we don't have any "mode"
distinguishing in this case as there is no XML or SGML to parse.

Proposed solution A)

Go by the mime type, e.g. we don't tolerate plug-ins served as the wrong mime
type in *any* case. That would be a nice solution in an ideal world, in which we
aren't living. Would cause a bunch of tech evangelism bugs. Who knows, maybe
this would be the cleverest solution.

Proposed solution B)

Let the user choose: "The document you're trying to view has the extension .SWF,
but is served as '[mime type]'.
(Play it as flash movie) (Open it with its mime type handler)"

This is a way too complicated and unrealistic solution.

Proposed solution C)

Sniff actual content type. Will be tough to do this for all supported plug-in
formats, though.

Proposed solution D)

Go by the file extension. I don't like this solution. Might as well be a
security risk.

Comment 16

[Kai Lahmann (is there, where MNG is)]

and A and C are only a bit realistic. A would mean to follow the spec and behave
as we do on HTML, and C is technically _very_ compilcated and also doesn't
always work.
We are all at the same oppinion, that is there's a usefull MimeType, we belive
it, and so only do this on text/plain and application/occet-stream?

Comment 17

[Sören 'Chucker' Kuklau (gone)]

Errata in Comment #15:

> Go by the mime type, e.g. we don't tolerate plug-ins served as the wrong mime

Should read

> Go by the mime type, e.g. we don't tolerate *plug-in content* served as the
wrong mime

Comment 18

[serge (gone)]

>Proposed solution B)
...
>This is a way too complicated and unrealistic solution.
it is not that complicated as solution C) and more realistic that C)
and from my point of view this issue should be addressed in the future plugin
manager implementation

Comment 19

[av (gone)]

Shrirang, can we move the test case elsewhere so people from outside could
access it too?

Comment 20

[Kai Lahmann (is there, where MNG is)]

hm.. B has one good point, it shows the users, that there's something wrong with
the server.

btw. 3 midairs - who had more? ;)

Comment 21

[Matthias Versen [:Matti]]

my 0.02Euro :-)

I like the way mozilla follows the standards.
Solution B) would be the best .
We are still following the standards and the user has no problems.

We should do this for a few mime-types (.mp3, .rar [.r01,.r02....}, .xls ) and
it should not limited to plugins.
Mozilla should only ask 1x for each server / browser session / file type

Comment 22

[av (gone)]

When the server is misconfigured and sends us the wrong mime type this is most
likely just because somebody did not care to set it, and the server goes with
the default one. If this assumption is correct, I think Kai's proposal makes
sense -- not to trust much to text/plain or application/octet-stream only and
override those too if necessary.

When we come close to implementing the plugin manager, there could be an option
like 'Let Mozilla decide how to resolve the conflict'.

Comment 23

[Kai Lahmann (is there, where MNG is)]

so here my plan:

text/plain
options:
-> show inline [default]
-> save
-> ask plugin/helper app by looking at the extension

on application/occet-stream the default would be save.

Comment 24

[Sören 'Chucker' Kuklau (gone)]

Re: Comment #23 From Kai Lahmann 2002-06-07 14:20
I'm fine with that one.

So I suppose the URL this bug refers to has "text/plain" and Kai's proposal
would solve that?

Comment 25

[Kai Lahmann (is there, where MNG is)]

external testcase now. This is NOT the default behavior of a debian apache.

Comment 26

[rubydoo123]

We just had this discussion in our quarterly W3C HTML WG face to face, the
decision that was reached by the HTML WG coincides with Sören's option B. If the
server and document do not agree on the mime-type, the UA should notify the user
as to the problem. The UA may offer the following:
1. allow the user to abort
2. offer the user to process the plug-in based on the mime-type offered by the
server, if the UA can satisfy that request
3. offer the user to process the plug-in based on the mime-type offered by the
author, if the UA can satisfy that request

Since this will require UI changes (the user dialog), this will have to be
pushed off till post RTM

Comment 27

[rubydoo123]

this one should have been nsbeta1- already

Comment 28

[rubydoo123]

Based on the recommendation from the W3C HTML WG I am attaching this to our
plug-in manager work and adding dependency to 44973 and 144263

Comment 29

[Glenn Widener]

Note: bug 158158 is NOT this bug!

This bug (after a careful reread through the noise), is a request for the
following feature:

If the server returns it's default mime type, try to infer what plugin to run
based on the suffix.  Most servers default the default MIME type to text/plain,
hence the request was to treat "text/plain" as "unknown"; similar action for
"application/octet-stream".  This default of text/plain is an unfortunate
de-facto standard, hence it's not unreasonable to give "text/plain" special
treatment.

However, doing so leads to improperly configure servers, resulting in erratic
behavior with different browsers and client configurations, thus in many ways is
a very bad idea.  The best scenario would be for all browsers to behave the
same, ideally fail immediately if the server administrator has failed to do his
job and configure the MIME type.  Keep in mind that the server developer has
total control of both mimes and suffixes, and it's his responsibility to get the
MIME type right.

I just checked, and Netscape ignores suffixes on http:, showing text/plain as
text, while IE as usual tries to be clever with text/plain and infer and run the
plugin (without user query) from the suffix.  Given the current state of the
world, duplicating IE's behavior is the better choice.  What I will strenuously
resist is any mis-construing of bug 149705 as a request for special treatment
for certain suffixes, or any MIME type other than "text/plain" or
"application/octet-stream" - that way is chaos (also known as Internet
Explorer!)

Comment 30

[rubydoo123]

peter : plug-in branch work

Comment 31

[Matthias Versen [:Matti]]

We detect now apache misconfigurations and use application/octet-stream.
Everything else should be wontfix, marking as such