try_files with map variable works differently in 1.10.x and 1.11.x

[Pyry Hakulinen]

Following config:

map $uri $wordpress_uri {
    default $uri;
#   Real config contains other stuff, which doesn't match, and doesn't matter (like this):
    ~^(/[_0-9a-zA-Z-]+)?(?<wp_file_uri>/wp-.+)$     $wp_file_uri;

}
server {
    listen 80;

    index index.php index.html;

    root /tmp/nginx;

    location / {
        try_files
            $wordpress_uri
            $wordpress_uri/
            @fallback;
    }
    location @fallback {
        return 200 "ok";
    }
}

/tmp/nginx/index.html

Somefile

On 1.11.x this will result in internal redirect loop:

2016/09/30 07:36:46 [error] 27355#0: *9 rewrite or internal redirection cycle while internally redirecting to "/index.html", client: 10.10.10.10, server: _, request: "GET / HTTP/1.1", host: "somehost.example.com"

On 1.10.x it will work fine and the contents of /tmp/nginx/index.html is returned to the client. Also if I change try_files to try_files $uri $uri/ @fallback; it will work fine in both versions.

Attached are debug logs for both 1.10.1 and 1.11.4.

Is this intentional change of behavior or a bug? Also if it's intentional, it would be helpful if changes like this were mentioned in the Changelog. Thanks and happy to provide more information if needed.

[Pyry Hakulinen]

Our builds have lua (and other custom modules), but the internal redirect loop also happens with vanilla builds.

[Ruslan Ermilov <ru@…>]

In 6832:ec10ce307dc0/nginx:

Map: the "volatile" parameter.

By default, "map" creates cacheable variables [1]. With this
parameter it creates a non-cacheable variable.

An original idea was to deduce the cacheability of the "map"
variable by checking the cacheability of variables specified
in source and resulting values, but it turned to be too hard.
For example, a cacheable variable can be overridden with the
"set" directive or with the SSI "set" command. Also, keeping
"map" variables cacheable by default is good for performance
reasons. This required adding a new parameter.

[1] Before db699978a33f (1.11.0), the cacheability of the
"map" variable could vary depending on the cacheability of
variables specified in resulting values (ticket #1090).
This is believed to be a bug rather than a feature.

[Maxim Dounin]

Closing this. The "volatile" parameter was introduced to facilitate configurations which need non-cacheable map{} results. See the commit log above for details.