On Tue, 5 Feb 2002 17:34:26 -0500, "Brad Clements" <bkc@murkworks.com> wrote:
I hacked the attached code into HTTPResponse, at the end of setBody. It works for xml-rpc responses and I suppose any text output, so long as the response object has a header named "dogzip" set.
I think you also need to check the accept-encoding header, to allow for clients that do not know how to gunzip. That also means you should set caching headers to prevent the compressed and uncompressed responses getting delivered to the wrong clients by a cache.
Also, RESPONSE.setBody really should have access to REQUEST.headers. What's the clean way to do that? Just pass the request object to response object's init method?
RESPONSE objects have a REQUEST attribute
Anyone think this is worthwhile?
I looked at this roughly 18 months ago and came to the conclusion that (at the time) adding content-encoding support in Zope was the wrong way to do it. It you are using Zope behind a front-end proxy.... and you really should be..... then it seems like a better idea to deliver the message to that proxy in an uncompressed form, and let it negotiate a transfer-encoding on its own. (Note that is transfer-, not content-encoding) The advantages of this scheme come from the fact that transfer-encoding is a hop-by-hop property. Two downstream caches can negotiate the best compression for that hop. Pushing everything downstream takes load away from zope, and making it a local choice means that the choice is often a better one. At the time, this type of auto-compressing proxies looked like they were just coming of age (http://rproxy.samba.org looked good at the time too). Unfortunately nothing has changed since. Today I think only Apache can do this (and has done for ages). Support in squid has stalled (http://devel.squid-cache.org/projects.html#te). Although I still think this is the way of the future, I suspect the short-term advantage of content-encoding the way you implemented it may be an advanatge for longer than I originally thought. I hope this helps, Toby Dickenson tdickenson@geminidataloggers.com