[PATCH] reset r->cache->valid_sec for following the redirect

Sangdeuk Kwon dark264sh at gmail.com
Thu May 16 04:28:29 UTC 2019


Thank you for your review

> An obvious workaround is to ensure that such configuration do not
> allow caching of responses, for example, by using "proxy_cache
> off;" in such locations.

If using "proxy_cache off;", all response is not cached.
The expected behavior is
    1. when 200 response, it is cached
    2. when 3xx response, nginx follow the redirect and followed response
is cached
nginx cannot configure whether cache or not cache by response status code.

> Using "r->cache->valid_sec = 0;" based on the status code,
> however, looks wrong to me.  First of all, it doesn't actually
> disable caching, but rather preserves the existing response
> validity as is - and this may result in more or less arbitrary
> behaviour.

client ---> nginx ---> origin
  |---------->|---------->| req
  |<----------|<----------| 302 res
  |---------->|---------->| followed req
  |<----------|<----------| followed res

client ---> nginx ---> origin
  |---------->|---------->| req
  |              |<----------| 302 res
  |              |---------->| followed req
  |<----------|<----------| followed res

If nginx follow the redirect, it can reduce round-trip time of HTTP
request/response sequence between client and nginx


> Second, it doesn't clear to me if this is something to
> be done unconditionally - there can be configuration when caching
> is desired, despite the fact that $upstream_http_location will not
> be available.

I understood your concern. How about adding new directive?

Syntax: proxy_follow_redirect on | off;
Default: proxy_follow_redirect off;
Context: http, server, location

if (proxy_follow_redirect &&
    (status == NGX_HTTP_MOVED_PERMANENTLY
    || status == NGX_HTTP_MOVED_TEMPORARILY
    || status == NGX_HTTP_SEE_OTHER
    || status == NGX_HTTP_TEMPORARY_REDIRECT
    || status == NGX_HTTP_PERMANENT_REDIRECT))
{
    r->cache->valid_sec = 0;
}

Thanks,
Sangdeuk
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-devel/attachments/20190516/fad2fecd/attachment.html>


More information about the nginx-devel mailing list