limit_req at server level gives 404 error for files rewritten at location level?

[Maxim Dounin]

Hello!

On Sun, Apr 26, 2020 at 09:59:03AM -0500, J.R. wrote:

> I skimmed over the ngx_http_limit_req_module.c and didn't see anything
> obvious in relation to file checking, but here's my scenario...
> 
> I have a location block that will re-write the requested 'versioned'
> file name to the actual common file name, so I can set some things
> immutable without having to deal with changing tons of physical files
> (only the HTML changes).
> 
> example (shortened for brevity):
> 
> # file.v1.gif = file.gif
> location ~* (.+)\.v\d+\.(gif|jpg|png)$ {
>    try_files $1.$2 $uri @proxy;
> }
> 
> When I had the following limit_req in my @proxy 'location' block,
> limiting worked fine.
> 
> location @proxy {
>   limit_req zone=reqlimit burst=24 delay=12;
>   proxy_pass http://backend;
> }
> 
> Obviously the above limit_req never interacted with the rewriting
> 'location' mentioned above (the @proxy at the end of try_files was
> just a fallback in case of errors).
> 
> However, when I moved the limit_req up to the 'server' level, I
> started getting 404 errors for all the image requests that were
> handled by the above mentioned rewriting location block. All other
> files were handled just fine.
> 
> Kind of scratching my head on this one.  Any thoughts Maxim?

Unfortunately, configuration shown is not enough to say anything 
for sure, but my best guess is as follows:

You are using "try_files $1.$2 ...", and your configuration 
expects that $1 and $2 variables are from the regular expression 
in the location.  This might not be true as long as there are any 
other regular expressions in the configuration.

In particular, if limit_req uses a map with regular expressions, 
this might result in $1.$2 to be set to something completely 
different from what was expected from the location matching.

The general rule is: avoid using positional captures from regular 
expressions in location and server_name matching, these can be 
used only in very simple configurations.

-- 
Maxim Dounin
http://mdounin.ru/