Change blank uwsgi_cache_key default, or log warning

gthb nginx-forum at nginx.us
Tue Sep 9 18:25:15 UTC 2014


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

Posted at Nginx Forum: http://forum.nginx.org/read.php?2,253149,253149#msg-253149



More information about the nginx mailing list