- From: Andrew Scherkus <scherkus@chromium.org>
- Date: Tue, 31 Aug 2010 17:59:54 -0700
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.htm>
Received on Tuesday, 31 August 2010 17:59:54 UTC