#2563 closed defect (duplicate)
Does not respect cache-control when using proxy_cache_use_stale updating
| Reported by: | Owned by: | ||
|---|---|---|---|
| Priority: | minor | Milestone: | |
| Component: | documentation | Version: | 1.22.x |
| Keywords: | Cc: | aminvakil@… | |
| uname -a: | Linux hostname 4.19.0-25-amd64 #1 SMP Debian 4.19.289-2 (2023-08-08) x86_64 GNU/Linux | ||
| nginx -V: |
nginx version: nginx/1.22.0
built by gcc 8.3.0 (Debian 8.3.0-6) built with OpenSSL 1.1.1n 15 Mar 2022 TLS SNI support enabled configure arguments: --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx --modules-path=/usr/lib/nginx/modules --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --pid-path=/var/run/nginx.pid --lock-path=/var/run/nginx.lock --http-client-body-temp-path=/var/cache/nginx/client_temp --http-proxy-temp-path=/var/cache/nginx/proxy_temp --http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp --http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp --http-scgi-temp-path=/var/cache/nginx/scgi_temp --user=nginx --group=nginx --with-compat --with-file-aio --with-threads --with-http_auth_request_module --with-http_realip_module --with-http_secure_link_module --with-http_slice_module --with-http_ssl_module --with-http_stub_status_module --with-http_sub_module --with-http_v2_module --with-cc-opt='-g -O2 -fdebug-prefix-map=/path/to/nginx-1.22.0=. -fstack-protector-strong -Wformat -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fPIC' --with-ld-opt='-Wl,-z,relro -Wl,-z,now -Wl,--as-needed -pie' |
||
Description (last modified by )
We have
proxy_cache_use_stale updating ...
in our proxy configurations, and on some paths, upstream is sending
cache-control: no-cache, no-store, must-revalidate pragma: no-cache expires: 0
in a 302 response.
It seems that nginx is caching this sometimes, because some clients are receiving 404 and all of those requests are
cache_status=UPDATING
.
It happens for 1 percent of clients and whenever I try to reproduce this I get
cache_status=EXPIRED
, so I'm not sure how to go further with this.
Change History (5)
comment:1 by , 13 months ago
| Description: | modified (diff) |
|---|
comment:2 by , 13 months ago
| Resolution: | → duplicate |
|---|---|
| Status: | new → closed |
comment:3 by , 13 months ago
Ah, I'm not sure but I think this bug is different from #853 as in our scenario upstream always return 302 and always sets no-cache headers.
comment:4 by , 13 months ago
The UPDATING status means that there is a stale (expired) response in the cache, and nginx already tries to update this response in a different request, hence the stale response from the cache is returned to the client.
That is, you do have a stale cache item in the cache. How it happened to be there depends on your particular setup, but most likely reasons include different upstream server behaviour in the past and/or different nginx configuration in the past.
Note that such responses might persist in the cache for a long time - as long as corresponding resources are periodically requested, nginx will consider these responses important and will not remove them from the cache, and since the new responses are non-cacheable, they won't be updated.
If in doubt, consider manually removing the cache. It should resolve the issue as long as the behaviour change happened at some point in the past, and there are no such periodic changes from cacheable to non-cacheable in your setup.
comment:5 by , 13 months ago
Thanks Maxim for your time and explanation!
Honestly I asked again and now I'm not completely sure if there was no time upstream returned another response code without cache control headers. We investigated further and realized it might have happened two or three months ago.
But to sum it up as we want to minimize the risk that something unexpected happens in case of a failure in upstream, I've removed updating from proxy_cache_use_stale.
Thanks again for your time!
This looks like a duplicate of #853. You have a stale cache item in the cache, which was previously saved to the cache, and the response nginx gets when trying to update this item does not allow caching, so the previously cached items stays in the cache. This stale item can be returned to clients if nginx is already updating the item (as per
proxy_cache_use_stale updating;in the configuration).