cache gzipped content with proxy_pass
mat999 at gmail.com
Fri May 27 07:48:21 MSD 2011
You can cache the image filter using either lua or through a proxy pass to
But yes I agree with your points.
On Fri, May 27, 2011 at 10:28 AM, adamchal <nginx-forum at nginx.us> wrote:
> 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
> 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
> 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?
> Posted at Nginx Forum:
> nginx mailing list
> nginx at nginx.org
Warez Scene <http://thewarezscene.org> Free Rapidshare
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the nginx