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

[Aryeh Gregor]

On Fri, Sep 3, 2010 at 5:05 PM, David Singer <singer at apple.com> wrote:
> Um, I think that in some cases the code that is supporting video/audio has ... historical artefacts ... which may not be entirely in line with the specs.  I think it's dangerous to make assumptions in this area, especially if you then go and ask for a change in a spec. based on assumptions.

Okay, okay, I'll try to avoid stating assumptions like that, at least
about people on the list.  :)  So never mind that point.  (Although I
was mostly thinking of IE, not Chrome and certainly not Safari.)  I
think sniffing is a good idea even if we could get everyone to agree
not to sniff.

On Fri, Sep 3, 2010 at 11:48 PM, Boris Zbarsky <bzbarsky at mit.edu> wrote:
>  > Okay, you're being too theoretical for me.  Let's say we have
>>
>> fingerprints for all the major video types, of the form "check if the
>> first X bytes match this very simple pattern".  Let's say the spec
>> says that whenever processing the response to an HTTP request,
>> browsers must act as though they executed the sniffing algorithm and,
>> if it sniffs as a video type, they must treat it the same as if the
>> Content-Type matched the sniffed type.
>
> OK, so context-independent?  Note that not a single browser implements this
> today.

Either context-independent, or specified to occur only in certain key
contexts like <video>/top-level browsing context.  No browser
implements my suggested behavior today, but I think we all agree it's
confusing/harmful to only sniff for <video> and not top-level browsing
contexts too, because it breaks all sorts of expected behavior (open
in new tab, copy video URL, etc.).

> Is this a reasonable supposition?  What are these byte sequences for the
> container formats at hand?  (Say WebM's restricted Matroska container,
> whatever container format is supported for H.264 by IE and Chrome, and Ogg;
> we'll ignore the generic Matroska weirdness for now.)

I don't know, which is why I'm considering a hypothetical.  If someone
who knows better could step up with this piece of info, that would be
helpful.

> Might be a good idea to ask the IE team, the Chrome team, and the Safari
> team why they're not sniffing in toplevel browsing contexts...  I believe
> there's been at least one answer from a Chrome developer on that already,
> though.

That would also be helpful information.  Andrew Scherkus made it sound
like Chrome wouldn't necessarily object to sniffing on top-level
browsing contexts, just that it would have to be sandboxed (although
I'm not sure why).

> Sure, but it's early days in implementation.  Note, also, that I believe
> it's 3 browsers, not 2.
>
> . . .
>
> Some of these changes take time (e.g. having to rejigger quicktime to allow
> you to no sniff while using it).  So is it that they have not changed, or
> that they have no plans to change, ever?
>
> . . .
>
> Such changes have happened in the past (e.g. for stylesheets, and for
> toplevel browsing contexts).  Why is this case different?

Okay, so maybe I'm too pessimistic.  :)  Regardless of this point, I
still think sniffing consistently is the best solution, *if* it can be
done reliably -- i.e., given the assumptions I gave in my sketch of a
proposal (easily-checked fingerprints that make text matches
impossible and binary matches of negligible likelihood).  If those
assumptions hold, would you agree that consistently sniffing is a
better idea than honoring clearly incorrect MIME types, assuming we
could get implementers to agree one way or the other?  If not, why
not?  I don't see significant downsides, and the upside of actually
being able to have stuff work without configuring MIME types seems
big.