[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 #23 from Adrian Bateman [MSFT] <adrianba@microsoft.com> 2011-03-04 20:12:33 UTC ---
(In reply to comment #22)
> 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.

We think we can live with this being what is in the spec. Unfortunately, we’re
too late to make changes in IE9 (we announced when we shipped the release
candidate that we would be shipping the final release shortly) and as usual I
can’t make predictions about when we will adopt things in future releases but
this seems like a reasonable compromise to work towards. As you mention, there
would be an inconsistency between handling of the codecs parameter between
canPlayType compared to playing but this is something we think is necessary
(for example to be able to choose between high and basic profile H.264
streams).

-- 
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 Friday, 4 March 2011 20:12:36 UTC