Skip to content

fix(middleware): set rate limit headers on memory store#2985

Open
leno23 wants to merge 1 commit into
labstack:v4from
leno23:fix/rate-limiter-response-headers
Open

fix(middleware): set rate limit headers on memory store#2985
leno23 wants to merge 1 commit into
labstack:v4from
leno23:fix/rate-limiter-response-headers

Conversation

@leno23
Copy link
Copy Markdown

@leno23 leno23 commented May 25, 2026

Summary

Fixes #2961

Rate limit middleware now sets standard rate limit response headers when using the built-in RateLimiterMemoryStore:

  • X-RateLimit-Limit — configured burst
  • X-RateLimit-Remaining — tokens remaining after the request
  • Retry-After — seconds until the next token is available (on 429 only)

Implementation follows the maintainer suggestion from the issue: an optional unexported rateLimiterStoreContext interface with AllowContext(c echo.Context, identifier string) (bool, error). When the configured store implements it, the middleware calls it instead of Allow. Custom stores can opt in without breaking the existing RateLimiterStore API.

Retry-After is computed via rate.Limiter.ReserveN(...).Delay() as suggested in the issue discussion.

Test plan

  • go test ./middleware -run TestRateLimiter
  • go test -race ./middleware -run TestRateLimiterMemoryStore
  • New test TestRateLimiterMemoryStore_AllowContext_SetsHeaders verifies headers on allowed and denied requests

Add optional rateLimiterStoreContext interface so stores can set
X-RateLimit-Limit, X-RateLimit-Remaining, and Retry-After headers.
RateLimiterMemoryStore implements it using golang.org/x/time/rate.

Fixes labstack#2961

Co-authored-by: Cursor <cursoragent@cursor.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant