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

Re: SVG12: Transfer-Encoding

From: Yves Lafon <ylafon@w3.org>
Date: Wed, 12 Oct 2005 10:55:33 +0200 (MEST)
To: Boris Zbarsky <bzbarsky@MIT.EDU>
cc: Chris Lilley <chris@w3.org>, Bjoern Hoehrmann <derhoermi@gmx.net>, www-svg@w3.org
Message-ID: <Pine.GSO.4.63.0510121049470.17875@gnenaghyn.vaevn.se>

On Tue, 11 Oct 2005, Boris Zbarsky wrote:

> Yves Lafon wrote:
>> digging a bit (down to [1]), I think that the spec is correct as it talks 
>> only about the data (entity in the HTTP world) TE/Transfer-Encoding deals 
>> with the message level and is completely hidden from a data presentation 
>> layer.
>
> That part of the specification is talking about the server, not the 
> presentation layer.  That is, per that spec any server that sends SVG data 
> compressed with gzip must set Content-Encoding.  Even if the compression is a 
> transfer-encoding in this case.  This does not seem to be the intent of the 
> specification (or I certainly hope not!), but that's what it says.

Well, it depends on what "on the fly" compression mean. The server can 
associate a resource with an uncompressed file, and compress it on the fly 
for every request and send it with Content-Encoding: gzip (not efficient, 
I agree but doable). The resource is not synchronized with the actual 
bytes stored on the disk.
The fact that the spec talks about "SVG data" makes me think "entity 
body" and not "http message". But if other people have other 
interpretations, it should indeed be clarified.

[moving the off-topic discussion off this list]

Thanks,

-- 
Yves Lafon - W3C
"Baroula que barouleras, au tiéu toujou t'entourneras."
Received on Wednesday, 12 October 2005 08:56:09 GMT

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