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

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.

Received on Sunday, 5 September 2010 12:59:09 UTC