Hello! On Fri, Jul 24, 2020 at 03:21:31PM +0200, Adam Volek wrote:
> On 24. 07. 20 4:33, Maxim Dounin wrote: > > As long as the response returned isn't cacheable (either > > as specified in the response Cache-Control / Expires > > headers, or per proxy_cache_valid), nginx won't put > > the response into cache and will continue serving previously > > cached response till stale-while-revalidate timeout expires. > > > > Most likely "specific status code" in your tests in fact means > > responses returned by your upstream server without Cache-Control > > headers, and hence not cached by nginx. > > This is not the case as far as I can tell. In our tests, the upstream server > was set up to send these two responses, the 204 first, and then then the 404: > > HTTP/1.1 204 No Content > Date: Fri, 24 Jul 2020 11:32:33 GMT > Connection: keep-alive > cache-control: max-age=5, stale-while-revalidate=10 > > HTTP/1.1 404 Not Found > Date: Fri, 24 Jul 2020 11:32:35 GMT > Content-Type: text/plain > Connection: close > cache-control: max-age=5, stale-while-revalidate=10 > > In this scenario, nginx returns fresh 204 for five seconds and then it > returns stale 204 for ten seconds even though it's attempting revalidation > according > to access log at the upstream server. If we send the following 410 response > instead of 404 however, nginx behaves as we would expect: it returns the fresh > 204 for five seconds, then it revalidates it almost instantly and starts > returning the fresh 410: > > HTTP/1.1 410 Gone > Date: Fri, 24 Jul 2020 11:41:56 GMT > Content-Type: text/plain > Connection: close > cache-control: max-age=5, stale-while-revalidate=10 You are right, this seems to be an incorrect behaviour of stale-while-revalidate / stale-if-error handling. Internally, stale-if-error (and stale-while-revalidate) currently behave as if "proxy_cache_use_stale" was set with all possible flags (http://nginx.org/r/proxy_cache_use_stale) when handling upstream server responses. Notably this includes http_403, http_404, and http_429 flags, and this causes the effect you observe. This probably should be fixed. Just in case, the following configuration can be used to reproduce the issue within nginx itself: proxy_cache_path cache keys_zone=one:1m; server { listen 8080; location / { proxy_pass http://127.0.0.1:8081; proxy_cache one; add_header X-Cache-Status $upstream_cache_status always; } } server { listen 8081; location / { add_header cache-control "max-age=5, stale-while-revalidate=10" always; if ($connection = "3") { return 204; } return 404; } } -- Maxim Dounin http://mdounin.ru/ _______________________________________________ nginx mailing list [email protected] http://mailman.nginx.org/mailman/listinfo/nginx
