Nginx http proxy caching

Ryan Malayter malayter at
Fri May 14 17:11:08 MSD 2010

2010/5/10 Maxim Dounin <mdounin at>:
> There are lots of situations where you have to cache private data
> on reverse proxy.  And you can do this safely by providing
> appropriate proxy_cache_key.

Only if you're able to create separate nginx locations or different
proxy_cache_key definitions for public items versus potentially
private dynamic pages based on URI alone. This isn't possible with
quite a few content management and collaboration systems, especially
those which dynamically return images or other content from a
database. In such systems, the URLs are usually something like, with Cache-Control and
Content-Type headers being set dynamically. You can't add a cookie or
anything else to the proxy_cache_key without giving up caching of
public items.

> I agree that private data shouldn't be cached by default, but I
> don't see any "fundamental violation" here.  In HTTP terms nginx
> is origin server, and it's up to it's admin to configure it to do
> whatever he want.

Nginx with the HTTP proxy module certainly doesn't meet the definition
of "origin" in RFC 2616. I agree the flexibility to go against the
specification is desirable, but as you say, the default behavior
should conform to the RFC.

> Wiki isn't documentation, it's user-contributed content.

Is the Russian version at the only
official documentation? I wish I understood Russian and was able to
help keep an up-to-date English version. Google translate does a
decent job, but with technical content that's not always good enough.

It would probably be best to distribute revision-controlled HTML
documentation which correspond to source code releases. I am willing
to help the project in this area.

> The only cache-control directives currently honored are "no-cache"
> and "max-age=".

I started looking at the source, but was thoroughly confused because
there are so few comments. It seems that a simple patch to
ngx_http_upstream.c which sets "u->cacheable = 0;" if a "private"
keyword (or for that matter other Cache-Control headers than nginx
does not yet understand) wold be a workable first step...

More information about the nginx mailing list