Cuando se alcance el limitador de velocidad, devolver una cabecera Retry-After

Característica
1

Hi,

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

5 Me gusta
Available settings for global rate limits and throttling
2

Sure, sounds like a good suggestion

3 Me gusta
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 Me gusta
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

¡Buena sugerencia!

Mientras tanto, el IETF ha estandarizado las cabeceras para informar a los programas que llaman sobre la limitación de la tasa; véase RateLimit Header Fields for HTTP. Nuestro software las utiliza para una serie de limitadores de tasa (véase Fair Use Daily Limits for a Better User Experience - invantive).

En nuestro caso, sería de gran ayuda que Discourse devolviera información sobre la limitación de la tasa a través de las cabeceras; los programas no tienen acceso al archivo de configuración y no tenemos ni idea exacta sin preguntar cuáles son las definiciones. Tampoco nuestro software que llama puede intentar evadir un 429 probando alternativas cuando la limitación de la tasa está a la vista.

Estado de V3

En la v3, están presentes las siguientes cabeceras que proporcionan alguna orientación:

  • Retry-After: número de segundos después de los cuales expira la ventana de limitación de la tasa y se permite un nuevo conjunto de llamadas a la API.
  • Discourse-Rate-Limit-Error-Code: una indicación de qué tipo de limitación de tasa se ha alcanzado (como admin_api_key_rate_limit o ip_10_secs_limit).

En HTTP 429, la carga útil también contiene algunas pistas, pero nada adicional en comparación con las cabeceras HTTP:

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

Tenga en cuenta que estas cabeceras solo se devuelven en caso de 429. No es posible predecir un fallo inminente para retroceder un poco.