Re: squid-3.0 (3.1?) ce: gzip+deflate

From: Robert Collins <robertc@dont-contact.us>
Date: Thu, 16 Oct 2003 07:45:41 +1000

On Thu, 2003-10-16 at 07:20, Gonzalo Arana wrote:
> > Content-Encoding should not be done in a proxy unless you know exacly what
> > you are doing. There is very fargoing implications of applying
> > Content-Encoding to a entity.
>
> OUCH! ok, were may I read about it? (appart RFCs containing
> 'Content-Encoding').

RFC 2616. To do CE, you'll need to duplicate the sort of rule set that
mod_gzip has about what clients are broken, and what aren't. Thats what
the config rules you've created so far are for.

> >
> > Transder-Encoding may be done freely in a proxy with no implications,
> > except that HTTP/1.1 support is needed...
>
> mmm I want to compress text/(html|plain) responses to my dial-up users.
> This can't be done with Transfer-Encoding, am I wright?

No, because all the browsers I've seen do not offer to accept compressed
TE responses.

As to where? For an initial implementation (no compressed cached
responses...)
Well, I suggest you
1) test after the ESI test in client_side_reply for whether to do CE or
not.
2) do the compression as a new clientStreamModule, which means the only
place you need to alter is step 1).

There are plenty o' pitfalls here - I'd have rfc 2616 open beside you
for reference. (You'll be creating a non semantically transparent cache,
so you'll need to add a Warning header, for instance).

Cheers,
Rob

-- 
GPG key available at: <http://members.aardvark.net.au/lifeless/keys.txt>.

Received on Wed Oct 15 2003 - 15:45:42 MDT

This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:20:44 MST