FixedWindowRateLimiter miscalculates `Retry-After` value

[aleksatoroman]

Description

When using the FixedWindowRateLimiter, the value set for the Retry-After header reflects the entire time window specified in the policy configuration rather than the remaining time until the next permissible request.

Reproduction Steps

1. Utilize the official example provided here. The relevant code snippet is:

_rateLimiterOptions.OnRejected = (context, token) =>
{
    if (context.Lease.TryGetMetadata(MetadataName.RetryAfter, out var retryAfter))
    {
        context.HttpContext.Response.Headers.RetryAfter =
            ((int) retryAfter.TotalSeconds).ToString(NumberFormatInfo.InvariantInfo);
    }

    return ValueTask.CompletedTask;
};

2.

Configure a Window option for, let's say, 00:01:00. After reaching the maximum request limit for this window, inspect the Retry-After header. A visual representation of the issue can be found

Expected behavior

The Retry-After header should reflect the remaining time until the next request is permissible, like some other implementations are doing, such as Redis-based rate limiting that is built on top of this one found here.

Actual behavior

The Retry-After header only reflects the static window value defined in the policy's configuration, ignoring the elapsed time.

Regression?

No response

Known Workarounds

No response

Configuration

No response

Other information

This RateLimiting middleware is used in combination with my YARP reverse proxy gateway based on the following documentation: YARP rate limiting

[ghost]

Tagging subscribers to this area: @mangod9 See info in area-owners.md if you want to be subscribed.

Issue Details

---

### Description When using the `FixedWindowRateLimiter`, the value set for the `Retry-After` header reflects the entire time window specified in the policy configuration rather than the remaining time until the next permissible request. ### Reproduction Steps 1. Utilize the official example provided [here](https://learn.microsoft.com/en-gb/aspnet/core/performance/rate-limit?view=aspnetcore-8.0). The relevant code snippet is: ```cs _rateLimiterOptions.OnRejected = (context, token) => { if (context.Lease.TryGetMetadata(MetadataName.RetryAfter, out var retryAfter)) { context.HttpContext.Response.Headers.RetryAfter = ((int) retryAfter.TotalSeconds).ToString(NumberFormatInfo.InvariantInfo); } return ValueTask.CompletedTask; }; ``` 2. Configure a `Window` option for, let's say, `00:01:00`. After reaching the maximum request limit for this window, inspect the Retry-After header. A visual representation of the issue can be found  ### Expected behavior The `Retry-After` header should reflect the remaining time until the next request is permissible, like some other implementations are doing, such as Redis-based rate limiting that is built on top of this one found [here](https://github.com/cristipufu/aspnetcore-redis-rate-limiting). ### Actual behavior The `Retry-After` header only reflects the static window value defined in the policy's configuration, ignoring the elapsed time. ### Regression? _No response_ ### Known Workarounds _No response_ ### Configuration _No response_ ### Other information This `RateLimiting` middleware is used in combination with my `YARP` reverse proxy gateway based on the following documentation: [YARP rate limiting](https://microsoft.github.io/reverse-proxy/articles/rate-limiting.html)

Author:	aleksatoroman
Assignees:	-
Labels:	`area-System.Threading`, `untriaged`
Milestone:	-

[mangod9]

@BrennanConroy