You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Fiber version
v 2.20+ (Limiter Middleware Commit #1542 )
Issue description
Since the new attributes for skip options were implemented the limiter does not work as expected anymore.
When I don't set any of the two new attributes the request will be forwarded to the upstream server even in case if this request will hit the limit. Therefore I end up with executing a successful request and returning a 429 (since after this request's execution the limiter notices that the limit was hit/overdone).
The solution would be
(1):
Don't forward the request when both of the attributes are set to false.
(2):
Don't return 429 on requests which were in fact executed successfully on the upstream (this affects the lastest request which is executed before the limit was hit (or overdone with the new implementation)). This will hide the actual statuscode.
The text was updated successfully, but these errors were encountered:
Thanks for opening your first issue here! 馃帀 Be sure to follow the issue template! If you need help or want to chat with us, join us on Discord https://gofiber.io/discord
Hi, I tried to solve it with this pr #1568.
This solution
1- doesn't forward the request before the limit reached calculations.
2- doesn't returns 429 on successful requests and doesn't overwrite the actual statuscode.
But there is a problem that I can't solve. I need some help.
When remaining number is 1 and next request should be skipped, this code will return 429 because it can't see the actual status code before checking limit reached.
Fiber version
v 2.20+ (Limiter Middleware Commit #1542 )
Issue description
Since the new attributes for skip options were implemented the limiter does not work as expected anymore.
When I don't set any of the two new attributes the request will be forwarded to the upstream server even in case if this request will hit the limit. Therefore I end up with executing a successful request and returning a 429 (since after this request's execution the limiter notices that the limit was hit/overdone).
The solution would be
(1):
Don't forward the request when both of the attributes are set to false.
(2):
Don't return 429 on requests which were in fact executed successfully on the upstream (this affects the lastest request which is executed before the limit was hit (or overdone with the new implementation)). This will hide the actual statuscode.
The text was updated successfully, but these errors were encountered: