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

[Aryeh Gregor]

On Thu, Sep 2, 2010 at 4:41 PM, Boris Zbarsky <bzbarsky at mit.edu> wrote:
> Well, serving up data as text/plain for it to be readable is one.  I agree
> that for the specific case of <video> this is not a big deal.

Yes, I'm talking specifically about that.  Sniffing in other cases (in
particular, text formats) may be a bad idea.

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

> There are proposals for standardizing several different types of sniffing,
> with the one used being context-dependent.  A proxy wouldn't have the
> context.
>
> It can all be made to work by erring on the side of blocking more stuff, but
> then you get to the point where the proxy makes it impossible to use the
> browser altogether, and then it's not a viable solution to the problem at
> hand.

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.  (You could limit the scope of
that somewhat for ease of implementation if you like, but at least for
<video> plus top-level browsing contexts.)  Also suppose that the
fingerprints include byte sequences that cannot occur in normal text
encodings, and that they're long enough that random false positives
are extremely unlikely.  What's the problem with this specific
proposal?

>> Put another way: the problem here is not that browsers sniff.  It's
>> that browsers don't behave interoperably or predictably.  Speccing a
>> precise sniffing algorithm that everyone's willing to follow allows
>> proxies to reliably know what browsers will do with it.  What will
>> cause problems is what you seem to be arguing for -- *not* speccing
>> sniffing
>
> 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.  Ian has spoken to those browsers' implementers, and the
browsers have not changed, despite knowing that they aren't following
the spec.  Do you have any particular reason to believe that they'll
change?  If not, then the situation I described is exactly what your
proposal (i.e., the status quo) will result in, no?

> 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?  It's
entirely possible that I'm missing a lot of subtleties here.