Hello,

Because uwsgi_cache_key has no default value (or rather, has the empty string as its default value), a configuration with uwsgi_cache set but uwsgi_cache_key not set behaves in a way that is very unlikely to be desired: Nginx caches the first publicly cacheable response it gets from upstream (for any request), and serves that cached response to *any* request mapping to the same location. The internals of that can be seen in the debug log, where the cache key is empty for all requests:

2014/09/09 17:41:02 [debug] 91211#0: *13 http cache key: ""

This is in contrast to a configuration with proxy_cache enabled but proxy_cache_key not set; that behaves OK because proxy_cache_key has a useful default.

Because of the *general* correspondence between the http_proxy and http_uwsgi modules, it's easy to fall into this trap, defining uwsgi_cache but not uwsgi_cache_key. When that happens, and unexpected responses start coming back, the first place one looks is error.log, and there's nothing there.

To get rid of this gotcha, I suggest either:

1. log a warning whenever a location/server/http block has uwsgi_cache set but no uwsgi_cache_key set.

or

2. change the default value of uwsgi_cache_key to a more useful default, such as $scheme$host$request_uri, similar to proxy_cache_key (not quite the same, because the proxy_cache_key has $proxy_host in its default, and there is no corresponding $uwsgi_host). You might not want to make such a default-behavior change in a subminor release --- but as a counterargument, the current default seems quite unlikely to be relied on by anyone.

Cheers,

Gulli