Re: SVG12: image/svg+xml gzip requirements
* Thomas DeWeese wrote:
The TAG finding has no impact whatsoever on SVG Viewer conformance requirements, I think the TAG will happily clarify this if you ask for it on www-tag. You would need to argue that this is allowed by the SVG Viewer conformance requirements. I think it is clear that this is not allowed by those conformance requirements.
Huh? If the network layer detects that the HTTP response is in fact GZip encoded even though the header isn't set and decodes it why is this a problem?
Because such software does not interoperate with software that does not perform such error correction. Would you also argue that for a ISO-8859- 1 encoded document Content-Type: image/svg+xml <?xml version="1.0"?> ... <text>Björn</text> ... the "network layer" may detect that the resource is ISO-8859-1 encoded and decodes it? The XML 1.0 Recommendation requires here, too, that the processor aborts normal processing and reports a fatal error to the application. I am not sure where you draw the line between errors this "network layer" may correct.
I'll agree with this. However you should then agree that there is no problem if the SVG mime-type registration states that there is _no_ charset parameter for image/svg+xml, and merely suggests that if a processor encounters this non-existing parameter that it should be ignored.
The proposed registration implies "MUST ignore", changing that to SHOULD ignore is even worse as it explicitly allows non-interoperable behavior. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de 68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
On Wed, 8 Dec 2004, Bjoern Hoehrmann wrote:
Huh? If the network layer detects that the HTTP response is in fact GZip encoded even though the header isn't set and decodes it why is this a problem?
Because such software does not interoperate with software that does not perform such error correction. Would you also argue that for a ISO-8859- 1 encoded document [...] I am not sure where you draw the line between errors this "network layer" may correct.
Indeed; the logical conclusion of the "correct it in the network layer" thinking is how you get to the world where IE will treat anything that happens to contain the string "<html>" as an HTML document, even if it is sent as text/plain. That kind of "magic error fixing" has security implications (hence why XPSP2 reduced the amount of sniffing in IE). I would strongly recommend that specs disallow sniffing of any kind, treating all metadata as authorative (and giving explicit priorities to handle metadata contradictions). In certain rare cases where sniffing is required due to missing metadata (as in the lack of byte order information when no authorative default is stated), then the sniffing performed should be well defined in order to allow all UAs to have exact interoperability. IMHO. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Bjoern Hoehrmann wrote:
* Thomas DeWeese wrote:
The TAG finding has no impact whatsoever on SVG Viewer conformance requirements, I think the TAG will happily clarify this if you ask for it on www-tag. You would need to argue that this is allowed by the SVG Viewer conformance requirements. I think it is clear that this is not allowed by those conformance requirements.
Huh? If the network layer detects that the HTTP response is in fact GZip encoded even though the header isn't set and decodes it why is this a problem?
Because such software does not interoperate with software that does not perform such error correction.
Well, you are free to your option but don't reference a TAG finding saying it doesn't support this behavior when it clearly does!
participants (3)
-
Bjoern Hoehrmann -
Ian Hickson -
Thomas DeWeese