- From: Boris Zbarsky <bzbarsky@mit.edu>
- Date: Sun, 21 Aug 2005 11:20:19 -0500
- 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. -Boris -Boris
Received on Sunday, 21 August 2005 16:20:28 UTC