[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.
Andrew
-------------- 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