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>.
signature.asc
Description: This is a digitally signed message part
