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

[Boris Zbarsky]

On 9/3/10 3:48 PM, Aryeh Gregor wrote:
>> Why are you assuming that?
>
> Because blocking an entire MIME type seems like it would be massive
> overkill . . . but if that's a real use-case, well, okay.  It still
> can't be *too* hard to check the first few bytes of the contents.
> They must do it anyway if they implement this for images, right?

Yes.

But note that for some video formats checking the first few bytes is not 
sufficient.  In fact, some video container formats can have arbitrary 
length prefixes before the actual video data starts.  Of course if 
sniffers are just restricted to the first few bytes that might be ok.

  > 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.

> Also suppose that the fingerprints include byte sequences that cannot occur in normal text
> encodings

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.)

> and that they're long enough that random false positives
> are extremely unlikely.  What's the problem with this specific
> proposal?

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.

>> Er... Where did I propose this?  I proposed speccing that there MUST NOT be
>> any sniffing, with browsers that sniff therefore being nonconformant.  I
>> didn't propose allowing ad-hoc sniffing.
>
> Right.  But the spec never allowed sniffing, and two browsers do it
> anyway.

Sure, but it's early days in implementation.  Note, also, that I believe 
it's 3 browsers, not 2.

> Ian has spoken to those browsers' implementers, and the
> browsers have not changed, despite knowing that they aren't following
> the spec.

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?

> Do you have any particular reason to believe that they'll
> change?

Such changes have happened in the past (e.g. for stylesheets, and for 
toplevel browsing contexts).  Why is this case different?

>> Only if "consistent" includes "consistent across all contexts".... (which no
>> one is proposing to either specify or implement).
>
> Could you comment specifically on the behavior I outlined above?

The behavior you outlined above is "consistent" in this sense, yes.

-Boris