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

Maciej Stachowiak mjs at apple.com
Tue Sep 7 09:12:19 PDT 2010

On Sep 7, 2010, at 3:52 AM, Philip Jägenstedt wrote:

> On Tue, 07 Sep 2010 11:51:55 +0200, And Clover <and-py at doxdesk.com> wrote:
>> On 09/07/2010 03:56 AM, Boris Zbarsky wrote:
>>> P.S. Sniffing is harder that you seem to think. It really is...
>> Quite. It surprises and saddens me that anyone wants to argue for *more* sniffing, and even enshrining it in a web standard.
> IE9, Safari and Chrome ignore Content-Type in a <video> context and rely on sniffing. If you want Content-Type to be respected, convince the developers of those 3 browsers to change. If not, it's quite inevitable that Opera and Firefox will eventually have to follow.

At least in the case of Safari, we initially added sniffing for the benefit of video types likely to be played with the QuickTime plugin - mainly .mov and various flavors of MPEG. It is common for these to be served with an incorrect MIME type. And we did not want to impose a high transition cost on content already being served via the QuickTime plugin. The QuickTime plugin may be a slightly less relevant consideration now than when we first thought about this, but at this point it is possible content has been migrated to <video> while still carrying broken MIME types.

Ogg and WebM are probably not yet poisoned by a mass of unlabeled data. It might be possible to treat those types more strictly - i.e. only play Ogg or WebM when labeled as such, and not ever sniff content with those MIME types as anything else.

In Safari's case this would have limited impact since a non-default codec plugin would need to be installed to play either Ogg or WebM. I'm also not sure it's sensible to have varying levels of strictness for different types. But it's an option, if we want to go there.


More information about the whatwg mailing list