[Zope-dev] Adding gzip compression to HTTPResponse.py
Brad Clements
bkc@murkworks.com
Wed, 6 Feb 2002 11:22:23 -0500
On 6 Feb 2002 at 10:40, Toby Dickenson wrote:
>
> 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.
Right, but I couldn't figure out how to see the request headers from response.setBody
>
> >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
Are you sure? I know that request objects have a response object. But looking at
publish.py doesn't look like it goes the other way.
> 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 am using Apache with mod_rewrite. Sure, it'd be great to compression there, but
Apache doesn't cache, you need squid for that, right?
For non-xmlrpc responses I'd want the stuff cached.
I agree, Transfer Encoding is the way to go, but based on remarks at:
http://www.iol.ie/~alank/python/httpcomp.html#encoding
I stuck with the simpler to understand content-encoding.
--
Shouldn't downstream caching proxies ungzip a response if they get a connection from
a client that doesn't support gzip? Or will they only do this if its Transfer-Encoded?
Brad Clements, bkc@murkworks.com (315)268-1000
http://www.murkworks.com (315)268-9812 Fax
netmeeting: ils://ils.murkworks.com AOL-IM: BKClements