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
image1832×444 42 KB

А вот заголовки:
image
image1572×484 45.2 KB

Это баг? Заранее спасибо.

5

Отличное предложение!

Тем временем, IETF стандартизировала заголовки для информирования вызывающих программ об ограничении частоты запросов; см. RateLimit Header Fields for HTTP. Наше программное обеспечение использует их для различных механизмов ограничения частоты (см. 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. Предсказать предстоящий сбой и немного уменьшить нагрузку заранее невозможно.