On Fri, Sep 3, 2010 at 5:05 PM, David Singer <sin...@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 <bzbar...@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.