W3C home > Mailing lists > Public > www-svg@w3.org > December 2004

Re: SVG12: image/svg+xml gzip requirements

From: Chris Lilley <chris@w3.org>
Date: Fri, 10 Dec 2004 04:51:38 +0100
Message-ID: <1287253417.20041210045138@w3.org>
To: Ian Hickson <ian@hixie.ch>
Cc: Bjoern Hoehrmann <derhoermi@gmx.net>, Thomas DeWeese <Thomas.DeWeese@Kodak.com>, <www-svg@w3.org>, <ietf-types@iana.org>

On Wednesday, December 8, 2004, 9:56:10 PM, Ian wrote:

IH> Indeed; the logical conclusion of the "correct it in the network layer"
IH> thinking is how you get to the world where IE will treat anything that
IH> happens to contain the string "<html>" as an HTML document, even if it is
IH> sent as text/plain.

But only if its in the first 256 bytes, so be carefull with those long
comments before the root element.

It also led to anything with Content transfer encoding being saved to
disk! which is why some SVG content was served without that, as an IE
workaround. It seems to be becoming less common. And of course, Firefox
and Opera and Safari don't have those sort of problems. Its something of
a FAQ.

IH> That kind of "magic error fixing" has security 
IH> implications (hence why XPSP2 reduced the amount of sniffing in IE).

IH> I would strongly recommend that specs disallow sniffing of any kind,
IH> treating all metadata as authorative

They do, although the xml encoding declaration is metadata too.

IH> (and giving explicit priorities to handle metadata contradictions).
IH> In certain rare cases where sniffing is required due to missing
IH> metadata (as in the lack of byte order information when no
IH> authorative default is stated), then the sniffing performed should
IH> be well defined in order to allow all UAs to have exact
IH> interoperability.

Yes. And reading an explicit xml encoding declaration, or choosing
between UTF-8, UTF-8 (with BOM) and UTF-16 (with BOM) is well defined in
the XML specification.

 Chris Lilley                    mailto:chris@w3.org
 Chair, W3C SVG Working Group
 Member, W3C Technical Architecture Group
Received on Friday, 10 December 2004 03:54:14 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 March 2017 09:47:01 UTC