On Tue, Mar 23, 2010 at 8:46 AM, Maxim Dounin <mdounin@mdounin.ru> wrote:
> I belive proxy_cache must cache response as it was got from
> upstream.  It is not it's business to compress or change anything,
> there are output filters to do changes.

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).

> On the other hand it is believed to be good idea to implement
> cache support in gzip filter.  I.e. gzip filter will cache gzipped
> content and will send it to client instead of re-compressing it.
> And it's actually in Igor's plans AFAIK, but most likely not near
> plans.

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.
--
RPM

_______________________________________________
nginx mailing list
nginx@nginx.org
http://nginx.org/mailman/listinfo/nginx