Opened 7 months ago

Closed 6 months ago

Last modified 6 months ago

#2563 closed defect (duplicate)

Does not respect cache-control when using proxy_cache_use_stale updating

Reported by: aminvakil@… 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/ --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 aminvakil@…)

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



It happens for 1 percent of clients and whenever I try to reproduce this I get


, so I'm not sure how to go further with this.

Change History (5)

comment:1 by aminvakil@…, 7 months ago

Description: modified (diff)

comment:2 by Maxim Dounin, 6 months ago

Resolution: duplicate
Status: newclosed

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).

comment:3 by aminvakil@…, 6 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 Maxim Dounin, 6 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 aminvakil@…, 6 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!

Note: See TracTickets for help on using tickets.