95549 - OBJECT tag: Content-type header should take precedence

Status: RESOLVED FIXED

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

Description

[Peter Lubczynski]

This is from bug 678 which implemented document viewing with the OBJECT tag.
[e-mail] 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.

Comment 1

[Braden]

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

Comment 2

[Peter Lubczynski]

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

[P. Damian Cugley]

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?

Comment 4

[Braden]

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

[scottputterman]

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 [e-mail].  You can search for
"Moving bugs not scheduled for a project" to quickly delete this bugmail.

Comment 6

[Denis Antrushin]

removing myself from cc:

Comment 7

[rubydoo123]

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

Comment 8

[rubydoo123]

based on the determination of the W3C HTML WG, marking this as wontfix

Comment 9

[Braden]

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

[Christopher Hoess (gone)]

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

[Andrew Hagen]

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

[Braden]

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

[Christopher Hoess (gone)]

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

[Braden]

Reopening (for lack of a good reason for this to remain closed).

Comment 15

[Peter Lubczynski]

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.

Comment 16

[Braden]

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

[Braden]

Er, make that , "Mozilla should *not* be loading a plug-in until it knows the
type of the data."

Comment 18

[av (gone)]

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

[Braden]

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

[av (gone)]

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

[Braden]

I thought the whole "bugwards compatible" versus "follow the specs" issue was
resolved for Mozilla some time ago.

Comment 22

[Peter Lubczynski]

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.

Comment 23

[Braden]

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.

Comment 24

[rubydoo123]

putting this one to PL2:NA and off to future until a much later date

Comment 25

[Jonadab the Unsightly One (Nathan Eady)]

> 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

[Boris Zbarsky [:bzbarsky]]

> 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

[Hixie (not reading bugmail)]

(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

[Christopher Hoess (gone)]

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

[Jonadab the Unsightly One (Nathan Eady)]

> 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

[Braden]

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

[rubydoo123]

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

[Braden]

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.

Comment 33

[Peter Lubczynski]

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

[rubydoo123]

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

[Braden]

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

[rubydoo123]

no, I'm not mistaken at all, no need to reread anything

Comment 37

[Braden]

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

[Boris Zbarsky [:bzbarsky]]

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

[Braden]

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

[Boris Zbarsky [:bzbarsky]]

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

[Christopher Hoess (gone)]

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

[Braden]

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

[Boris Zbarsky [:bzbarsky]]

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

[rubydoo123]

interesting, I'm the one writing the spec - so, no I am not mistaken or
misinterpreting the spec at all

Comment 45

[Braden]

Boris, Peter, Christopher: Alright. Fixing this with the quirks mode exception
and the warning message sounds like the best thing to do.

Comment 46

[Braden]

beppe: The "am not" "are too" exchange is not constructive. Provide concrete
citations to back up your assertions.

Comment 47

[Hixie (not reading bugmail)]

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

[Jonadab the Unsightly One (Nathan Eady)]

> 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

[Braden]

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.

Comment 50

[Braden]

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

[Phil Endecott]

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

[Christian :Biesinger (don't email me, ping me on IRC)]

fixed by bug 1156.