gzip compression reduces the transport size of responses up to 80%, depending on the "fluffiness" of the data.
There are other ways of doing this. For example, there is an Apache module, mod_gzip, that does this. But if you are running Zope 3 bare or behind a different load-balancer or proxy without gzip capability (e.g., pound), httpgz may be something you would want to use.
By default, httpgz will compress any responses of MIME types:
It is thought that these MIME types will be the majority of compressible files; particularly included are text/html and application/x-javascript. A quick look at the code will show that adding or omitting mime types is a trivial exercise.
Most internet browsers will accept gzipped responses, so this can be a big win for your bandwidth. Decompression happens automatically on the client, so this may be considered a transparent technology. The pages look and behave the same, but the speed of transport is substantially improved because the size of the transported response is much smaller.
Compression only happens when the client specifically claims that gzipped responses are OK. If the client does not advertise that it does gzip decompression, it will not receive gzipped responses. Accordingly, httpgz will not affect most automated testing.
This particular implementation may not be the most elegant way to do this operation in Zope 3, but it seems to be "the simplest thing that could possibly work." httpgz is compatible with zc.resourcelibrary, which also does post-processing of browser requests. httpgz does not require zc.resourcelibrary.
httpgz requires Zope 3 version 3.2 or later.
Testing was done by inspection. Either it compresses, or it doesn't. This package simply adds a conditional operation to Zope 3 core code.
Special thanks to Alan Kennedy http://www.xhaus.com/alan/python/httpcomp.html for putting up some code I can understand.
-Jim Washington
-18 March 2006