Regression in 1.14 when following upstream redirects

Maxim Dounin mdounin at
Tue May 15 03:38:05 UTC 2018


On Mon, May 14, 2018 at 01:22:46PM -0400, vedranf wrote:

> There is a problem when nginx is configured to try to follow redirects (301)
> from upstream server in order to cache responses being directed to, rather
> than the short redirect itself. This worked in 1.12 and earlier releases.
> Here is the simplified configuration I use and which used to work:
> server { proxy_cache something;
> location / { proxy_pass http://upstream; }
> location @handle3XX {
>   proxy_cache_key ...;
>   set $target $upstream_http_location;
>   proxy_pass $target;
>   proxy_redirect off;
>   internal;
> }}
> With 1.12 this would cause nginx to follow the redirect and return the
> response after the (absolute) redirect. With 1.14 something weird is going
> on, it returns 301 back to the client and upstream_cache_status variable is
> set to HIT (even though 3XX aren't configured to be cached at all). If I
> repeat the request, I get 500 with "invalid URL prefix in" because $target
> is now empty as it didn't connect to the upstream at all.
> Debug logs for the critical part show this below (trimmed). Common for both
> nginx versions:


>From the incomplete configuration and debug log snippets you've 
provided it looks like your problem if that requests previously 
not cached now successfully extracted from cache.

>From the snippets you've provided it is not possible to conclude 
if the previous behaviour was buggy and now fixed (and your 
previous configuration worked due to a bug), or the new behaviour 
is incorrect.

There are at least some fixes in 1.13.x which might affect your 
configuration.  In particular, this fix in 1.13.6 might be 

    *) Bugfix: cache control headers were ignored when caching errors
       intercepted by error_page.

To further investigate things you may want to provide full 
configuration which demonstrates the problem, and full debug logs 
for requests in both versions.

Please avoid any modifications to configuration and debug logs.  
If you want to keep some information private, consider reproducing 
the problem in a sandbox without any private information instead.

Maxim Dounin

More information about the nginx mailing list