Martin Jonsson wrote:
Sure, but my patch will need a little bit more attention first. It
seems I'm a bit busy this week but I expect to have it done by the
weekend.
Update: I decided to give the protocol cache itself some knowledge about
compression instead of compressing the request outside of the protocol
cache and register vary callbacks to deal with various browser
capabilities. Compressed entries are now stored in the protocol cache,
and entries are decompressed on the fly if the client isn't gzip-aware.
That makes it possible to avoid different cache entries for different
browser compression capabilities. The size of the protocol cache should
also be reduced a bit since entries are stored in the compressed form
(memory is cheap these days, but anyways ... ;) )
After the discussions I also decided to drop deflate capabilities for
now. The number of requests where the client announces deflate
capabilities but not gzip should be very few and gzip seems to be the
most supported compression method (MS' deflate implementation is a bit
broken.)
As Arjan pointed out, the vast majority of the browsers should be
gzip-enabled these days, so the extra load coming from decompressing
entries on the fly should be very low. It seems it's still faster, in
many cases, than bypassing the cache and letting the request pass to a
listening filesystem anyways. There will still be an option to enable
compression of dynamic requests, though.
Finally, since I changed strategy a bit the config options are still
hard coded in this new implementation. I'll try to get it done the next
few days.
/Martin
--
Martin Jonsson E-mail: <[email protected]>
Developer Cell: +46-709-153931
Roxen Internet Software AB
