- From: Thomas DeWeese <Thomas.DeWeese@Kodak.com>
- Date: Wed, 08 Dec 2004 14:48:25 -0500
- To: Boris Zbarsky <bzbarsky@MIT.EDU>
- CC: www-svg@w3.org
Boris Zbarsky wrote:
>
> Thomas DeWeese wrote:
>
>> But this is a case of inconsistent meta-data. The sender says
>> that the data is not encoded, but the content indicates that it is
>> GZIP encoded.
>
> How, exactly, does the content indicate this? Via byte-sniffing and
> guessing that some byte sequences correspond to certain data types?
I don't think there is generally any other way to detect
inconsistent meta-data is there? Heck even within XML the
detect of UTF-8/16 relies on this basic technique.
> I'd think we would want to avoid that mess. Otherwise, why bother with
> MIME types and encoding types at all?
Well first off because (unfortunately in my mind) not all content
has a magic number that can be so easily checked. In other words
there is lots of content that is not "self describing" in useful
ways. Second off it's nice when it works. This whole thread has
been about what to do when it _doesn't_ work because someone
mislabeled something.
> This all sounds to me like an attempt to legislate existing broken UA
> and content provider behavior into technically being correct....
Who said any of this was a matter of "correct". Clearly the
transfer has problems, you stated that taking the simplest of steps
(as suggested by the SVG specification) to figure out what the problem
was is inconsistent with the TAG finding. I only got involved because
this is clearly not what the TAG intended, they do envision (perhaps
even support) noticing inconsistencies, rectifying them and notifying
the user.
Received on Wednesday, 8 December 2004 19:48:27 UTC