A question has come up concerning how rate limiting might function, or what is best practice if I'd like to rate limit on the following example.

Problem = I would like to rate limit all junction requests through URL - https://test.rate.org/ - with a capacity of 10, in a 60 second interval.
     I would also like to rate limit junction requests for URL - http://test.rate.org/junction1 - with a stricter capacity of 5, in a 30 second interval.
     Thirdly, I would also like to rate limit junction requests for URL - http://test.rate.org/junction2 - with an even stricter capacity of 2, in a 10 second interval.

Would this be achieved by implementing 3 rate limiting config/YAML files? Or can multiple URLs, methods, and intervals/capacities be placed in a sole rate limiting config?

Secondly, when a request is parsed for rate limiting, I'm figuring it's going to wind up in a bucket for the first rule/pattern it matches. So would I list these rules above from least-strict to most-strict to be able to achieve this functionality? 

I'm just curious what best practice would be here. 

Thanks and regards,
Bayless Rutherford

A question has come up concerning how rate limiting might function, or what is best practice if I'd like to rate limit on the following example.

Problem = I would like to rate limit all junction requests through URL - https://test.rate.org/ - with a capacity of 10, in a 60 second interval.
     I would also like to rate limit junction requests for URL - http://test.rate.org/junction1 - with a stricter capacity of 5, in a 30 second interval.
     Thirdly, I would also like to rate limit junction requests for URL - http://test.rate.org/junction2 - with an even stricter capacity of 2, in a 10 second interval.

Would this be achieved by implementing 3 rate limiting config/YAML files? Or can multiple URLs, methods, and intervals/capacities be placed in a sole rate limiting config?

Secondly, when a request is parsed for rate limiting, I'm figuring it's going to wind up in a bucket for the first rule/pattern it matches. So would I list these rules above from least-strict to most-strict to be able to achieve this functionality? 

I'm just curious what best practice would be here. 

Thanks and regards,
Bayless Rutherford

Hello,

In regards to this, it is possible to have stricter rate limiting on more specific junctions.

using the example above, you could set a policy on https://test.rate.org/junction1 for 100 requests per minute.

Then you can also have a policy on https://test.rate.org/junction1/junction2 that is stricter (50 requests per minute).

In our case we want to have the more general junction (/junction1) to be stricter than the specific url (/junction1/junction2). Is this possible?

We are using wildcards within the policy and would like to have an option within the policy yaml file to exclude one but match all the rest.

So similar, to the original post, but instead of getting stricter on more specific junctions, we want the rate limiting to be more lenient on a specific junction.

A question has come up concerning how rate limiting might function, or what is best practice if I'd like to rate limit on the following example.

Problem = I would like to rate limit all junction requests through URL - https://test.rate.org/ - with a capacity of 10, in a 60 second interval.
     I would also like to rate limit junction requests for URL - http://test.rate.org/junction1 - with a stricter capacity of 5, in a 30 second interval.
     Thirdly, I would also like to rate limit junction requests for URL - http://test.rate.org/junction2 - with an even stricter capacity of 2, in a 10 second interval.

Would this be achieved by implementing 3 rate limiting config/YAML files? Or can multiple URLs, methods, and intervals/capacities be placed in a sole rate limiting config?

Secondly, when a request is parsed for rate limiting, I'm figuring it's going to wind up in a bucket for the first rule/pattern it matches. So would I list these rules above from least-strict to most-strict to be able to achieve this functionality? 

I'm just curious what best practice would be here. 

Thanks and regards,
Bayless Rutherford

Jerry,

WebSEAL will apply the request against all matching rate limiting policies.  This means that if you have a policy on https://test.rate.org/junction1, and another policy for https://test.rate.org/junction1/junction2, any requests for a resource like: 'https://test.rate.org/junction1/junction2/index.html', will have a bucket in both rate limiting policies.   There is no way to tell WebSEAL to ignore a rate limiting policy for certain requests. 

I hope that this helps.

Scott.

Hello,

In regards to this, it is possible to have stricter rate limiting on more specific junctions.

using the example above, you could set a policy on https://test.rate.org/junction1 for 100 requests per minute.

Then you can also have a policy on https://test.rate.org/junction1/junction2 that is stricter (50 requests per minute).

In our case we want to have the more general junction (/junction1) to be stricter than the specific url (/junction1/junction2). Is this possible?

We are using wildcards within the policy and would like to have an option within the policy yaml file to exclude one but match all the rest.

So similar, to the original post, but instead of getting stricter on more specific junctions, we want the rate limiting to be more lenient on a specific junction.

A question has come up concerning how rate limiting might function, or what is best practice if I'd like to rate limit on the following example.

Problem = I would like to rate limit all junction requests through URL - https://test.rate.org/ - with a capacity of 10, in a 60 second interval.
     I would also like to rate limit junction requests for URL - http://test.rate.org/junction1 - with a stricter capacity of 5, in a 30 second interval.
     Thirdly, I would also like to rate limit junction requests for URL - http://test.rate.org/junction2 - with an even stricter capacity of 2, in a 10 second interval.

Would this be achieved by implementing 3 rate limiting config/YAML files? Or can multiple URLs, methods, and intervals/capacities be placed in a sole rate limiting config?

Secondly, when a request is parsed for rate limiting, I'm figuring it's going to wind up in a bucket for the first rule/pattern it matches. So would I list these rules above from least-strict to most-strict to be able to achieve this functionality? 

I'm just curious what best practice would be here. 

Thanks and regards,
Bayless Rutherford

Hi all,

Is this still the situation in IVIA 11.0.0.0?
And if so, is there another way to achieve this within IVIA?

Jerry,

WebSEAL will apply the request against all matching rate limiting policies.  This means that if you have a policy on https://test.rate.org/junction1, and another policy for https://test.rate.org/junction1/junction2, any requests for a resource like: 'https://test.rate.org/junction1/junction2/index.html', will have a bucket in both rate limiting policies.   There is no way to tell WebSEAL to ignore a rate limiting policy for certain requests. 

I hope that this helps.

Scott.

Hello,

In regards to this, it is possible to have stricter rate limiting on more specific junctions.

using the example above, you could set a policy on https://test.rate.org/junction1 for 100 requests per minute.

Then you can also have a policy on https://test.rate.org/junction1/junction2 that is stricter (50 requests per minute).

In our case we want to have the more general junction (/junction1) to be stricter than the specific url (/junction1/junction2). Is this possible?

We are using wildcards within the policy and would like to have an option within the policy yaml file to exclude one but match all the rest.

So similar, to the original post, but instead of getting stricter on more specific junctions, we want the rate limiting to be more lenient on a specific junction.

A question has come up concerning how rate limiting might function, or what is best practice if I'd like to rate limit on the following example.

Problem = I would like to rate limit all junction requests through URL - https://test.rate.org/ - with a capacity of 10, in a 60 second interval.
     I would also like to rate limit junction requests for URL - http://test.rate.org/junction1 - with a stricter capacity of 5, in a 30 second interval.
     Thirdly, I would also like to rate limit junction requests for URL - http://test.rate.org/junction2 - with an even stricter capacity of 2, in a 10 second interval.

Would this be achieved by implementing 3 rate limiting config/YAML files? Or can multiple URLs, methods, and intervals/capacities be placed in a sole rate limiting config?

Secondly, when a request is parsed for rate limiting, I'm figuring it's going to wind up in a bucket for the first rule/pattern it matches. So would I list these rules above from least-strict to most-strict to be able to achieve this functionality? 

I'm just curious what best practice would be here. 

Thanks and regards,
Bayless Rutherford