confused about FixedWindowElasticExpiryRateLimiter

[craynic]

I have such test code:

storage = storage_from_string('memory://')
limiter = limits.strategies.FixedWindowElasticExpiryRateLimiter(storage)
rate = limits.parse('2/6second')
while 1:
 print(limiter.hit(rate, '111'))
 time.sleep(5)

and I got

True True False False False

My actual rate is 1/5second, lower than limit 2/6second, but I got failed to submit. There are no 3 hits in any continuous 6 seconds. If it's by design, hope it to be documented in the strategies.

[m-aciek]

This is the current example in documentation:

For example, if you specify a 100/minute rate limit on a route and it is being attacked at the rate of 5 hits per second for 2 minutes - the attacker will be locked out of the resource for an extra 60 seconds after the last hit. This strategy helps circumvent bursts.

I think we should add a sentence here similar to:

This strategy requires whole window time without any request to reset the counter. If the requests continue at least 1 in a window time, the expiry window will be continuously being extended.

Is it possible to correct this strategy to make a penalty at most of two window times?

[alisaifee]

The original design behind the FixedWindowElasticExpiryRateLimiter wasn't well thought through at all and I'm actually surprised it's in use. I'd be happy to take a pull request that improves it and makes it more useful - however, considering it's been the same since version 1.0 - we'd have to be careful to make changes in behavior opt in (in the off chance someone is using it the way it is :sweat_smile: )

[alisaifee]

Closing due to inactivity