Closed
Bug 95549
Opened 23 years ago
Closed 19 years ago
OBJECT tag: Content-type header should take precedence
Categories
(Core Graveyard :: Plug-ins, defect, P5)
Core Graveyard
Plug-ins
Tracking
(Not tracked)
RESOLVED
FIXED
Future
People
(Reporter: peterlubczynski-bugs, Assigned: jst)
References
Details
(Keywords: html4, topembed-, Whiteboard: [PL2:NA][Object] [Hixie-P2])
This is from bug 678 which implemented document viewing with the OBJECT tag. braden@endoframe.com raises the point that we strictly use the TYPE= attribute to determine the type of plugin but we should first consider the content-type in the header of the stream: The TYPE attribute on OBJECT is *just a hint* the the browser can use to determine whether or not it should try to download the data. It is not a required attribute. And if the media type sent by the server happens to differ from that in the TYPE attribute, the client *must* honor the type sent by the server. It sounds like Mozilla may need substantial fixing in this regard. Perhaps the fix could be integrated with bug 95548 OBJECT tag's type can't be changed later.
Also importantly, this is an HTTP conformance issue. From RFC 2616 (HTTP/1.1): 7.2.1 Type When an entity-body is included with a message, the data type of that body is determined via the header fields Content-Type and Content- Encoding. These define a two-layer, ordered encoding model: entity-body := Content-Encoding( Content-Type( data ) ) Content-Type specifies the media type of the underlying data. Content-Encoding may be used to indicate any additional content codings applied to the data, usually for the purpose of data compression, that are a property of the requested resource. There is no default encoding. Any HTTP/1.1 message containing an entity-body SHOULD include a Content-Type header field defining the media type of that body. If and only if the media type is not given by a Content-Type field, the recipient MAY attempt to guess the media type via inspection of its content and/or the name extension(s) of the URI used to identify the resource. If the media type remains unknown, the recipient SHOULD treat it as type "application/octet-stream".
Keywords: mozilla1.0
Reporter | ||
Updated•23 years ago
|
Status: NEW → ASSIGNED
Priority: -- → P3
Target Milestone: --- → mozilla1.0
Reporter | ||
Comment 2•23 years ago
|
||
Note: this works properly if it's a real plugin, just not for sub-documents and images. For example, see the videos at abcnews.com
Comment 3•23 years ago
|
||
The correct behaviour is inconvenient when one does not have control over the mime-types database of one's web server. For example, consider the URL http://www.alleged.demon.co.uk/pdc/xmas2001/ This includes an SVG image using an 'object' element with 'type="image/svg+xml"'. Mozilla+SVG knows how to display SVG files, so it tries to download it. The web server serves the SVG content as 'text/plain', because it does not know about '.svg' files. Mozilla+SVG now ignores the 'type' attribute, and displays the SVG source code as text. Mozilla knows how to display plain text, so there is no need for it to try the fall-back image represented by the content of the 'object' element. This is, I believe, the 'correct' behaviour. Microsoft Internet Explorer sees the 'type' attribute, looks it up in its list of plug-ins, and selects the SVG plug in (since I happen to have that installed). It passes the data from my SVG file to the plug-in, which displays the pretty picture. In other words, MSIE 'erroneously' displays the SVG file -- as I intended. The upshot of which is that if SVG counts as a subdocument or image then maybe this bug is now fixed?
This bug is *not* fixed. You need to get your server fixed. It is in fact an error that Mozilla is displaying the SVG on that page. It should not. Note that Mozilla does the Right Thing if you just enter the URL of the SVG image in the location bar. As stated in the original description of this bug, the TYPE attribute of OBJECT is just a hint that the browser can use when deciding if it wants to download the data. The TYPE attribute is optional, and the graphic should display just the same if you omit it.
Comment 5•23 years ago
|
||
Moving Netscape owned 0.9.9 and 1.0 bugs that don't have an nsbeta1, nsbeta1+, topembed, topembed+, Mozilla0.9.9+ or Mozilla1.0+ keyword. Please send any questions or feedback about this to adt@netscape.com. You can search for "Moving bugs not scheduled for a project" to quickly delete this bugmail.
Target Milestone: mozilla1.0 → mozilla1.2
Comment 6•22 years ago
|
||
removing myself from cc:
Updated•22 years ago
|
Whiteboard: [Object]
Updated•22 years ago
|
Whiteboard: [Object] → [Object] [Hixie-P2]
Comment 7•22 years ago
|
||
In the W3C face to face that took place on 3-4 June 2002, the following was determined to be the appropriate method to follow: If type attribute is present: If user agent does not support type specified by 'type' attribute get the data If user agent does not support actual type declared by server else process the data else 'type' attribute is not present so get the data If user agent does not support actual type declared by server else process the data
Whiteboard: [Object] [Hixie-P2] → [PL2:P3][Object] [Hixie-P2]
Comment 8•22 years ago
|
||
based on the determination of the W3C HTML WG, marking this as wontfix
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → WONTFIX
Whiteboard: [PL2:P3][Object] [Hixie-P2] → [Object] [Hixie-P2]
beppe: This is not an HTML issue, it is an HTTP issue. HTTP 1.1 conformance is impossible unless this bug is fixed. Put bluntly, since this is an HTTP issue, it seems to me that the HTML WG is not the authority here. This bug is contributing to lots of sites naively reporting bogus content types. It needs to be fixed and it should be reopened.
Comment 10•22 years ago
|
||
Braden: I think this behavior is in compliance with HTTP 1.1, as long as we render the <object> in a manner consistent with the server-provided content-type. Consider the following example: an <object> is preferred to be SVG, and given type="image/svg+xml". Someone browses the page with a normal Mozilla build, which doesn't recognize that MIME-type. We get the <object> anyway, and conneg on the server side sends us an image/png instead. Mozilla passes it to the png decoder, and we display the png. Same deal with Damian's example (except that this isn't the behavior he had intended): a text/plain <object> is quite valid, and Mozilla can display it, so it does so when it gets the MIME-type. If you still feel it violates HTTP 1.1, could you be more explicit as to why?
Comment 11•22 years ago
|
||
What part of the HTTP standard does it break? If this is an HTTP bug, shouldn't the component be networking, not plug-ins?
Comment 12•22 years ago
|
||
Andrew: It's right there in comment #1. It's "Plug-ins" because, as I understand it, the problem is in the plug-in handling code. Christopher: If browsing with a Mozilla build that supports SVG, and an object with TYPE="image/svg+xml" is encountered, but the server sends "text/plain", Mozilla will not render "text/plain". This is broken. Per HTTP, the type sent by the server must be honored. If this bug is WONTFIX, bug 65092 needs to be WONTFIX as well. Of course, I think that's nuts.
Comment 13•22 years ago
|
||
I misunderstood Damian's comment; my own testing shows that the content of the <object> is displayed rather than the text/plain data. This is not as bad as if the <object> data were handled with the wrong content-type, but I agree it should show the data rather than the content. Given the possible cases, these are the outcomes that I believe to be correct, where types a/a and b/b are understood by mozilla, and c/c is not: 1) type attribute "a/a", MIME-type "a/a": data displayed as a/a. 2) type attribute "a/a", MIME-type "b/b": data displayed as b/b. 3) type attribute "a/a", no MIME-type: data displayed as a/a. 4) type attribute "c/c", MIME-type "a/a": data displayed as a/a. 5) type attribute "c/c", no MIME-type: content displayed. 6) type attribute "a/a", MIME-type "c/c": content displayed. 7) no type attribute, MIME-type "a/a": data displayed as a/a. 8) no type attribute, MIME-type "c/c": content displayed. The disagreement here centers around case 4, where we display the content rather than the data. Are any of the examples I have outlined in conflict with the HTML WG's findings, and if so, why?
Comment 14•22 years ago
|
||
Reopening (for lack of a good reason for this to remain closed).
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Reporter | ||
Comment 15•22 years ago
|
||
This bug is a non-issue because we already do the "right thing" by using the TYPE attribute as just a "hint". The HTTP header is already used by the various components to determine how to display the data. There are 3 catagories of media that can be displayed by the OBJECT tag. In each one, we allow the HTTP header to take precedence: PLUGINS: Plugins have 2 calls in which a mime-type is sent. First, |NPP_New| is called to start the plugin instance. The mime-type passed in here is the one in the TYPE attribute to be compatibile with 4.x-style plugins. The second time we pass a mime-type to the plugin is when DATA is going to be passed to the plugin. |NPP_NewStream| is called with the mime-type from the HTTP header and it's up to every plugin to honor the spec. IMAGES: If we see a TYPE attribute with a mime-type that our image library says it can handle, we do not look for any plugins but mearly transfer control over to the image frame code. Plugin code doesn't do anything with this nor even looks at the stream as this would cause us to open it twice. However, image code should use the content-type header like it does for other tags. DOCUMENTS: Similar to images, the TYPE attribute is examined to see if we have any viewers capable rendering this document. If we do, control is transfered to the IFRAME code which I also gives precedence to the content-type header. So, I think we are following the spec by only using the TYPE attribute as a "hint" to decide which type of rendering above is desired by the author then allowing the HTTP header to take precedence.
Status: REOPENED → RESOLVED
Closed: 22 years ago → 22 years ago
Resolution: --- → WONTFIX
Comment 16•22 years ago
|
||
Peter: How does a plug-in hand the data back to the browser (to retry with another plug-in) in the event that it receives data that it cannot render? The strategy you describe seems to be breaking down for Christopher's Case 4. Mozilla should be loading a plug-in until it knows the type of the data. And Mozilla is definitely *not* following the HTML (4.01) spec here. 13.3 states, in the description of the TYPE attribute: If the value of this attribute differs from the HTTP Content-Type returned by the server when the object is retrieved, the HTTP Content-Type takes precedence. By loading the plug-in based on the value of TYPE rather than the Content-Type returned from the server, Mozilla is not allowing the Content-Type from the server to take precedence. As a result, Mozilla is not guaranteed to do the Right Thing with the data. Furthermore, I do not see that fixing this would impinge upon the 4.x plugin API in any way. NP_New is spec'd to supply the tag attribute-value pairs, and that's just fine.
Comment 17•22 years ago
|
||
Er, make that , "Mozilla should *not* be loading a plug-in until it knows the type of the data."
Comment 18•22 years ago
|
||
Looks like to comply with the spec we should ignore the initial call with mime type specified by the TYPE attribute but rather wait for the stream to start. As Peter said we already have this mechanism in place, and can try not to attempt to determine mime type as we currently do: from the TYPE attribute or the source file extension. Will we break a lot of pages by doing that? I anticipate that many servers are misconfigured. Another thing, what if there is no SRC attribute in the OBJECT tag and there is not going to be a data stream? We should probably detect this situation somehow and still use the TYPE attribute.
Comment 19•22 years ago
|
||
av: As per HTTP/1.1, it's fine to use the TYPE attribute, filename extension, or whatever, to infer the content type *if and only if* the server has not sent a Content-Type. Browser bugs like this one are *why* many servers are misconfigured. Mozilla should follow the specs; server configurations will get fixed as the problem gets noticed. As for OBJECT instances without a DATA attribute, we should focus on the use of the CLASSID attribute to instantiate the plug-in. But I think it should be fine to use the TYPE attribute for this in case there is no CLASSID attribute either.
Comment 20•22 years ago
|
||
I am not arguing (and in fact agree) but again, this is not only the engineering
issue. Fixing this may have a negative effect on Mozilla browsers market share
because:
> Mozilla should follow the specs; server configurations will get fixed as the
> problem gets noticed.
...or will not, if there is another browser to choose which does the 'wrong' thing.
Comment 21•22 years ago
|
||
I thought the whole "bugwards compatible" versus "follow the specs" issue was resolved for Mozilla some time ago.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Reporter | ||
Comment 22•22 years ago
|
||
Not for plugins! Because we are stuck using mostly the same API and relic plugins from 4.x, we're stuck with all their quirks and bugs. Compatibility with plugins is more difficult than layout because getting plugin vendors to change their plugins and mass-distribute them is nearly impossible. Since we are trying to make as many plugins work as close to the way they used to in 4.x, incorrectly interpreting the spec would make it even harder to make plugins look right in Mozilla. It's also hard to justify to AOL that such a change needs to be made when IE is able to render it fine. Now I think this bug is actually WFM because we *ARE* correctly following the HTTP spec in allowing the content-type header to take precedence when the TYPE attribute differs in each rendering mode below: DOCUMENTS: <OBJECT type="text/plain" data="http://www.mozilla.org/index.html"> Despite the fact the type attribute is asking to display the document as plain text, we allow the content-type header to take precendence and instead render this tag in text/html. We follow the HTTP spec and the author has no option to display the document as plain text. IMAGES: <OBJECT type="image/jpeg" data="http://mozilla.org/images/mozilla-banner.gif"> Same story here. Even though the TYPE attribute says to render as JPEG, we render as GIF. PLUGINS: <OBJECT type="audio/wav" data="http://www.digitallyimported.com/mp3/eurodance128k.pls"> Even with plugins, the HTTP header take precendence! In the above example, the server hands back a mime of 'audio/x-scpls' and the plugin is able to interpret the data and then play the resulting MP3 streams depsite being ask to play it as a wav. The plugin doesn't care that it was giving a hint to try 'audio/wav' as it follows HTTP spec and renders according to what the server hands back. It's up to each plugin to obey the spec, the browser just passes the information along. If there are individual plugins that don't follow the spec, open evangelism bugs with good detailed testcases. The examples above show that we correctly render "case #4" in comment #13. The TYPE attribute is mearly used as a *HINT* to determine which type of rendering the entire tag will fall into, reguardless if we are going to feed any data to the plugin. When data actually needs to be fed to the plugin, the content-type header takes precedence. > Browser bugs like this one are *why* many servers are misconfigured. That may be somewhat true, but I think many servers are misconfigured because they are *OLD* and full of bugs. There are many servers out there that incorrectly send text/plain for Flash and that's the #1 plugin out there! Imagine if I was a new plugin developer. It would be very difficult for my plugin to gain popularity if I had to employee an army of evangelist to change every misconfigued web server to recognize my new file type. The 4.x API does allow a plugin to cancel its intial stream. Since it's legit to do this and Acrobat even does it when going into byte range mode, the browser can't use this to detect failure to render from HTTP header. Perhaps a new RFE bug should be opened to add the ability to the API for a plugin to ask the browser to try alternate rendering instead. Perhaps we should also have a better way to select plugins, like IE does, except that we're stuck with the fact 4.x only used mime-types and file extension, but that's another bug.
Status: REOPENED → RESOLVED
Closed: 22 years ago → 22 years ago
Priority: P3 → P5
Resolution: --- → WORKSFORME
Target Milestone: mozilla1.2alpha → Future
Comment 23•22 years ago
|
||
Peter: I suspect what you're seeing are side effects of particular content types with particular plug-ins. This is not fixed, as I have just confirmed by testing P. Damian Cugley's example. (The OBJECT element in the page should show the SVG source text, not the SVG graphic.) Or are you seriously suggesting that it is the SVG plug-in's responsibility to display text/plain and not Mozilla's? > Not for plugins! When was this decided, and by whom? > It's also hard to justify to AOL that such a change needs to > be made when IE is able to render it fine. I don't care about that, and I don't believe it's at all material. I care about making a case to mozilla.org. Fact is, because the server's sending the wrong type, someone would not be able to link to the resource and have it render full-screen. That is damage to the Web that this bug passively promotes. Simply: if Mozilla were following the HTTP and HTML specs here, it would not load the plug-in until it knew the data type. If the TYPE attribute is really treated as "just a hint", there is no basis for loading a plug-in based on its value.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Comment 24•22 years ago
|
||
putting this one to PL2:NA and off to future until a much later date
Assignee: peterlubczynski → beppe
Status: REOPENED → NEW
Whiteboard: [Object] [Hixie-P2] → [PL2:NA][Object] [Hixie-P2]
Comment 25•22 years ago
|
||
> You need to get your server fixed. This is so far from realistic it is beyond absurd. Most of the web consists of users who have an _account_ on a server, not an entire server. These users don't (and shouldn't) have control over the server configuration and cannot change what content-type the server sends in all cases. (Some ISPs allow .htaccess, but not most, because it is off by default; further, some servers don't even run Apache.) It is *absurd* to expect every ISP to add mime types to the server for every type of file any of the users who have accounts there might want to put on their websites. For many ISPs, that would make someone a full-time job. (New file formats pop up on the web constantly. Most of them never amount to anything.) And I'm not just talking about home users with www.isp.net/~username/ sites, either. Many small domains operated by small organisations and businesses don't have their own server. Regarding HTTP conformance: http is a protocol for the _transfer_ of data (hence the name). It doesn't (or shouldn't) have jack diddly to do with how the content is _displayed_. That's determined by other standards such as HTML and XML and CSS and PNG and so on and so forth. HTTP is about getting the file from the server to the client. I'm strongly against the MSIE behavior of making guesses from the file extension, but a content-type that has been specified by the page author is a different matter entirely, for two reasons. First, the page author is more likely than the website administrator to know the correct content type for the file. Second, if the content-type specified in the tag is as you keep saying only a hint and not to be followed, you need to explain what the legitimate application would be for giving a hint that is not accurate; otherwise that argument is spurious, and we have to conclude that the author _intended_ an accurate content-type. > Browser bugs like this one are *why* many servers are misconfigured. Some servers, perhaps, but in most cases the server administrator sets up the server and then never touches the MIME type database again because the main website (which is generally a content-free advertisement for the ISP or else a news "portal") only uses the basic content types (usually, a blend of HTML 3.x and HTML 4.x with no doctype, GIF, and JPEG). However, the users who have accounts on the server, who have little influence on how the server is administered, often wish to serve content of other types. If I write a game in Inform, should I petition my ISP's web server admin to add the application/X-glulx content-type to the MIME types database? How far do you think I would get? > Mozilla should follow the specs; This I agree with, but I fail to see how HTTP should be more important than HTML or XML when it comes to rendering content. HTTP surely should take precedence over HTML and XML in Necko, but in Gecko the content rendering standards are more relevant, when push comes to shove. If W3C says follow the content-type given in the tag, that's what should be done. Now, when you follow a link, then html/xml does not say what to do with the file at the other end of the link, and you fall back on the http content-type. But an embedded object that's part of a page is another matter; the standard governing the rendering of the page is clearly relevant in that case. > server configurations will get fixed as the problem gets noticed. I've been reading that statement since 1995. I'm still waiting. It seems to me that you want to push the web toward a situation where only people who administer their own servers (large corporations and IT professionals, for the most part) are free to server various kinds of content. Not that I don't wish more people would use fewer plugins, but that's really an entirely separate question.
Comment 26•22 years ago
|
||
> I fail to see how HTTP should be more important than HTML or XML when it comes > to rendering content You raise a good point. The reason it's more important is because the HTML spec says so explicitly. From http://www.w3.org/TR/html401/struct/objects.html#edef-OBJECT: type = content-type [CI] This attribute specifies the content type for the data specified by data. This attribute is optional but recommended when data is specified since it allows the user agent to avoid loading information for unsupported content types. If the value of this attribute differs from the HTTP Content-Type returned by the server when the object is retrieved, the HTTP Content-Type takes precedence. Note the last sentence. Now it could be argued that this is a mistake on the part of the HTML spec. Please take that up with the W3C.
Comment 27•22 years ago
|
||
(Note that this is by design. The Web page can't know for sure what the remote content's type actually is; only the server knows that for sure.)
Comment 28•22 years ago
|
||
Jonadab: it's not true that you must be a server administrator to change MIME-type mappings for your own files (although some servers may be set up that way). I've just filed bug 183340 suggesting that we help people out by providing templates so that they can set up the proper MIME-types for their own files, at least.
Comment 29•22 years ago
|
||
> Jonadab: it's not true that you must be a server administrator to change > MIME-type mappings for your own files In theory it's not true. However... > (although some servers may be set up that way) "some" is a conservative figure. However, given comment 26, I think I agree that this needs to be addressed at the W3C -- assuming that is still the W3C's position. I was unsure of this for a couple of reasons. First, comment 7 was confusing, then comment 8 seemed to indicate a determination had been made to go the other way. I haven't managed to locate anything to that effect in the XHTML recommendations, however.
Comment 30•22 years ago
|
||
Jonadab: The excerpt from HTML 4.01 that Boris quoted for you is really just window dressing. The important part is in the HTML 4.01's listing of normative references, which includes RFC 2616, the HTTP/1.1 specification. Boris is mistaken when he says that it can be argued that there is an error in the HTML spec. It can't. Per HTTP/1.1, the content type sent by the server is *always* correct--by definition--as far as the client is concerned. Thus not only would it be nonsensical for an [X]HTML spec to include contradictory prose, it would be a spec error for it to do so while continuing to normatively reference HTTP/1.1.
Comment 31•22 years ago
|
||
Arguing which spec has pecedence is all fine and dandy, but the bottom line is user experience and user expectation. A user does not expect to have an invalid statement to come back at them because a server was misconfigured. If the browser has the resources to resolve the plug-in needed to display/process the object, then that is what must be done. If that is against the HTTP spec that is unfortunate, however, in this case it is more appropriate to follow the HTML/XHTML specs. It is inappropriate at best to fault a user because a server is misconfigured or because a server returns an inaccurate mimetype. Normative text within the HTML spec states that we must attempt to resolve the object, if part of that is stepping over the HTTP spec statement, then so be it.
Comment 32•22 years ago
|
||
beppe: Arguing which spec has pecedence is all fine and dandy, but the bottom line is user experience and user expectation. A user does not expect to have an invalid statement to come back at them because a server was misconfigured. What are suggesting a user *does* expect to happen when a server is misconfigured? This is nonsense, of course, because *users don't expect servers to be misconfigured*. And importantly, *neither do HTTP clients*. HTTP functions on the premise that the information received from the server is accurate. There is no facility for second guessing the server. Misapplying an HTML construct to second-guess the server breaks HTTP and it breaks HTML. If the browser has the resources to resolve the plug-in needed to display/process the object, then that is what must be done. That's exactly why this bug is open. Mozilla is *failing* for the example that Damian Cugley posted in comment #3. If that is against the HTTP spec that is unfortunate, however, in this case it is more appropriate to follow the HTML/XHTML specs. It is inappropriate at best to fault a user because a server is misconfigured or because a server returns an inaccurate mimetype. Normative text within the HTML spec states that we must attempt to resolve the object, if part of that is stepping over the HTTP spec statement, then so be it. What are you talking about? The HTTP and HTML specs are not at all contradictory on this point.
Reporter | ||
Comment 33•22 years ago
|
||
So it seems to me like this bug is another case of where good user experience (comment #3) would be hurt by following some standards to the tee. I think Mozilla already has a mechanism for solving such problems: quriks compatibility mode. Possible idea: since most pages on the web are rendered in quirks mode anyway, only allowing the content-type header to take precedence in standards mode should keep the web rendering correctly while keeping standards buffs happy. Thoughts?
Comment 34•22 years ago
|
||
pardon me Braden? You're the one who has been pissing and moaning in this bug about how the HTML spec is diffetent than the HTTP spec -- so what on earth are you talking about?
Comment 35•22 years ago
|
||
beppe: You're quite mistaken. I suggest you reread the comments. Peter: I don't think that is the most desirable solution (surprise); but it would definitely be an improvement over the current situation. Is there any precedent for using quirks mode for this kind of thing?
Comment 36•22 years ago
|
||
no, I'm not mistaken at all, no need to reread anything
Comment 37•22 years ago
|
||
beppe: If you don't care to go back and find your mistake, I'll lay it out for you: you're completely wrong in your assertion that I've been complaining that "the HTML spec is diffetent than the HTTP spec" (sic). I have *never* claimed or otherwise suggested that HTTP/1.1 and HTML 4.01 have incompatible requirements. Please familiarize yourself with the HTML spec prose to avoid further muddying this discussion with your perceptions of what it says that are apparently based on your misinterpretation of what I've said in this bug report.
Comment 38•22 years ago
|
||
Braden, our treatment of non-text/css stylesheets is sort of precedent, I guess. Also, you may want to note that beppe is on the HTML WG (see http://www.w3.org/TR/xhtml1/#acks, http://www.w3.org/TR/xhtml11/acknowledgements.html#a_acks; "Beth Epperson, Netscape/AOL") thus presumably familiar with the HTML spec prose...
Comment 39•22 years ago
|
||
Boris: So non-text/css stylesheet handling is broken, too? Re. beppe, I'm quite aware of that. Her recent comments here are nonetheless misguided and mistaken.
Comment 40•22 years ago
|
||
Braden: "broken" in that in quirks we accept them, yes (otherwise we would fail to render a _huge_ percentage of sites out there. Something like 50% of the top100 when I checked a few months ago).
Comment 41•22 years ago
|
||
Some points: 1. HTTP 1.1 and HTML 4.01 are in no way in conflict; both agree that the HTTP-delivered Content-Type takes precedence over the "type" attribute or any form of guessing in the interpretation of <object> data. Beppe, I can only conclude that you're misreading the HTML spec from your comment #31, which implies that the HTML/XHTML spec allows us to override the HTTP Content-Type if that is necessary to "resolve the plug-in" needed to display the object. Such is not the case. 2. Since many types of <object> content have not been assigned MIME-types or are in the vendor tree, hence not likely to be served with the correct MIME-type, we should proceed with some care in fixing this bug. My suggestions: begin by improving our evangelism resources for MIME-type problems, by fixing bug 183340, for instance. In addition, do as CSS does and start dumping warnings to the JS console when the Content-Type of the file doesn't match whatever value was used to instantiate the plugin. This will give us a better idea of the scope of the problem. Then we can try doing what we do for stylesheets, namely, holding fast to the Content-Type when in standards mode. From what I've heard, a relatively small proportion of pages trigger standards mode, and those that do are probably not multimedia-rich, so I would guess that we can make this change without an impossible amount of evangelism.
Comment 42•22 years ago
|
||
Boris: Ah, gotcha. (Sorry, I wasn't connecting the dots with my query about a precedent for Peter's suggestion.) Yes, that sounds like it's in very much the same spirit. Is this how it works? if (LINK TYPE="text/css" or no TYPE attribute) { fetch if (quirks mode) { render } else if (Content-Type: text/css) { render } }
Comment 43•22 years ago
|
||
Yep, that's pretty much exactly how it works, with an error logged to the JS console in the non-render case and a warning logged in the render-but-not-text/css case.
Comment 44•22 years ago
|
||
interesting, I'm the one writing the spec - so, no I am not mistaken or misinterpreting the spec at all
Comment 45•22 years ago
|
||
Boris, Peter, Christopher: Alright. Fixing this with the quirks mode exception and the warning message sounds like the best thing to do.
Comment 46•22 years ago
|
||
beppe: The "am not" "are too" exchange is not constructive. Provide concrete citations to back up your assertions.
Comment 47•22 years ago
|
||
The HTML specification is irrelevant here; HTTP has precedence when it is the underlying transport protocol. In any case, the HTML 4.01 specification explicitly states that the "type" attribute is merely advisory: # type # [..] If the value of this attribute differs from the HTTP Content-Type # returned by the server when the object is retrieved, the HTTP Content-Type # takes precedence. -- http://www.w3.org/TR/html401/struct/objects.html#adef-type-OBJECT XHTML 1.0 and XHTML 1.1 explicitly reference HTML 4.01 for their normative semantic definitions. As bz and choess have said, what we should do here is exactly the same mechansim as we should do for stylesheet imports, and is the same mechanism that we should use for <img> and <script> elements, namely, do the right thing in standards mode, and the compatible thing in quirks mode.
Comment 48•22 years ago
|
||
> beppe: This is not an HTML issue, it is an HTTP issue. HTTP 1.1 conformance > is impossible unless this bug is fixed. Put bluntly, since this is an HTTP > issue, it seems to me that the HTML WG is not the authority here. [...] > beppe: If you don't care to go back and find your mistake, I'll lay it > out for you: you're completely wrong in your assertion that I've been > complaining that "the HTML spec is diffetent than the HTTP spec" Read that first one twice slowly, and you'll see how we misunderstood what you meant. Regarding fixing this in standards mode, I have no objection, because: 1. I doubt very many pages that render in full standards mode would break if this were fixed. Authors who use those doctypes tend to know what fire they are playing with, or should. 2. It would be *useful* to be anal about this in full standards mode, because web authors who like to adhere to specs use full standards mode (among other things) for testing. I do that myself. I still don't think it's worth breaking existing quirks-mode pages on this issue unless someone can explain a legitimate useful reason (other than testing browser spec adherence) that a content author might deliberately lie about the content-type in the HTML "hint" but give the correct type in the http header. As far as precedent for playing loose with specs in quirks mode, see the entire list of differences between quirks mode and full standards mode. I also still think that if a future W3C spec-to-be reverses itself on the issue of which takes precendence, Mozilla should follow that. There is also the can of worms that is almost-standards mode... somebody had to mention it.
Comment 49•22 years ago
|
||
jonadab: I've read and reread it repeatedly. The only way you'll find inconsistency between those statements is by imagining words that aren't there. In comment #47, Hixie said much the same thing as I did.
Updated•20 years ago
|
Assignee: rubydoo123 → peterlubczynski-bugs
Comment 50•20 years ago
|
||
http://www.microsoft.com/technet/prodtechnol/winxppro/maintain/sp2brows.mspx#XS LTsection133121120120 In light of this, it is questionable whether Mozilla *ever* really needs to (or even should) allow the media type declared in the page to override the one sent by the server.
Comment 51•20 years ago
|
||
Re comment 13's case 7: > 7) no type attribute, MIME-type "a/a": data displayed as a/a. I'm trying to write <object data="foo">No</object> and have the server send PNG or something else based on the Accept: header. ("something else" is in principle SVG, but in practice it's only ever PNG at the moment; see also bug 240493.) Apache sends a PNG file with the correct content-type: header, but nothing is displayed, not even the alt-text. But it seems that if I write data="foo.png" it does work, so presumably Mozilla is matching the filename extension. It also works if I write <img src="foo">. Unlike some of the other cases discussed in this bug I don't think there's anyting controversial here; there is no conflicting type information to resolve and no plugins involved. Can this be made to work? This could become important once the long-awaited take off of SVG finally happens... --Phil. p.s. this is with Firefox 0.8; appologies if something has changed recently.
Comment 52•19 years ago
|
||
fixed by bug 1156.
Status: NEW → RESOLVED
Closed: 22 years ago → 19 years ago
Resolution: --- → FIXED
Updated•2 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•