[whatwg] Video with MIME type application/octet-stream
philipj at opera.com
Wed Sep 1 01:12:04 PDT 2010
On Wed, 01 Sep 2010 02:59:54 +0200, Andrew Scherkus
<scherkus at chromium.org> wrote:
> On Tue, Aug 31, 2010 at 12:59 PM, Aryeh Gregor
> <Simetrical+w3c at gmail.com<Simetrical%2Bw3c at gmail.com>
>> On Tue, Aug 31, 2010 at 10:35 AM, Boris Zbarsky <bzbarsky at mit.edu>
>> > You can't sniff in a toplevel browser window. Not the same way that
>> > 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
> in the browser versus download. We would never want to execute
> 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.
Can you elaborate on this? What would be the problem with sniffing in this
> 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
> itself would prompt a download.
If we start ignoring the Content-Type I expect we would also add sniffing
so that opening a video served with the wrong (or missing) Content-Type
still works in a top-level browsing context, as it does for images (I
More information about the whatwg