- From: Chris Lilley <chris@w3.org>
- Date: Sun, 21 Aug 2005 18:50:46 +0200
- To: Boris Zbarsky <bzbarsky@mit.edu>
- Cc: Bjoern Hoehrmann <derhoermi@gmx.net>, www-svg@w3.org
On Sunday, August 21, 2005, 6:20:19 PM, Boris wrote: BZ> To make this clearer, if I have a gzipped SVG file on the server and BZ> I send it out as image/svg+xml I should set "Content-Encoding: BZ> gzip". If I have an uncompressed SVG file on the server and I BZ> compress the data on the fly when sending it, I should set BZ> "Transfer-Encoding: gzip". Note that in these two cases the actual BZ> _data_ sent is identical. The difference is whether the compression BZ> is an inherent property of the resource or whether the compression BZ> was just tossed in to speed up network transmission. Thanks, that is much clearer. (However, if someone gzips an SVG document, the intent is also to speed up network transmission.) BZ> Since section D.4.3 of SVG Tiny 1.2 indicates that "Content-Encoding" should be BZ> used any time "SVG is compressed with gzip", it would seem that following BZ> section D.4.3 for cases when the SVG is compressed on the fly entails a BZ> violation of the HTTP/1.1 RFC. This seems undesirable. Aha, thanks (unless the server compresses the compressed content, which is futile but seemingly allowed by the spec). OK we will clarify for the case where the server compresses on the fly. -- Chris Lilley mailto:chris@w3.org Chair, W3C SVG Working Group W3C Graphics Activity Lead
Received on Sunday, 21 August 2005 16:54:34 UTC