[whatwg] Video with MIME type application/octet-stream

[Philip Jägenstedt]

On Tue, 31 Aug 2010 09:36:00 +0200, Ian Hickson <ian at hixie.ch> wrote:

> On Mon, 19 Jul 2010, Philip Jägenstedt wrote:
>>
>> I've tested Firefox 3.6.4, Firefox 4.0b1 and Chrome 5.0.375.99 and none
>> return "maybe" for canPlayType("application/octet-stream"). I couldn't
>> get meaningful results from Safari on Windows (requires restart to
>> detect QuickTime, perhaps?).
>>
>> It would appear that Opera is the only browser that supports
>> application/octet-stream. At the time I added this, it was simply
>> because it is true, maybe we can play it. However, I see no practical
>> benefit of this spec-wise or implementation-wise. Since no other
>> browsers have implemented it, I am going to remove it from Opera and
>> hope that the spec will be changed to match this.
>
> Agreed. I've changed the spec to match.

I never did make that change, instead waiting for the outcome of this  
discussion. Note that since Opera uses the same code path for checking the  
argument to canPlayType and for the Content-Type header, the change would  
also have meant that videos served as application/octet-stream would stop  
working, in violation of the spec.

> On Thu, 22 Jul 2010, Philip Jägenstedt wrote:
>>
>> 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.
>
> On Thu, 22 Jul 2010, Maciej Stachowiak wrote:
>>
>> 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.
>
> On Fri, 23 Jul 2010, Philip Jägenstedt wrote:
>>
>> Right, it certainly isn't useful, I'm just pointing out that this is
>> what happens if one adds text/plain to the list of "maybe" codecs rather
>> than ignoring Content-Type altogether, which is the only thing you can
>> do within the bounds of the current spec to get text/plain to play. The
>> only 3 serious options I know are still the ones I outlined in my
>> earlier email.
>
> canPlayType() is now hardcoded as not supporting application/octet-stream
> even though that type is otherwise not considered one that isn't  
> supported
> (i.e. is a type that sniffs).

I'm not very happy with special-casing application/octet-stream only for  
canPlayType, especially as it only handles the exact string  
"application/octet-stream", not e.g. "application/octet-stream;" which  
would instead be put through the same code path as Content-Type and return  
"maybe".

At this point the least complex solution seems to be to ignore the  
Content-Type header and unless the teams behind Chrome, Safari and IE9  
have a sudden change of hearts it's the only realistic outcome. Perhaps we  
should also encourage authors to not send the Content-Type header at all,  
to remove any illusions of it having an effect.

-- 
Philip Jägenstedt
Core Developer
Opera Software