Patch proposal: allow alternatives to 503 status code in limit_req module

[Nick Marden]

On Sun, Mar 3, 2013 at 7:00 AM, <nginx-devel-request at nginx.org> wrote:

> Message: 1
> Date: Sun, 3 Mar 2013 03:14:12 +0400
> From: Maxim Dounin <mdounin at mdounin.ru>
> To: nginx-devel at nginx.org
> Subject: Re: Patch proposal: allow alternatives to 503 status code in
>         limit_req module
> Message-ID: <20130302231412.GD15378 at mdounin.ru>
> Content-Type: text/plain; charset=us-ascii
>
> Hello!
>
> On Fri, Mar 01, 2013 at 09:23:08PM -0500, Nick Marden wrote:
>
> > Hey there,
> >
> > I've been doing some work using limit_req to prevent overzealous clients
> > from DOS'ing my site. Specifically, I wanted to use a different HTTP
> status
> > code such as 420 or 429 so that it would be straightforward to show a
> "hey
> > man, chill out" page rather than my generic 503 error page.
> >
> > Attached is a patch that enables this option for the limit_req directive.
> > It still defaults to 503, but you can set it to any 4xx or 5xx value of
> > your choosing by specifying
> >
> > limit_req zone=foo burst=10 status_code=420;
> >
> > for example.
>
> I don't think this should be per-limit settings, for the following
> reasons in no particular order:
>
> - This makes things complicated in case of multiple limits used.
>   Current concept is to pass a request if it satisfies all limits
>   configured.  If at least one limit reached - request is rejected
>   (and nothing else happens).  With such aproach limit check order
>   isn't significant.  Introducing per-limit status code will make
>   check order significant.
>
> - There is no way to easily set default code server-wide.
>
> I think it should be separate directive to set status, something
> like
>
>     limit_req_status 429;
>
> Additionally, there should be limit_conn counterpart,
>
>     limit_conn_status 429;
>

I understand what you are saying and have made the corresponding changes to
my patch (attached).


> > I hope I've sent this to the right place. Please let me know where else
> to
> > send it if I'm in the wrong place.
>
> It's the right place.
>

Thanks. Please let me know if there is anything else I can do to help get
this patch onto trunk.

Cheers,

-- 
Nick Marden
nick at marden.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-devel/attachments/20130305/46faa003/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: alternative_limit_status_codes.patch
Type: application/octet-stream
Size: 4319 bytes
Desc: not available
URL: <http://mailman.nginx.org/pipermail/nginx-devel/attachments/20130305/46faa003/attachment.obj>