This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 8479 - http content-type override mandatory for <object>
Summary: http content-type override mandatory for <object>
Status: RESOLVED FIXED
Alias: None
Product: HTML WG
Classification: Unclassified
Component: pre-LC1 HTML5 spec (editor: Ian Hickson) (show other bugs)
Version: unspecified
Hardware: PC Windows NT
: P3 normal
Target Milestone: ---
Assignee: Ian 'Hixie' Hickson
QA Contact: HTML WG Bugzilla archive list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-12-11 16:04 UTC by Julian Reschke
Modified: 2010-10-04 13:57 UTC (History)
5 users (show)

See Also:


Attachments

Description Julian Reschke 2009-12-11 16:04:25 UTC
It appears that the current definition of <object> has several cases where @type (or a type derived from the 'extension' of the URI) would override the server-supplied media type.

Consistent with other parts of the spec, this behavior should be optional (== a UA should be allowed to consider the HTTP content type as authoritative).

See related discussion, plus pointers to the Mozilla bug database, in http://lists.w3.org/Archives/Public/public-html/2009Dec/0260.html.
Comment 1 Adam Barth 2009-12-13 02:56:04 UTC
What's the point of being vague here?  The browsers all use the @type media type, and there are scads of web sites that rely on this behavior.  In the email you cite, Jonas says that he wishes it weren't the case but he's not willing to implement the alternate behavior.
Comment 2 Julian Reschke 2009-12-13 09:00:15 UTC
(In reply to comment #1)
> What's the point of being vague here?  The browsers all use the @type media
> type, and there are scads of web sites that rely on this behavior.  In the
> email you cite, Jonas says that he wishes it weren't the case but he's not
> willing to implement the alternate behavior.

Actually, the alternate behavior already was implemented, and backed out because of *some* sites. AFAIR, Jonas said that it might be possible to revert that change by applying sufficient evangelism.

Also, this is not being vague. This is about allowing exactly two behaviors, of which one currently *seems* to be necessary, and the other one would be consistent with HTML4 and the web architecture in general (authoritative metadata). 

How is this different from the approach in draft-abarth-mime-sniff, which also allows both strategies?

Comment 3 Adam Barth 2009-12-13 11:03:29 UTC
> Actually, the alternate behavior already was implemented, and backed out
> because of *some* sites. AFAIR, Jonas said that it might be possible to revert
> that change by applying sufficient evangelism.

He says he's not willing to do it unless someone shows him compatibility data.  Do you have compatibility data?

> Also, this is not being vague. This is about allowing exactly two behaviors, of
> which one currently *seems* to be necessary, and the other one would be
> consistent with HTML4 and the web architecture in general (authoritative
> metadata). 

My understanding is the HTML4 compatibility is irrelevant.  You're right that your suggesting something that's vague in that it allows two possibilities: one that matches reality and one that's a pleasant fiction.

> How is this different from the approach in draft-abarth-mime-sniff, which also
> allows both strategies?

HTML5 requires the sniffing part of draft-abarth-mime-sniff.  The alternate mode is for non-HTML user agents, like SIP phones.  In this case, we're talking about how to interpret an HTML element, which isn't that interesting for SIP phones.
Comment 4 Julian Reschke 2009-12-13 12:00:35 UTC
(In reply to comment #3)
> HTML5 requires the sniffing part of draft-abarth-mime-sniff.  The alternate
> mode is for non-HTML user agents, like SIP phones.  In this case, we're talking
> about how to interpret an HTML element, which isn't that interesting for SIP
> phones.

That's definitively not what we agreed upon in the Working Group around one year ago. I'll open a separate bug.


Comment 5 Julian Reschke 2009-12-13 12:34:16 UTC
(In reply to comment #4)
> (In reply to comment #3)
> > HTML5 requires the sniffing part of draft-abarth-mime-sniff.  The alternate
> > mode is for non-HTML user agents, like SIP phones.  In this case, we're talking
> > about how to interpret an HTML element, which isn't that interesting for SIP
> > phones.
> 
> That's definitively not what we agreed upon in the Working Group around one
> year ago. I'll open a separate bug.

Actually, MINESNIFF has as Step 2 in Section 3:

   2.  If the user agent is configured to strictly obey Content-Type
       headers for this resource, then jump to the last step in this set
       of steps.

So yes, using the algorithm is mandatory, but the algorithm explicitly allows not to sniff.


Comment 6 Ian 'Hixie' Hickson 2010-01-10 10:55:28 UTC
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Accepted
Change Description: see diff given below
Rationale: I've allowed UAs to skip the sniffing steps, as with MIMESNIFF.
Comment 7 contributor 2010-01-10 11:04:08 UTC
Checked in as WHATWG revision r4556.
Check-in comment: Allow skipping sniffing steps.
http://html5.org/tools/web-apps-tracker?from=4555&to=4556