Emit RFC 9429-compliant rate limit headers

[atkrad]

The problem I'm facing

Tyk currently sends rate limit information using the legacy X-RateLimit-Limit, X-RateLimit-Remaining, and X-RateLimit-Reset headers. These use the old X- prefix convention and are not compliant with the now-published IETF standard for rate limit headers. As a client following the standard, I cannot rely on Tyk's current headers.

The solution I'd like

Tyk should emit the standardized headers defined in RFC 9429 ("RateLimit Header Fields for HTTP", IETF httpapi WG, August 2023):

RateLimit-Limit: 1000
RateLimit-Remaining: 42
RateLimit-Reset: 3600
RateLimit-Policy: 1000;w=86400

Key differences from the current implementation:

• No X- prefix.
• RateLimit-Reset is a delay in seconds (not a Unix timestamp).
• RateLimit-Policy is a new field describing the quota window and policy.

For backward compatibility, the existing X-RateLimit-* headers could be kept alongside the new ones during a transition period, or made opt-in/opt-out via API definition configuration.

Alternatives I've considered

• Keeping only the existing X-RateLimit-* headers maintains backward compatibility but leaves Tyk non-compliant with the published standard.
• Emitting both sets of headers simultaneously is the safest migration path, as existing integrations continue to work while new clients can adopt the RFC 9429 headers.

Additional context

• RFC 9429 - RateLimit Header Fields for HTTP (published August 2023)
• IETF httpapi WG living draft
• The data needed for all RFC 9429 headers is already computed internally by Tyk; this is primarily a matter of exposing it under the standardized header names.

[probelabs]

Thank You & Initial Triage

Hi @atkrad, thank you for this excellent and well-researched feature request. Aligning with modern standards like RFC 9429 for rate limiting headers is a valuable enhancement for Tyk, and we appreciate you taking the time to outline the requirements so clearly.

• Category: Enhancement
• Priority: Medium
• Complexity: Moderate

Analysis

Your understanding is spot on. Tyk currently uses the legacy X-RateLimit-* headers. Our investigation confirms that the data required for the new RateLimit-Limit, RateLimit-Remaining, and RateLimit-Reset headers is readily available where the existing headers are set.

The core logic for this is located in the rateLimitSender.SendRateLimits function in tyk/internal/rate/headers.go. The rate.Stats object passed to this function contains all the necessary information:

• stats.Limit can be used for RateLimit-Limit.
• stats.Remaining can be used for RateLimit-Remaining.
• stats.Reset is a time.Duration that can be directly converted to seconds for the RateLimit-Reset header, as the RFC requires.

Implementation Considerations

The main challenge, as you alluded to, is gathering the data for the new RateLimit-Policy header. This header requires the original quota and window (per value) from the API's configuration. This configuration is defined in the APIDefinition struct but is not directly available in the SendRateLimits function where the headers are written.

To implement this, we would likely need to:

1. Plumb the rate and per values from the API definition through the call stack, starting from the rate-limiting middleware (mw_api_rate_limit.go), through the session limiter (session_manager.go), and finally to the header sender (headers.go).
2. This would involve modifying the function signatures in this call chain to pass the additional configuration data.
3. Introduce a new configuration setting in the API definition to control the behavior, as you suggested. A field like api_definition.proxy.rate_limit_headers_mode with options (legacy, rfc9429, both) would provide the necessary flexibility for backward compatibility.

This makes the task moderately complex, as it touches several components in the request processing path, but it is certainly feasible.

Thanks again for the great suggestion. We'll add this to our backlog for consideration.

References

• tyk/internal/rate/headers.go – Where the current X-RateLimit-* headers are set.
• tyk/gateway/mw_api_rate_limit.go – The middleware that initiates the per-API rate limit check.
• tyk/gateway/session_manager.go – The session limiter that orchestrates the check and calls the header sender.
• tyk/apidef/api_definitions.go – Contains the GlobalRateLimit struct where the rate and per values are configured.

---

Powered by Visor from Probelabs

💡 TIP: You can chat with Visor using /visor ask <your question>