I suggest doing it inside the configuration instead of via upstream. It
will make life easier without complex internal states.

钱勇 <[email protected]> 于2021年11月15日周一 下午6:40写道:

> If the image of the flowchart cannot be load normally, you can use this
> link:
> https://user-images.githubusercontent.com/22141303/141767163-1e61abe0-b892-4b52-90a6-ef1824e2f04c.png
>
> Best regards,
> Nic <https://github.com/nic-6443 <https://github.com/bisakhmondal>>
>
> On Mon, Nov 15, 2021 at 4:51 PM 钱勇 <[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:
>>
>> [image: image.png]
>>
>> 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 <https://github.com/bisakhmondal>>
>>
>

Reply via email to