Regression in 1.14 when following upstream redirects
Maxim Dounin
mdounin at mdounin.ru
Tue May 15 03:38:05 UTC 2018
Hello!
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
related:
*) 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
http://mdounin.ru/
More information about the nginx
mailing list