Greetings!
I’m using Nginx for a new project, and am already very impressed by
the rate limiting features. Thank you!
However, there is one stakeholder who is insistent that abusers
(defined as those that are exceeding the set rate) be put into a 60
second timeout in which we display 503’s. It’s the 60 second part
that I’m having trouble with - is that possible with the current
feature set?
I was doing my testing with a rate setting of 5 req/s and a burst of
5. Obviously the 503’s appear after the burst has been depleted, but
they go away more or less immediately once the user begins behaving
properly.
All the Best,
Michael G.
On Tue, 2010-05-11 at 04:48 -0400, Michael G. wrote:
I’m using Nginx for a new project, and am already very impressed by
the rate limiting features. Thank you!
However, there is one stakeholder who is insistent that abusers
(defined as those that are exceeding the set rate) be put into a 60
second timeout in which we display 503’s. It’s the 60 second part
that I’m having trouble with - is that possible with the current
feature set?
You can use your packet filter to trap those who exceed certain
parameters and redirect incoming traffic from those qualified to
different port which nginx will also listen on and serve 503’s
there.
–
Miros³aw “Psyborg” Jaworski
GCS/IT d- s+:+ a C++$ UBI++++$ P+++$ L- E— W++(+++)$ N++ o+ K- w-- O-
M- V- PS+ PE++ Y+ PGP t 5? X+ R++ !tv b++(+++) DI++ D+ G e* h++ r+++ y?
“To err is human, to arrrr is pirate.”
You can use your packet filter to trap those who exceed certain
parameters and redirect incoming traffic from those qualified to
different port which nginx will also listen on and serve 503’s
there.
Thanks for the reply, Miroslaw! I think this is a good general work
around, but my app is a little more sensitive and requires different
rates for different url locations.
I do appreciate the idea, though. I think it would work for a lot of
cases.
All the Best,
Michael