W3C home > Mailing lists > Public > public-html-bugzilla@w3.org > March 2011

[Bug 11984] Simplify <video> for implementors and authors by ignoring the Content-Type HTTP header

From: <bugzilla@jessica.w3.org>
Date: Thu, 03 Mar 2011 22:27:12 +0000
To: public-html-bugzilla@w3.org
Message-Id: <E1PvGzI-00050j-97@jessica.w3.org>

--- Comment #22 from Philip Jägenstedt <philipj@opera.com> 2011-03-03 22:27:09 UTC ---
OK, new suggestion:

* In most cases, including at least audio/* and video/*, trust the Content-Type
header and try decoding it as such. This is stricter than the current spec,
which requires sniffing after inspecting Content-Type.
* Sniff for the set of Content-Type values that are usually incorrect defaults,
like text/plain and application/octet-stream. The table in
<http://tools.ietf.org/html/draft-ietf-websec-mime-sniff-02#section-3> looks
relevant to this.
* Ignore the codecs parameter in the Content-Type header completely, since
codec setup cannot be done without inspecting the data anyway.
* Get rid of all special-casing of application/octet-type in canPlayType.

* Fixes the biggest problem of Content-Type, namely that videos served as
text/plain or application/octet-stream don't play.
* Respects Content-Type in cases where second guessing likely isn't useful,
like audio/* and video/*.
* Would work the same in a <video> context and in a top-level browsing context.
* Formats that are not reliably sniffable don't have to be added to the
sniffing table, they just wouldn't work when served as
* Browsers that sniff to support existing content (e.g. Safari) would likely
see less breakage than if moving to strict handling like Firefox/IE.
* It's still possible to move to "always sniff" from here without much damage
being left behind.

* Inconsistent with how <img> works.
* Requires considering both Content-Type and the data to determine what demuxer
to plug, rather than just one or the other.
* The codecs parameter would have an effect in canPlayType but not in
Content-Type. In practice the codecs parameter isn't sent in Content-Type, so
it's not the end of the world.

Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Thursday, 3 March 2011 22:27:14 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:44 UTC