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
Available settings for global rate limits and throttling
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

Hi,

Seems like the PR is merged but I don’t observe any ‘Retry-After’ headers.
Here you can see the body of my error:

image
image1832×444 42 KB

And here you can see the headers:
image
image1572×484 45.2 KB

Is this a bug? Thanks in advance

5

良い提案ですね！

その間、IETFは呼び出しプログラムにレート制限を通知するためのヘッダーを標準化しました。RateLimit Header Fields for HTTP を参照してください。当社のソフトウェアは、さまざまなレート制限器にこれらを使用しています（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の場合にのみ返されることに注意してください。将来の障害を予測して少しバックオフすることはできません。