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

Andrew Scherkus scherkus at chromium.org
Tue Aug 31 17:59:54 PDT 2010

On Tue, Aug 31, 2010 at 12:59 PM, Aryeh Gregor
<Simetrical+w3c at gmail.com<Simetrical%2Bw3c at gmail.com>
> wrote:

> On Tue, Aug 31, 2010 at 10:35 AM, Boris Zbarsky <bzbarsky at mit.edu> wrote:
> > You can't sniff in a toplevel browser window.  Not the same way that
> people
> > are sniffing in <video>.  It would break the web.
> How so?  For the sake of argument, suppose you sniff only for known
> binary video/audio types, and fall back to existing behavior if the
> type isn't one of those (e.g., not video or audio).  Do people do
> things like link to MP3 files with incorrect MIME types and no
> Content-Disposition, and expect them to download?  If so, don't people
> also link to MP3 files with correct MIME types and expect the same?  I
> don't see how sniffing vs. using MIME type makes a compatibility
> difference here, since media support in browsers is so new -- surely
> whatever bad thing happens, sniffing will make it happen more often,
> at worst.
> What do Chrome and IE do here?

We use the incoming MIME type to determine whether we render the audio/video
in the browser versus download.  We would never want to execute multimedia
sniffing code in the trusted/browser process so implementing sniffing for a
top level browser window would involve sending the bytes to a sandboxed
process for inspection first.

This does have a side effect where a <video> may play fine on a page with a
bogus MIME type (due to sniffing), but viewing the video URL in the browser
itself would prompt a download.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100831/4a6f3bb9/attachment-0002.htm>

More information about the whatwg mailing list