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

http://www.w3.org/Bugs/Public/show_bug.cgi?id=11984

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

Pros:
* 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
application/octet-stream.
* 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.

Cons:
* 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