- From: Chris Lilley <chris@w3.org>
- Date: Tue, 11 Oct 2005 19:58:35 +0200
- To: Boris Zbarsky <bzbarsky@MIT.EDU>
- Cc: Yves Lafon <ylafon@w3.org>, Bjoern Hoehrmann <derhoermi@gmx.net>, <www-svg@w3.org>
On Tuesday, October 11, 2005, 7:30:55 PM, Boris wrote: BZ> Chris Lilley wrote: >> Yes, I agree with that. So,whether the HTTP layer understands or does not >> understand gzip as a Transfer-Encoding is >> >> a) orthogonal to the use of Content-Transfer-Encoding BZ> There is no Content-Transfer-Encoding in HTTP. I always do that. Content-Encoding. >> b) transparent to the SVG implementation BZ> The relevant part of the specification is talking about the server, not BZ> the SVG implementation. It's not transparent to the server. >> It also looks as if nothing needs to be said regarding conformance - if >> the client sends a TE header and the server uses the values from the TE >> header, it all works and if not, the TE header will not be sent. Either >> way, by the time the SVG implementation sees the content,any encoding of >> the message has been undone. BZ> My problem with the spec as written is that it's encouraging SVG servers BZ> to send Content-Encoding for what is actually a Transfer-Encoding, BZ> leading the client to wonder which it really was. Right; I agree that this is not the intent. Here is what the spec currently says for Conforming SVG Servers: <p>Conforming SVG Servers must meet all the requirements of a Conforming SVG Generator. In addition, Conforming SVG Servers using HTTP or other protocols that use Internet Media types must serve SVG stand-alone files with the media type <tt>image/svg+xml</tt>.</p> <p>Also, if the SVG content is compressed with gzip or deflate (i.e.an svgz file), Conforming SVG Servers must indicate this with the "Content-Encoding: gzip" or "Content-Encoding: deflate" headers, as appropriate,if the protocol supports them.</p> <p><em>Note:</em> This compression of <em>content</em> (the entity,in HTTP terms) is distinct from automatic compression of the <em>message</em>,as defined in HTTP/1.1 <a href="http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.39">TE</a>/<a href="http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.41">Transfer Encoding</a>.</p> So, it distinguishes between compression of the content and compression of the message, as you and Yves explained, and it defers to HTTP/1.1 for whether Transfer-Encoding uses gzip or not. BZ> Doesn't matter for BZ> rendering purposes, but does matter for saving, for example -- if it's a BZ> really a Content-Encoding, then compressed SVG should be saved. If the BZ> compression was just added to speed up HTTP transfer, then uncompressed BZ> SVG should be saved. But if the server uses Content-Encoding for both BZ> cases, how is a client to tell? Its not intended to be using it for both cases. Yves seemed to think it was already clearly about only content compression, not message compression. I believe this latest change makes that abundantly clear. Do you agree? -- Chris Lilley mailto:chris@w3.org Chair, W3C SVG Working Group W3C Graphics Activity Lead Co-Chair, W3C Hypertext CG
Received on Tuesday, 11 October 2005 17:58:53 UTC