- From: Chris Lilley <chris@w3.org>
- Date: Fri, 10 Dec 2004 04:51:38 +0100
- 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