Not with 204.
This works quite well with a partner that has an aversion to errors when
they run over the limit:
limit_req_status 204;

On Wed, Jan 11, 2023 at 12:22 PM Maxim Dounin <mdounin@mdounin.ru> wrote:

> Hello!
>
> On Mon, Jan 09, 2023 at 09:44:52AM -0800, Christopher Liebman wrote:
>
> > # HG changeset patch
> > # User Christopher B. Liebman <liebman@zod.com>
> > # Date 1672855906 28800
> > # Wed Jan 04 10:11:46 2023 -0800
> > # Node ID e438fab51202365305cace94aa25937081b051d0
> > # Parent 07b0bee87f32be91a33210bc06973e07c4c1dac9
> > limit_req_status: allow status response to be as low as 200
> >
> > No need to limit this to 400+ and it's handy to be able to return
> > a non-error for for this.
> >
> > diff -r 07b0bee87f32 -r e438fab51202
> > src/http/modules/ngx_http_limit_req_module.c
> > --- a/src/http/modules/ngx_http_limit_req_module.c Wed Dec 21 14:53:27
> 2022
> > +0300
> > +++ b/src/http/modules/ngx_http_limit_req_module.c Wed Jan 04 10:11:46
> 2023
> > -0800
> > @@ -97,7 +97,7 @@
> >
> >
> > static ngx_conf_num_bounds_t ngx_http_limit_req_status_bounds = {
> > - ngx_conf_check_num_bounds, 400, 599
> > + ngx_conf_check_num_bounds, 200, 599
> > };
>
> Thank you for the patch.
>
> Unfortunately, removing limitation is not going to work, since
> returning non-error status codes also requires sending an actual
> response.
>
> The good part is that you can easily return any responses by using
> an error status and configuring appropriate error_page, see
> http://nginx.org/r/error_page for details.
>
> --
> Maxim Dounin
> http://mdounin.ru/
> _______________________________________________
> nginx-devel mailing list
> nginx-devel@nginx.org
> https://mailman.nginx.org/mailman/listinfo/nginx-devel
>
_______________________________________________
nginx-devel mailing list
nginx-devel@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-devel