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
