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

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

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

J.R.
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?

Thanks!
_______________________________________________
nginx mailing list
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx
Reply | Threaded
Open this post in threaded view
|

Re: 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/
_______________________________________________
nginx mailing list
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx
Reply | Threaded
Open this post in threaded view
|

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

J.R.
In reply to this post by J.R.
> 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.

You were right! I forgot I had a map matching /24 of the
$binary_subnet_addr that was being used by the limit_req_zone
directive.

I went through and gave names to my capture groups just to ensure this
type of conflict doesn't happen again.

Thanks again for your help!
_______________________________________________
nginx mailing list
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx