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

Re: SVG12: Transfer-Encoding

From: Boris Zbarsky <bzbarsky@mit.edu>
Date: Sun, 21 Aug 2005 11:20:19 -0500
Message-ID: <4308A9C3.70707@mit.edu>
To: Chris Lilley <chris@w3.org>
CC: Bjoern Hoehrmann <derhoermi@gmx.net>, www-svg@w3.org

Chris Lilley wrote:
> Bjoern, looking at 3.6 Transfer Codings in the HTTP/1.1 specification
> http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.6
> We think you may be confusing Transfer-Coding with Content-Encoding,
> described in section 14.11 Content-Encoding
> http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.11
> or possibly even the Content-Transfer-Encoding values of MIME.
> Chunked transfer encoding is unrelated to Content-Encoding.

Chris, HTTP/1.1 allows values of Transfer-Encoding other than "chunked".  In 
particular, it allows "gzip" as a Transfer-Encoding value:

   The Internet Assigned Numbers Authority (IANA) acts as a registry for
   transfer-coding value tokens. Initially, the registry contains the following
   tokens: "chunked" (section 3.6.1), "identity" (section 3.6.2), "gzip" (section
   3.5), "compress" (section 3.5), and "deflate" (section 3.5).

The specification also clearly describes what the difference between the two 
headers.  "Content-Encoding: gzip" means that (per 14.11):

   The content-coding is a characteristic of the entity identified by the
   Request-URI. Typically, the entity-body is stored with this encoding and is
   only decoded before rendering or analogous usage.

while "Transfer-Encoding: gzip" means that (per 3.6):

   This differs from a content coding in that the transfer-coding is a property
   of the message, not of the original entity.

To make this clearer, if I have a gzipped SVG file on the server and I send it 
out as image/svg+xml I should set "Content-Encoding: gzip".  If I have an 
uncompressed SVG file on the server and I compress the data on the fly when 
sending it, I should set "Transfer-Encoding: gzip".  Note that in these two 
cases the actual _data_ sent is identical.  The difference is whether the 
compression is an inherent property of the resource or whether the compression 
was just tossed in to speed up network transmission.

Since section D.4.3 of SVG Tiny 1.2 indicates that "Content-Encoding" should be 
used any time "SVG is compressed with gzip", it would seem that following 
section D.4.3 for cases when the SVG is compressed on the fly entails a 
violation of the HTTP/1.1 RFC.  This seems undesirable.


Received on Sunday, 21 August 2005 16:20:28 UTC

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