#2138 Introduce ASP.NET rate limiting #2188

yjorayev · 2024-11-06T07:27:19Z

Closes #2138

When will ASP.NET Core Implementation of Rate Limiter start? #2138

Discussion thread

When will ASP.NET Core Implementation of Rate Limiter start? #2138 (comment)

Proposed Changes

Includes changes to use .Net middleware
Middleware type for rate limiting can be specified in ocelot.json. It defaults to Ocelot's existing rate limiter if not specified
Also added some Unit Tests, Integration test and a sample

Documentation block

RST sources: Rate Limiting | Future and ASP.NET Implementation
Html docs: Rate Limiting | Future and ASP.NET Implementation

Predecessor

#585 #1229 #1598 #1915 Rate limiting global configuration #2294
We need to merge this PR first due to the agreement on the JSON schema, which includes global configuration and specific Metadata options.

raman-m

Thanks for PR creation!

Please move current test/Ocelot.IntegrationTests/RateLimitingTests to Ocelot.AcceptanceTests project, we already have a suitable class: ClientRateLimitingTests. However, these tests only cover the Ocelot feature "Rate Limit by Client's Header." Since you are proposing a new feature, a new testing class should be created.

P.S. I recommend (and require) inheriting from Steps, which offers many useful testing helpers, so there's no need to reinvent the wheel.

test/Ocelot.IntegrationTests/RateLimitingTests.cs

raman-m · 2024-11-06T11:54:52Z

Yhlas, thank you once again. Here's the current status: I will request an official code review after transitioning tests to acceptance testing. Please remember to draft the preliminary docs.

Regarding the delivery vision, I cannot include it in the current Autumn'24 milestone due to anticipated multiple development rounds. Post-release, our team intends to upgrade Ocelot to .NET 9. It appears your feature may be incorporated into the release alongside this upgrade. Therefore, I suggest testing the PR code with the current .NET 9 RC. Is that okay? Consequently, we will target two frameworks in the project files: net8.0 and net9.0

yjorayev · 2024-11-07T06:36:08Z

... I suggest testing the PR code with the current .NET 9 RC. Is that okay? Consequently, we will target two frameworks in the project files: net8.0 and net9.0

I targeted Ocelot project and a sample to net 9.0-rc. No issue on manual testing.

I will start working on docs for this in a few days. Thanks!

raman-m

We can enhance the quality of the PR: my suggestions are outlined below 👇
FYI, I will revisit this PR once it has been reviewed by a team member as well.

P.S. Keep in mind Line-Ending Gotchas aka EOL Fun. I saw some files have fake changes because of changed line endings.

test/Ocelot.UnitTests/Configuration/Validation/RouteFluentValidatorTests.cs

samples/RateLimiter/Ocelot.Samples.RateLimiter.http

src/Ocelot/Configuration/File/FileRateLimitRule.cs

src/Ocelot/Configuration/RateLimitMiddlewareType.cs

src/Ocelot/DependencyInjection/Features.cs

src/Ocelot/DependencyInjection/OcelotBuilder.cs

src/Ocelot/Middleware/OcelotPipelineExtensions.cs

src/Ocelot/RateLimiting/Middleware/RateLimitingMiddleware.cs

test/Ocelot.AcceptanceTests/RateLimiting/RateLimitingTests.cs

ggnaegi · 2024-11-08T16:01:31Z

@raman-m That's a great idea, but we are stuck with the .NET rate limiters specs, you can't modify them on the fly, as you could with the current limiters. The rate limiters policies must be known, and therefore configured during startup

raman-m · 2024-11-09T09:44:42Z

but we are stuck with the .NET rate limiters specs, you can't modify them on the fly, as you could with the current limiters.

@ggnaegi, what is your suggestion?
Could you please clarify the problem for the author?
Why not conduct a separate code review yourself?

src/Ocelot/Configuration/RateLimitOptions.cs

raman-m · 2024-11-11T09:17:13Z

Unfortunately, merge conflicts have arisen due to the recent merging of PR #1307 and its commit da9d6fa into the develop branch. I recommend to perform rebasing.

@raman-m

…Context` response accessed via `IHttpContextAccessor` (ThreeMammals#1307) * set rate limiting headers on the proper httpcontext * fix Retry-After header * merge fix * refactor of ClientRateLimitTests * merge fix * Fix build after rebasing * EOL: test/Ocelot.AcceptanceTests/Steps.cs * Add `RateLimitingSteps` * code review by @raman-m * Inject IHttpContextAccessor, not IServiceProvider * Ocelot's rate-limiting headers have become legacy * Headers definition life hack * A good StackOverflow link --------- Co-authored-by: Jolanta Łukawska <jolanta.lukawska@outlook.com> Co-authored-by: Raman Maksimchuk <dotnet044@gmail.com>

Co-authored-by: Raman Maksimchuk <dotnet044@gmail.com>

raman-m · 2025-05-27T17:22:38Z

@yjorayev Hi Yhlas!
Do you have the enthusiasm proceed with development? Could you begin by addressing the merge conflicts, please?

If you have no objections, I would like to invite you to review the following PR →

#585 #1229 #1598 #1915 Rate limiting global configuration #2294
where we will address the issue of various types of limiters.

src/Ocelot/Configuration/Validator/RouteFluentValidator.cs

raman-m · 2025-08-13T15:44:48Z

Predecessor

#585 #1229 #1598 #1915 Rate limiting global configuration #2294

@yjorayev FYI
We need to merge this PR first due to the agreement on the JSON schema, which includes global configuration and specific Metadata options.

P.S. Could you fix all the merge conflicts by simply merging develop into the feature branch, please?

…ge conflicts

raman-m

Hi Yhlas!
Do you recall what you were doing a year ago? Do you plan to continue contributing further?

With the merge conflicts resolved and #2294 successfully integrated, it seems like the perfect time to move forward with development. Unfortunately, the acceptance test is currently failing.

raman-m · 2025-09-24T14:31:50Z

samples/RateLimiter/Program.cs

+builder.Services.AddRateLimiter(op =>
+{
+    op.AddFixedWindowLimiter(policyName: "fixed", options =>
+    {
+        options.PermitLimit = 2;
+        options.Window = TimeSpan.FromSeconds(12);
+        options.QueueProcessingOrder = QueueProcessingOrder.OldestFirst;
+        options.QueueLimit = 0;
+    });
+});


I disagree! In this case, we haven't proposed anything new.
I think we should provide the user with an option to choose between configuration approaches. We could consider having a separate Ocelot rate-limiting rule to manage app auto-configurations.

@raman-m it's basically what i mentioned:
Yes, that's the main concern; we essentially need to reinvent the wheel for the middleware part. I've tried to "dynamize" the policies myself, but I believe it’s not possible.
The policies are setup during startup, you can't modify them after that, and you can't mix them (as of 2024, maybe now it's possible).

We can't mix policies, but we can define as many as needed, right?
From your words, did you mean that the "fixed" policy is global in this code?

Yes, it's global and they can't be modified.

raman-m · 2025-09-24T14:36:26Z

src/Ocelot/Configuration/File/FileRateLimitRule.cs

+    /// <value>
+    /// A string of rate limit policy name.
+    /// </value>
+    public string Policy { get; set; }


You might want to consider removing this property and using FileRateLimitByAspNetRule.Policy instead.

raman-m · 2025-09-24T14:39:02Z

src/Ocelot/Configuration/Validator/RouteFluentValidator.cs

-        When(route => route.RateLimitOptions != null && route.RateLimitOptions.EnableRateLimiting != false, () =>
+        When(route => route.RateLimitOptions != null
+                && route.RateLimitOptions.EnableRateLimiting != false
+                && string.IsNullOrWhiteSpace(route.RateLimitOptions.Policy), () =>


We still need to validate the rule algorithm properties, even if the ASP.NET policy is in place.

raman-m · 2025-09-24T14:40:24Z

src/Ocelot/Configuration/RateLimitOptions.cs

            fromRule.Period.IfEmpty(RateLimitRule.DefaultPeriod),
            fromRule.PeriodTimespan.HasValue ? $"{fromRule.PeriodTimespan.Value}s" : fromRule.Wait,
            fromRule.Limit ?? RateLimitRule.ZeroLimit);
+        Policy = fromRule.Policy;


An option of a flawed rule 😄 Consider removing!

raman-m · 2025-09-24T14:41:25Z

src/Ocelot/Configuration/RateLimitOptions.cs

        QuotaMessage = fromOptions.QuotaMessage.IfEmpty(DefaultQuotaMessage);
        KeyPrefix = fromOptions.KeyPrefix.IfEmpty(DefaultCounterPrefix);
        Rule = fromOptions.Rule ?? RateLimitRule.Empty;
+        Policy = fromOptions.Policy;


It's fine because of the copy constructor ✔️

raman-m · 2025-09-24T14:53:27Z

src/Ocelot/DependencyInjection/Features.cs

+        var globalRateLimitOptions = configurationRoot.Get<FileConfiguration>()?.GlobalConfiguration?.RateLimitOptions;
+        var rejectStatusCode = globalRateLimitOptions?.HttpStatusCode ?? StatusCodes.Status429TooManyRequests;
+        var rejectedMessage = globalRateLimitOptions?.QuotaExceededMessage ?? "API calls quota exceeded!";


Merging in the wrong place can be risky.
We've assigned the IRateLimitOptionsCreator service specifically for merging options. Please refer to the RateLimitOptionsCreator class for details.

raman-m · 2025-09-24T14:56:18Z

src/Ocelot/DependencyInjection/Features.cs

+                rejectedContext.HttpContext.Response.StatusCode = rejectStatusCode;
+                await rejectedContext.HttpContext.Response.WriteAsync(rejectedMessage, token);


It's amusing that we implement the same approach in Ocelot's middleware. Perhaps adding a virtual method in the middleware to connect to the handler could work? 😉

raman-m · 2025-09-24T14:58:57Z

src/Ocelot/DependencyInjection/OcelotBuilder.cs

-
+        Services.AddRateLimiting(); // Feature: Rate Limiting
+#if NET7_0_OR_GREATER
+        Services.AddAspNetRateLimiting(configurationRoot); // Feature: AspNet Rate Limiting


I strongly believe we shouldn't introduce a new feature, whether public or internal. Since the method is already auto-enabled internally, it seems we can leave it as-is. However, we definitely need to review this design.

raman-m · 2025-09-24T15:01:39Z

src/Ocelot/RateLimiting/RateLimitingMiddlewareExtensions.cs

+
+public static class RateLimitingMiddlewareExtensions
+{
+    public static IApplicationBuilder UseRateLimiting(this IApplicationBuilder builder)


Great! It looks like the number of references is zero.

So, how are we supposed to use this extension method? Just mentioning in the documentation that users should call it?

raman-m · 2025-09-24T15:02:46Z

test/Ocelot.AcceptanceTests/RateLimiting/AspNetRateLimitingTests.cs

+
+    [Fact]
+    [Trait("Feat", "2138")]
+    public async Task Should_RateLimit()


Currently, this test fails ❗

raman-m · 2025-09-24T16:05:38Z

@ggnaegi commented on Nov 14, 2024

Yes, that's the main concern; we essentially need to reinvent the wheel for the middleware part. I've tried to "dynamize" the policies myself, but I believe it’s not possible.

We don't need to reinvent anything, just a useful JSON configuration.
ASP.NET middleware can be part of Ocelot pipeline at position before Ocelot's own middleware, here:

Ocelot/src/Ocelot/Middleware/OcelotPipelineExtensions.cs

Lines 77 to 80 in d5e6d9a

    
           app.UseMiddleware<DownstreamRequestInitialiserMiddleware>(); 
        
           // We check whether the request is ratelimit, and if there is no continue processing 
        
           app.UseMiddleware<RateLimitingMiddleware>();

Place it after DownstreamRequestInitialiserMiddleware but before RateLimitingMiddleware. Inheriting from the ASP.NET Core one might seem like a crazy idea, but it’s definitely possible!

However, at least we can retain Microsoft's RateLimiter implementations and replace the current ones.

Since we seem to agree on independent evolution, we should avoid replacing or combining anything. Instead, we need to design an effective embedded module using JSON configurations, supplemented by additional C# helpers if necessary.

…elimit'

raman-m assigned yjorayev Nov 6, 2024

raman-m added feature A new feature Rate Limiting Ocelot feature: Rate Limiting labels Nov 6, 2024

raman-m requested changes Nov 6, 2024

View reviewed changes

test/Ocelot.IntegrationTests/RateLimitingTests.cs Outdated Show resolved Hide resolved

raman-m changed the title ~~Users/yjorayev/dotnet ratelimit~~ Introduce ASP.NET rate limiting Nov 6, 2024

raman-m changed the title ~~Introduce ASP.NET rate limiting~~ #2138 Introduce ASP.NET rate limiting Nov 6, 2024

yjorayev requested a review from raman-m November 7, 2024 06:36

raman-m requested review from RaynaldM and ggnaegi November 8, 2024 10:32

raman-m requested changes Nov 8, 2024

View reviewed changes

raman-m reviewed Nov 9, 2024

View reviewed changes

src/Ocelot/Configuration/RateLimitOptions.cs Outdated Show resolved Hide resolved

raman-m added the conflicts Feature branch has merge conflicts label Nov 11, 2024

yjorayev and others added 11 commits November 12, 2024 23:56

draft implementation of .net rate limiter in ocelot

c7c4c6b

fixed tests

b6c1577

use rate limit status and message in dot net rate limiter

e6359cb

added integration test for dotnet rate limiter

39a4934

added RateLimiter sample

2833359

move rate limiting acceptance test to corresponding folder

852fac1

failed test on pipeline run

7dbb578

addressed PR comments

cd3075a

Update test/Ocelot.AcceptanceTests/RateLimiting/RateLimitingTests.cs

032e7f2

Co-authored-by: Raman Maksimchuk <dotnet044@gmail.com>

rename test file name to AspNetRateLimitingTests

e8987ad

yjorayev force-pushed the users/yjorayev/dotnet-ratelimit branch from 59ef966 to e8987ad Compare November 13, 2024 06:15

Merge branch 'develop' into users/yjorayev/dotnet-ratelimit

d5e3a44

raman-m force-pushed the develop branch 7 times, most recently from 908d84f to 0678e7a Compare April 19, 2025 15:13

raman-m added conflicts Feature branch has merge conflicts Winter'26 Winter 2026 release labels May 27, 2025

raman-m added this to the Summer'25 milestone May 27, 2025

RaynaldM reviewed May 29, 2025

View reviewed changes

src/Ocelot/Configuration/Validator/RouteFluentValidator.cs Outdated Show resolved Hide resolved

src/Ocelot/Configuration/Validator/RouteFluentValidator.cs Outdated Show resolved Hide resolved

This was linked to issues Aug 13, 2025

Global rate limiting for all, multiple routes instead of every route #1229

Closed

Apply rate limiting globally #1915

Closed

raman-m mentioned this pull request Aug 13, 2025

#585 #1229 #1598 #1915 Rate limiting global configuration #2294

Merged

raman-m added 3 commits September 24, 2025 15:51

Merge 'develop' into 'yjorayev:users/yjorayev/dotnet-ratelimit'

f6274bb

Incorporate the proposed code into the middleware after resolving mer…

2c01ab1

…ge conflicts

Propagate the Policy name option into the middleware

e5555ed

raman-m removed the conflicts Feature branch has merge conflicts label Sep 24, 2025

ThreeMammals deleted a comment from yjorayev Sep 24, 2025

raman-m requested changes Sep 24, 2025

View reviewed changes

raman-m self-assigned this Sep 24, 2025

raman-m added the conflicts Feature branch has merge conflicts label Dec 27, 2025

raman-m added 2 commits January 18, 2026 16:56

Merge 'ThreeMammals:develop' into 'yjorayev:users/yjorayev/dotnet-rat…

fce8f5b

…elimit'

Delete directive: #if NET7_0_OR_GREATER

be8d67b

raman-m removed the conflicts Feature branch has merge conflicts label Jan 18, 2026

		rejectedContext.HttpContext.Response.StatusCode = rejectStatusCode;
		await rejectedContext.HttpContext.Response.WriteAsync(rejectedMessage, token);

#2138 Introduce ASP.NET rate limiting #2188

Are you sure you want to change the base?

#2138 Introduce ASP.NET rate limiting #2188

Conversation

yjorayev commented Nov 6, 2024 • edited by raman-m Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Closes #2138

Discussion thread

Proposed Changes

Documentation block

Predecessor

Uh oh!

raman-m left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

raman-m commented Nov 6, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

yjorayev commented Nov 7, 2024

Uh oh!

raman-m left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

ggnaegi commented Nov 8, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

raman-m commented Nov 9, 2024

Uh oh!

Uh oh!

raman-m commented Nov 11, 2024

Uh oh!

raman-m commented May 27, 2025

Uh oh!

Uh oh!

Uh oh!

raman-m commented Aug 13, 2025

Predecessor

Uh oh!

raman-m left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ggnaegi Sep 25, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

yjorayev commented Nov 6, 2024 •

edited by raman-m

Loading

raman-m left a comment •

edited

Loading

raman-m commented Nov 6, 2024 •

edited

Loading

raman-m left a comment •

edited

Loading

ggnaegi commented Nov 8, 2024 •

edited

Loading

raman-m left a comment •

edited

Loading

ggnaegi Sep 25, 2025 •

edited

Loading