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.
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.
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.
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.
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
this one should have been nsbeta1- already
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
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!)
peter : plug-in branch work
We detect now apache misconfigurations and use application/octet-stream. Everything else should be wontfix, marking as such