Re: gzip support

On Mon, 2002-12-16 at 07:48, Stephen Sprunk wrote:
> > For a proxy, Vary support is essential. Fortunately we have that :}.
>
> Forgive me; the article I read claimed squid's lack of Vary support
> is a large reason nobody uses the Content-Encoding field.

Which article? (We should send them an errata note, at least).
 
> I don't see any indication that modification of content-[en]coding
> must be off by default.

For -squid-. Given squids raison d'etre...

>I can't think
> of any problems either case would cause.

Oh, well here's one.

Child A requests foo. Parent returns Etag X, with gzip CE, client gets
given etag X, identity CE.

Child B requests foo. Cache returns foo, gzipped as the Accept-Encoding
indicates it can accept. Child B crashes. (As apparently netscape 4.x
does with gzipped .css (or something similar. The mod-gzip folk have a
huge list of browser idiosyncracies)).

Simply - the semantics have been broken for forward proxies. So wrong
things *will happen*. It's a question of how minimal those things can
be.
 

> Is that an effort that is justified by the potential benefits?

For a certain value of effort, yes. I think it would be a good thing to
do, and as Henrik says, most of the infrastructure is there already.
 
> > Having said all that, this could be very useful for reverse proxies.
>
> I think it would be extremely useful for forward proxies as well, but
> should probably be turned off by default since the compression will
> eat CPU power and the required Warning may surprise people.

It should be off by default in forward proxies because squid by default
is a semantically transparent proxy, CPU is not the issue.

Rob