On Tue, Aug 31, 2010 at 12:59 PM, Aryeh Gregor <span dir="ltr"><<a href="mailto:Simetrical%2Bw3c@gmail.com">Simetrical+w3c@gmail.com</a>></span> wrote:<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">
On Tue, Aug 31, 2010 at 10:35 AM, Boris Zbarsky <<a href="mailto:bzbarsky@mit.edu">bzbarsky@mit.edu</a>> wrote:<br>
> You can't sniff in a toplevel browser window.  Not the same way that people<br>
> are sniffing in <video>.  It would break the web.<br>
<br>
</div>How so?  For the sake of argument, suppose you sniff only for known<br>
binary video/audio types, and fall back to existing behavior if the<br>
type isn't one of those (e.g., not video or audio).  Do people do<br>
things like link to MP3 files with incorrect MIME types and no<br>
Content-Disposition, and expect them to download?  If so, don't people<br>
also link to MP3 files with correct MIME types and expect the same?  I<br>
don't see how sniffing vs. using MIME type makes a compatibility<br>
difference here, since media support in browsers is so new -- surely<br>
whatever bad thing happens, sniffing will make it happen more often,<br>
at worst.<br>
<br>
What do Chrome and IE do here?<br>
</blockquote></div><br><div>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.</div>
<div><br></div><div>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.   </div><div>
<br></div><div>Andrew</div>