-
-
Notifications
You must be signed in to change notification settings - Fork 37
Description
Description
I think we should remove the resetExpiryOnChange option (essentially, the window resets on every request, but the hit count doesn't).
For starters, I don't think we have a good way to convey the behavior in any of the standardized header formats.
Additionally it feels a little confusing to me, as it creates an odd incentive: instead of a slow, steady rate of requests, when the option is enabled end users get the most out of the server by hammering it with the max number of requests all at once, and then waiting for the window to reset, then doing it again. I don't see why any server operator would want to encourage that pattern of behavior.
I suppose that could make sense if the limit is 1 - but in that case, it should probably have a bigger window from the start rather than a window that grows over time.
I know that as an end user, a server behaving like this would just feel punitive and annoying, especially if it wasn't clear why the reset time kept changing.
Why
Simplify the codebase and documentation. Remove a footgun.
Alternatives
Leave it, or keep it but remove the documentation.