W3C home > Mailing lists > Public > public-html@w3.org > July 2010

Re: video/@src vs application/octet-stream

From: Maciej Stachowiak <mjs@apple.com>
Date: Mon, 19 Jul 2010 11:52:51 -0700
Cc: Boris Zbarsky <bzbarsky@MIT.EDU>, "public-html@w3.org" <public-html@w3.org>
Message-id: <7699313C-01DE-4D81-B01F-4C919AC8A667@apple.com>
To: Julian Reschke <julian.reschke@gmx.de>

On Jul 19, 2010, at 11:20 AM, Julian Reschke wrote:

> On 19.07.2010 20:09, Maciej Stachowiak wrote:
>> ...
>> For Safari/WebKit, we wanted to make it possible for the<video>  element to play content that was previously embedded via the QuickTime plugin or other plugins we support. Unfortunately, a fair proportion of such content is being served with the wrong MIME type, most typically application/octet-stream but sometimes also text/plain. We thought it might create too high a barrier, if authors had to reconfigure their Web servers before they could switch from the QuickTime plugin to<video>.
>> ...
> Thanks for the feedback.
> So, does this make Safari non-compliant? It appears so, as draft-abarth-mime-sniff doesn't mention sniffing for video, and the spec text about video/@src doesn't seem to make an exception.

>From testing, it looks like our implementation will successfully play an MPEG-4 video embedded in the <video> element, when served as the following types:


I believe our behavior is to completely ignore the MIME type and only rely on sniffing for <video>, much as the spec suggests and as UAs actually do for <img>. It is possible our sniffing could be restricted to a narrower set of types, but I'd have to ask the <video> experts on the team about that and we may need to run an experiment.

Also, note that this sniffing only applies in the context of the <video> element. If you navigate directly to a video served with one of the above types as the main URL, then in no case will we attempt to play the video (the behaviors are download; display garbled text; broken image icon; download, respectively).

I think it is reasonable for <video> to ignore MIME type just as <img> does; media formats are, in general, unambiguously sniffable, and do not contain active content that would pose a security risk. It is also plausible to have narrower sniffing rules, or none at all. We haven't done testing to determine the minimum level of sniffing that works well.

Note: if a file in media format we support is incorrectly served with the MIME type of another, incompatible format that we also support, then it would be challenging to get that file to fail instead of playing correctly, since we rely on an underlying media framework to do the playback and format detection.

Received on Monday, 19 July 2010 18:53:24 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:45:21 UTC