[whatwg] <video> application/octet-stream
mjs at apple.com
Thu Jul 22 13:40:44 PDT 2010
On Jul 22, 2010, at 3:30 AM, Philip Jägenstedt wrote:
> On Thu, 22 Jul 2010 11:22:45 +0200, Henri Sivonen <hsivonen at iki.fi> wrote:
>> Chris Double wrote:
>>> As I mentioned in a previous email, the sniffing could result in a
>>> reasonable amount of data being consumed. I'm sure people who run
>>> sites that share HTML 5 video would appreciate browsers not consuming
>>> data bandwidth to sniff files that they've already specified as being
>>> something the browser doesn't support.
>> I think the solution to this concern is to allow authors of bandwidth-sensitive to specify the type attribute on <source> or the Content-Type header on the HTTP response to say something other than application/octet-stream or text/plain. For best performance, authors should use the type attribute in multi-<source> cases anyway.
> Chrome and Safari ignore the MIME type altogether, in my opinion if we align with that we should do it full out, not just by adding text/plain to the whitelist, as that would either require (a) canPlayType("text/plain") to return "maybe" or (b) different code paths for checking the MIME type in Content-Type and for canPlayType.
I don't think canPlayType("text/plain") has to return "maybe". It's not useful for a Web developer to test for the browser's ability to sniff to overcome a bad MIME type. canPlayType should be thought of as testing whether the browser could play a media resource that is "really" of a given type, rather than labeled with that type over HTTP.
More information about the whatwg