Closed Bug 149705 Opened 22 years ago Closed 15 years ago

full page plugins don't work by file extension

Categories

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

Product:
Core Graveyard
Component:
Plug-ins
Platform:
x86
Windows NT
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX
Milestone:
mozilla1.4beta

People

(Reporter: shrir, Assigned: peterl-bugs)

References

(
URL
)

Details

(Whiteboard: [Plug-in Mgr][PL:BRANCH]) 

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.
Keywords: nsbeta1
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 :-) )
eeks..let me check then :)
Plugins are special, they need to given a chance to override.
Whiteboard: [PL RTM]
matti, here's a test url from a site.  

http://multimedia.ogrish.com/download.php?filename=danielpearl.asf
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.
uh ok
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?
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.

>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 ?

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?
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.
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?
>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.
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.

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.
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?
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
>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


Shrirang, can we move the test case elsewhere so people from outside could
access it too?
hm.. B has one good point, it shows the users, that there's something wrong with
the server.

btw. 3 midairs - who had more? ;)
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
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'.
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.
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?
external testcase now. This is NOT the default behavior of a debian apache.
URL: http://slip/shrir/Dice.swf → http://linuxfaqs.de/Dice.swf
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
Assignee: beppe → av
Priority: -- → P2
Whiteboard: [PL RTM]
Target Milestone: --- → mozilla1.1alpha
this one should have been nsbeta1- already
Keywords: nsbeta1 → nsbeta1-
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
Depends on: 44973, 144263
Whiteboard: [Plug-in Mgr][PL2:P3]
Target Milestone: mozilla1.1alpha → mozilla1.2alpha
Priority: P2 → P3
Target Milestone: mozilla1.2alpha → mozilla1.2beta
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!)
Target Milestone: mozilla1.2beta → mozilla1.3alpha
peter : plug-in branch work
Assignee: av → peterl
Whiteboard: [Plug-in Mgr][PL2:P3] → [Plug-in Mgr][PL:BRANCH]
Target Milestone: mozilla1.3alpha → mozilla1.4beta
We detect now apache misconfigurations and use application/octet-stream.
Everything else should be wontfix, marking as such
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → WONTFIX
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.