- 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
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 UTC