2010/5/10 Maxim Dounin <mdounin@mdounin.ru>:
> 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
http://myserver.com/content/id354325435ed434, 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 http://sysoev.ru/nginx/docs/ 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...
--
RPM

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