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

Re: SVG12: Transfer-Encoding

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Tue, 11 Oct 2005 12:30:55 -0500
Message-ID: <434BF6CF.2080501@mit.edu>
To: Chris Lilley <chris@w3.org>
CC: Yves Lafon <ylafon@w3.org>, Bjoern Hoehrmann <derhoermi@gmx.net>, www-svg@w3.org

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

There is no Content-Transfer-Encoding in HTTP.

> b) transparent to the SVG implementation

The relevant part of the specification is talking about the server, not 
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.

My problem with the spec as written is that it's encouraging SVG servers 
to send Content-Encoding for what is actually a Transfer-Encoding, 
leading the client to wonder which it really was.  Doesn't matter for 
rendering purposes, but does matter for saving, for example -- if it's a 
really a Content-Encoding, then compressed SVG should be saved.  If the 
compression was just added to speed up HTTP transfer, then uncompressed 
SVG should be saved.  But if the server uses Content-Encoding for both 
cases, how is a client to tell?

-Boris
Received on Tuesday, 11 October 2005 17:31:11 GMT

This archive was generated by hypermail 2.3.1 : Friday, 8 March 2013 15:54:31 GMT