On Tue, Mar 23, 2010 at 8:46 AM, Maxim Dounin <mdou...@mdounin.ru> wrote:

Transformation of content by proxies and caches is specifically allowed in the HTTP specs, unless a "Cache-Control: no-transform" directive is present.

Or were you referring to the nginx architecture/code specifically? If that is so, why is it not the business of proxy_cache to transform content (it already manipulates headers out of necessity)? Re-applying the same output filter repeatedly is wasteful and increases latency. If Igor is worried about the impact updating HTTP date strings more than once per second, surely avoiding thousands of loops through a gzip filter is an optimization that would be smiled upon?

Even Microsoft gets this specific part right (static content is cached in its compressed state in IIS, and can use a different compression ratio from dynamic content).

Integrating the compression with the "retrieval" portion of the cache code would allow for the use of high compression ratios for long-lived objects, as well as prevent duplication of data on disk. Also, any caching mechanism is going to need the same quantity of settings and infrastructure as proxy_cache already has, so there would be a lot of unnecessary code duplication if the mechanism was separate from proxy_cache. But it would be more general (for nginx) to have a separate standalone gzip_cache module.