On Sun, Mar 3, 2013 at 7:00 AM, <nginx-devel-requ...@nginx.org> wrote:
> Message: 1 > Date: Sun, 3 Mar 2013 03:14:12 +0400 > From: Maxim Dounin <mdou...@mdounin.ru> > To: nginx-devel@nginx.org > Subject: Re: Patch proposal: allow alternatives to 503 status code in > limit_req module > Message-ID: <20130302231412.gd15...@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 n...@marden.org
alternative_limit_status_codes.patch
Description: Binary data
_______________________________________________ nginx-devel mailing list nginx-devel@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-devel
