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>.
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:20:44 MST