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:
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:
log a warning whenever a location/server/http block has uwsgi_cache
set
but no uwsgi_cache_key set.
or
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.