# When rate limiting is hit return return a Retry-After header
**URL:** https://meta.discourse.org/t/when-rate-limiting-is-hit-return-return-a-retry-after-header/81838
**Category:** Feature
**Tags:** pr-welcome
**Created:** [2월 28, 2018, 7:16오후 UTC](https://meta.discourse.org/t/when-rate-limiting-is-hit-return-return-a-retry-after-header/81838 "2018-02-28T19:16:58Z")
**Posts on this page:** 5
**Page:** 1
### Author:  [@jdevost](https://meta.discourse.org/u/jdevost)
#### Post date: [2월 28, 2018, 7:16오후 UTC](https://meta.discourse.org/t/when-rate-limiting-is-hit-return-return-a-retry-after-header/81838/1 "2018-02-28T19:16:58Z")
Hi,
Shouldn’t the delay to wait be in the Response as a Retry-After header?
> **[429 Too Many Requests - HTTP | MDN](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/429)**
>
> The HTTP 429 Too Many Requests client error response status code indicates the client has sent too many requests in a given amount of time.
> This mechanism of asking the client to slow down the rate of requests is commonly called "rate limiting".
---
### Author:  [@sam](https://meta.discourse.org/u/sam)
#### Post date: [2월 28, 2018, 7:27오후 UTC](https://meta.discourse.org/t/when-rate-limiting-is-hit-return-return-a-retry-after-header/81838/2 "2018-02-28T19:27:33Z")
Sure, sounds like a good suggestion
---
### Author:  [@xrav3nz](https://meta.discourse.org/u/xrav3nz)
#### Post date: [3월 8, 2018, 3:14오전 UTC](https://meta.discourse.org/t/when-rate-limiting-is-hit-return-return-a-retry-after-header/81838/3 "2018-03-08T03:14:15Z")
Taking a stab at this 😉
* * *
[https://github.com/discourse/discourse/pull/5659](https://github.com/discourse/discourse/pull/5659)
* * *
I am assuming:
`Retry-After` shouldn’t be set in controller actions like the following, where the retry time is (intentionally) hidden from the end user.
[https://github.com/xrav3nz/discourse/blob/60e5f39130ca1e4711400955969990fa283fa969/app/controllers/invites\_controller.rb#L151](https://github.com/xrav3nz/discourse/blob/60e5f39130ca1e4711400955969990fa283fa969/app/controllers/invites_controller.rb#L151)
---
### Author:  [@Mike\_Yermolayev](https://meta.discourse.org/u/Mike_Yermolayev)
#### Post date: [12월 1, 2020, 12:33오전 UTC](https://meta.discourse.org/t/when-rate-limiting-is-hit-return-return-a-retry-after-header/81838/4 "2020-12-01T00:33:51Z")
안녕하세요,
PR이 병합된 것 같지만, ‘Retry-After’ 헤더를 확인하지 못하겠습니다.
여기 제 오류의 본문이 있습니다:
그리고 여기 헤더가 있습니다:
이것이 버그인가요? 미리 감사드립니다.
---
### Author:  [@guidoleenders](https://meta.discourse.org/u/guidoleenders)
#### Post date: [7월 19, 2024, 1:34오후 UTC](https://meta.discourse.org/t/when-rate-limiting-is-hit-return-return-a-retry-after-header/81838/5 "2024-07-19T13:34:31Z")
좋은 제안입니다!
그동안 IETF에서는 호출 프로그램에 레이트 리미팅 정보를 전달하기 위한 헤더를 표준화했습니다. 관련 내용은 [https://www.ietf.org/archive/id/draft-polli-ratelimit-headers-02.html을](https://www.ietf.org/archive/id/draft-polli-ratelimit-headers-02.html%EC%9D%84) 참조하세요. 저희 소프트웨어는 다양한 레이트 리미터에 이 표준을 적용하고 있습니다([Fair Use Daily Limits for a Better User Experience - invantive](https://forums.invantive.com/t/fair-use-daily-limits-for-a-better-user-experience/3767) 참고).
저희의 경우, Discourse가 헤더를 통해 레이트 리미트 정보를 반환해 준다면 큰 도움이 될 것입니다. 호출 프로그램은 설정 파일에 접근할 수 없으며, 직접 문의하지 않는 한 레이트 리미트 정의가 정확히 무엇인지 알 수 없습니다. 또한 레이트 리미트에 근접한 상황에서 429 오류를 피하기 위해 대안을 시도해 보는 것도 호출 소프트웨어에서는 불가능합니다.
## V3 상태
v3에서는 다음과 같이 몇 가지 지침을 제공하는 헤더가 존재합니다:
- `Retry-After`: 레이트 리미트 창이 만료되고 새로운 API 호출 세트를 허용하기까지 남은 초 단위 시간
- `Discourse-Rate-Limit-Error-Code`: 어떤 유형의 레이트 리미트에 도달했는지를 나타내는 지표(예: `admin_api_key_rate_limit` 또는 `ip_10_secs_limit`)
HTTP 429 응답 시 페이로드에도 몇 가지 힌트가 포함되지만, HTTP 헤더보다 추가적인 정보는 없습니다:
```json
{
"errors": [
"i18n text"
],
"error_type": "rate_limit",
"extras": {
"wait_seconds": 21,
"time_left": "21 seconden"
}
}
```
이 헤더들은 429 응답 시에만 반환된다는 점에 유의하세요. 따라서 다가올 실패를 예측하여 미리 요청을 줄이는 것은 불가능합니다.