W3C home > Mailing lists > Public > www-svg@w3.org > August 2005

Re: SVG12: Transfer-Encoding

From: Chris Lilley <chris@w3.org>
Date: Sun, 21 Aug 2005 18:50:46 +0200
Message-ID: <782696721.20050821185046@w3.org>
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

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