Problem of location matching with a given request

[samilko.ka@…]

Hi, guys. I've got a problem with location request and regexp, 'cause the nginx is not finding match like it describes here: ​https://nginx.ru/en/docs/http/ngx_http_core_module.html#location

My request is:

​http://localhost:8080/catalog/css/asdftail

My conf is:

server {
    listen 8080;

    location ~ ^/catalog/(js|css|i)/(.*)$
    {
            return 405;
    }
    location / {
            location ~ ^.+tail$ {
                    return 403;
            }
            return 402;
    }
}

My problem is:
With my request, my conf must return me 405 error, but it return me 403 error, 'cause nginx starts to check regexp location from "the location with the longest matching prefix is selected and remembered.", not from top of config - "Then regular expressions are checked, in the order of their appearance in the configuration file."

If my conf likes this:

server {
    listen 8080;

    location ~ ^/catalog/(js|css|i)/(.*)$
    {
            return 405;
    }
    
    location ~ ^.+tail$ {
            return 403;
    }

    location / {

            return 402;
    }
}

or this:

server {
    listen 8080;

    location catalog/ {
        location ~ ^/catalog/(js|css|i)/(.*)$
        {
                return 405;
        }
    }
    location / {
            location ~ ^.+tail$ {
                    return 403;
            }
            return 402;
    }
}

Then all works like in manual.

[Maxim Dounin]

Location matching procedure as described in the documentation describes matching without nested locations, hence the confusion.

If there are nested locations, the same procedure is additionally applied within a location with longest prefix, location / in your config. That is, nginx will search for longest matching prefix location within location /, and then it'll check for the first matching regular expression within location /. The latter will match location ~ ^.+tail$. Matching will stop here, as we've already found a regular expression match, and regular expressions on previous levels won't be checked.

In other words, regular expressions within prefix locations have higher priority than global ones, making it possible to do more specific processing, for example:

location ~ \.php$ {
    fastcgi_pass global_backend;
    ...
}

location /foo/ {
    ...

    location ~ \.php$ {
        fastcgi_pass foo_backend;
        ...
    }
}

Summing up the above, the behaviour you are seeing is not a bug, location matching works as designed. On the other hand, we might want to improve the documentation to better describe how matching works if there are nested locations.