Description:
When either the global (envoy.filters.http.ratelimit) or local (envoy.filters.http.local_ratelimit) rate limit filter enforces a limit, it emits a 429 and optionally the IETF draft-03 header triple (x-ratelimit-limit, x-ratelimit-remaining, x-ratelimit-reset) if enable_x_ratelimit_headers: DRAFT_VERSION_03 is configured. However, neither filter emits Retry-After on 429 responses.
Retry-After on 429 is specified by RFC 6585 section 4, with the field format defined by RFC 9110 section 10.2.3 as an HTTP-date or delay-seconds integer. Both filter paths already compute the reset value needed to populate it. Only the emission is missing.
The existing response_headers_to_add field on both filter protos does not satisfy this: it accepts only static values and cannot express a value derived dynamically from rate limit state at request time.
Desired behaviour: add an opt-in flag to both filter protos — mirroring enable_x_ratelimit_headers — that causes the filter to emit Retry-After: <delay-seconds> on 429 responses only, with the value sourced dynamically from the most-restrictive matched rule's seconds-until-reset, clamped to ≥1.
Relevant Links:
Description:
When either the global (
envoy.filters.http.ratelimit) or local (envoy.filters.http.local_ratelimit) rate limit filter enforces a limit, it emits a 429 and optionally the IETF draft-03 header triple (x-ratelimit-limit,x-ratelimit-remaining,x-ratelimit-reset) ifenable_x_ratelimit_headers: DRAFT_VERSION_03is configured. However, neither filter emitsRetry-Afteron 429 responses.Retry-Afteron 429 is specified by RFC 6585 section 4, with the field format defined by RFC 9110 section 10.2.3 as an HTTP-date or delay-seconds integer. Both filter paths already compute the reset value needed to populate it. Only the emission is missing.The existing
response_headers_to_addfield on both filter protos does not satisfy this: it accepts only static values and cannot express a value derived dynamically from rate limit state at request time.Desired behaviour: add an opt-in flag to both filter protos — mirroring
enable_x_ratelimit_headers— that causes the filter to emitRetry-After: <delay-seconds>on 429 responses only, with the value sourced dynamically from the most-restrictive matched rule's seconds-until-reset, clamped to ≥1.Relevant Links:
Retry-After): https://www.rfc-editor.org/rfc/rfc9110#section-10.2.3Retry-After): https://www.rfc-editor.org/rfc/rfc6585#section-4x-ratelimit-*headers proposal, 2021): Proposal: add support for x-ratelimit-* headers #12356BackendTrafficPolicy: emitRetry-Afterheader on rate-limit 429 responses gateway#9078