当达到速率限制时返回一个 Retry-After 头信息

功能
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

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 已经标准化了用于通知调用程序有关速率限制的标头；请参阅 https://www.ietf.org/archive/id/draft-polli-ratelimit-headers-02.html。我们的软件将其用于一系列速率限制器（请参阅 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 标头相比没有其他内容：

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

请注意，这些标头仅在 429 时返回。无法预测即将发生的故障以稍微退避。