- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Tue, 11 Oct 2005 12:30:55 -0500
- 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 UTC