[whatwg] Video with MIME type application/octet-stream
Simetrical+w3c at gmail.com
Sun Sep 5 12:59:09 PDT 2010
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
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
> 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,
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
More information about the whatwg