Re: gzip support

On Sun, 2002-12-15 at 11:54, Stephen Sprunk wrote:
> I've been thinking about gzip Content-Encoding, and it seems to me
> that Vary support isn't really necessary. Here's my idea:

For a proxy, Vary support is essential. Fortunately we have that :}.

Note that your idea MUST NOT be turned on by default. And should *never*
be turned on for intercepting proxies. See the RFC 2616 requirements for
transparent proxies for more detail.
 
> . Add a filter for which content-types should be gzip'd (default to
> text/*)
> . Request all content in gzip encoding; store as received
> . Compress non-gzip content in the background

This will be interesting :}. You'll need to start by coding a
storeobject->storeobject copy engine. Definately doable though.

> . Track both the compressed and uncompressed content-lengths
> . Do on-the-fly decompression as needed for the extremely rare
> browsers that don't request gzip

Don't forget to emit Vary headers for the logic you use to choose which
variant to send, on every request. Also be sure to exclude range
requests from recieving gzipped content, or asking for gzipped content
therein.
Also, you should add a Warning header on any replies that are not
semantically transparent - that is when you have made *any* decision
about what content-encoded form to send to the client. (If we make the
decision, then the origin has *not* made the decision).

Having said all that, this could be very useful for reverse proxies.

Cheers,
Rob