Re: gzip support

Thus spake Robert Collins:
> 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 :}.

Forgive me; the article I read claimed squid's lack of Vary support
is a large reason nobody uses the Content-Encoding field.

> 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.

Section 14.11 states:
   However, a non-transparent proxy MAY modify the content-coding if
   the new coding is known to be acceptable to the recipient, unless the
   "no-transform" cache-control directive is present in the message.

I don't see any indication that modification of content-[en]coding
must be off by default. One can presume that it MUST NOT be done by
transparent proxies, but that's not explicitly stated. I can't think
of any problems either case would cause.

> > . 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.

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

> Also be sure to exclude range requests from recieving gzipped
> content, or asking for gzipped content therein.

I'm still a bit fuzzy on the RFC's terminology... Does the gzipped
content qualify as an entity or message body?

Section 14.35.1:
   Byte range specifications in HTTP apply to the sequence of bytes in
   the entity-body (not necessarily the same as the message-body).

> 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).

Another good point; 14.46 specifically requires a Warning: 214 in this
case.

> 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.

S

-- 
Stephen Sprunk         "God does not play dice."  --Albert Einstein
CCIE #3723         "God is an inveterate gambler, and He throws the
K5SSS        dice at every possible opportunity." --Stephen Hawking