On Wed, 01 Sep 2010 02:59:54 +0200, Andrew Scherkus
<[email protected]> wrote:
On Tue, Aug 31, 2010 at 12:59 PM, Aryeh Gregor
<[email protected]<simetrical%[email protected]>
wrote:
On Tue, Aug 31, 2010 at 10:35 AM, Boris Zbarsky <[email protected]>
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.
Can you elaborate on this? What would be the problem with sniffing in this
context?
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.
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
think).
--
Philip Jägenstedt
Core Developer
Opera Software
