Hi! Put the throttle settings on HTTP headers and let the downside to decide it is so feasible that tough to control. I think configuring through configuration is better.
On November 15, 2021 at 16:52:14, 钱勇 ([email protected]) wrote: Hi Community, Currently, we have a useful limit-count plugin, which can realize "Limit request rate by a fixed number of requests in a given time window". Can we consider going further, allowing limit and window to be configured more flexibly? Imagine the following business scenario: The user ID (maybe from the HTTP header) is used as the key to limit request count, and the limit of the number of requests for different users can be dynamically set according to the instructions returned by the upstream (from the HTTP response header of the upstream), so that different limit can be specified for each user. In order to achieve the above features, I carefully read the current limit-count code, and currently consider implementing it according to the following changes: 1. Add the following configuration to the limit-count plugin: { type = "object", properties = { dynamic_limit_enable = {type = "boolean", default = false}, dynamic_limit_count_header = { type = "string", default = "X-RateLimit-Set-Limit", }, dynamic_limit_window_header = { type = "string", default = "X-RateLimit-Set-Window", } } } 2. This is the workflow I envision now, because the text description is more complicated, I use a flowchart instead: 3. As a supplement, send the "X-RateLimit-Limit" and "X-RateLimit-Remaining" header corresponding to the current key to upstream, so that upstream can combine the current limit state to implement business logic. The above are my current ideas. As a newcomer to the community, I look forward to your guidance and suggestions. Thank you very much. Best regards, Nic <https://github.com/nic-6443>
