[whatwg] Video with MIME type application/octet-stream

On Tue, Aug 31, 2010 at 3:36 AM, Ian Hickson <ian at hixie.ch> wrote:
> The Microsoft guys responded to my suggestion that they might want to
> implement something like this with "what's the benefit of doing that?".
> It's a tough question, in this context, given that there's no possibilty
> of script execution or other privilege escalation with the types we're
> talking about (currently, anyway).

If you can't come up with any actual problems with what IE is doing,
then why is anything else even being considered?  There's a very
clear-cut problem with relying on MIME types: MIME types are often
wrong and hard for authors to configure, and this is not going to
change anytime soon.

> Sadly, the boat has sailed for text/html and XML at this point, but for
> binary types, and for contexts where text/plain isn't a contender, why
> bother doing anything but sniff?

If this is your position, why doesn't the spec match it?

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?

Received on Tuesday, 31 August 2010 12:59:14 UTC