I've been following this discussion and I'm anxiously waiting for some resolution. I think Maxim's approach is right: implementing a gzip_cache filter that could be used for caching any content. This would allow for much more flexibility than just using it for proxy_pass/proxy_cache.

This could effectively eliminate the gzip_static filter. If you have plain HTML served and "gzip on;" plus something like "gzip_cache on;" all of your plain text content would be served using the cached gzip content. Similarly, you would be able to use this for proxy_pass, proxy_store, fastcgi_pass, etc. It wouldn't matter since the caching of the gzip'd content would be stored in the gzip_cache filter and negotiated directly with the client.

There's a lot of chatter about using Varnish or Lighty or <insert another web/cache server here> to give Nginx pre-gzipped data in a proxy response. This sounds absolutely horrible. The bottom line is that if Nginx is the webserver that is dealing with the client directly, it should then be Nginx's responsibility to serve the appropriate version (gzip'd or plain text) content based on the client's request headers. That being said, Nginx should be managing it's own cache of filtered items.

The same goes for the image_filter. Currently, I use the image_filter for a project and I'm bummed out that Nginx is scaling the same image over and over each time it is requested. An image_filter_cache would be another great feature.

Am I on the right track?