You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apisix.apache.org by 钱勇 <qi...@api7.ai> on 2021/11/15 08:51:15 UTC
[Proposal] Support dynamic limit config for limit-count plugin
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>>
Re: [Proposal] Support dynamic limit config for limit-count plugin
Posted by Zexuan Luo <sp...@apache.org>.
I suggest doing it inside the configuration instead of via upstream. It
will make life easier without complex internal states.
钱勇 <qi...@api7.ai> 于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 钱勇 <qi...@api7.ai> 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>>
>>
>
Re: [Proposal] Support dynamic limit config for limit-count plugin
Posted by 钱勇 <qi...@api7.ai>.
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 钱勇 <qi...@api7.ai> 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>>
>
Re: [Proposal] Support dynamic limit config for limit-count plugin
Posted by Chao Zhang <to...@apache.org>.
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, 钱勇 (qianyong@api7.ai) 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>