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;
};

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