[EMAIL PROTECTED] wrote:
> In a message dated 01-09-04 19:17:25 EDT, Ian writes...
>
>
>>>ASIDE: You really only need the 'compression' part of it. You
>>>
>> > are a Server, not a client.
>>
>> we also can be a client.
>> think mod-proxy
>>
>
> What current ( or future ) operation would require mod_proxy
> to 'decompress' something? I would imagine that if mod_proxy
> can ever accept Content-Encodings it would do what SQUID
> does... it just stores the response and pays attention to the
> 'Vary' headers and such but there's never a need to 'decompress'
> anything.
>
I was thinking that the proxy could request gzip'd data, and possibly
get gzip'd returned. it would then examine the client's request and
if it can't handle a gzip reply it would ungzip it.
(this is the approach that rsync's rproxy takes.)
the proxy also reverse-proxies, and the output of that needs to be
plain text so it could be merged (via mod-include) (and then possibly
gzip'd again)
I'm going to run mod_gz through our benchmark lab tomorrow (8-way machine)
to see what happens (CPU Usage mainly,and to see if there are any resource leaks)
If I get a copy of mod_gzip for 2.0 I will do the same for it.
> Maintaining an 'object compression' cache is a bit different from
> regular caching and has to follow different 'rules'. Even if there is
> a way to store both a compressed and non-compressed version
> of the same URL in a cache there still isn't any real need to
> 'decompress' anything.
>
> Transfer-encoding: gzip, chunked or some other 'hop to hop' deal
> is a different story but there's still no known browser that can handle
> that ( nor any known Proxy that can, either, AFAIK ).
>
check out the work being down by the rproxy.samba.org on rproxy.
if we had rsync compression (and a proxy to un-rysnc it) it would be
really cool... (especially if mozilla could talk rproxy) but that is
pie in the sky.
> It was just a thought.
> If people think that ZLIB is 'too big' you can easily cut it in
> half by only including what you need.
>
nah... I'd rather just link to the one already living on people's systems.
the only advantage is if apache's memory pool handling is much faster than
zlibs plain old malloc.. but I'm not sold on that (we could link in hoard)
> Ian... are you a committer?
not on Apache, just APR & Proxy
> What do you say about adding ZLIB to Apache source ASAP.
> Yea or nay?
>
> Yours...
> Kevin Kiley
>
..Ian
