On Tue, 5 Feb 2002 17:34:26 -0500, "Brad Clements" <[EMAIL PROTECTED]>

>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 

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

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

Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists -
 http://lists.zope.org/mailman/listinfo/zope )

Reply via email to