When rate limiting is hit return return a Retry-After header

기여 기능
1

Hi,

Shouldn’t the delay to wait be in the Response as a Retry-After header?

5개의 좋아요
2

Sure, sounds like a good suggestion

3개의 좋아요
3

Taking a stab at this :wink:

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

6개의 좋아요
4

안녕하세요,

PR이 병합된 것 같지만, ‘Retry-After’ 헤더를 확인하지 못하겠습니다.
여기 제 오류의 본문이 있습니다:
![image|690x167](upload://790x167](upload://743Q122rzulyqzDf5v21IYLMsHk.png)
그리고 여기 헤더가 있습니다:

image
image1572×484 45.2 KB

이것이 버그인가요? 미리 감사드립니다.

5

좋은 제안입니다!

그동안 IETF에서는 호출 프로그램에 레이트 리미팅 정보를 전달하기 위한 헤더를 표준화했습니다. 관련 내용은 https://www.ietf.org/archive/id/draft-polli-ratelimit-headers-02.html을 참조하세요. 저희 소프트웨어는 다양한 레이트 리미터에 이 표준을 적용하고 있습니다(Fair Use Daily Limits for a Better User Experience - invantive 참고).

저희의 경우, Discourse가 헤더를 통해 레이트 리미트 정보를 반환해 준다면 큰 도움이 될 것입니다. 호출 프로그램은 설정 파일에 접근할 수 없으며, 직접 문의하지 않는 한 레이트 리미트 정의가 정확히 무엇인지 알 수 없습니다. 또한 레이트 리미트에 근접한 상황에서 429 오류를 피하기 위해 대안을 시도해 보는 것도 호출 소프트웨어에서는 불가능합니다.

V3 상태

v3에서는 다음과 같이 몇 가지 지침을 제공하는 헤더가 존재합니다:

  • Retry-After: 레이트 리미트 창이 만료되고 새로운 API 호출 세트를 허용하기까지 남은 초 단위 시간
  • Discourse-Rate-Limit-Error-Code: 어떤 유형의 레이트 리미트에 도달했는지를 나타내는 지표(예: admin_api_key_rate_limit 또는 ip_10_secs_limit)

HTTP 429 응답 시 페이로드에도 몇 가지 힌트가 포함되지만, HTTP 헤더보다 추가적인 정보는 없습니다:

{
    "errors": [
        "i18n text"
    ],
    "error_type": "rate_limit",
    "extras": {
        "wait_seconds": 21,
        "time_left": "21 seconden"
    }
}

이 헤더들은 429 응답 시에만 반환된다는 점에 유의하세요. 따라서 다가올 실패를 예측하여 미리 요청을 줄이는 것은 불가능합니다.