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

Funzionalità
1

Hi,

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

5 Mi Piace
Available settings for global rate limits and throttling
2

Sure, sounds like a good suggestion

3 Mi Piace
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 Mi Piace
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

Ottimo suggerimento!

Nel frattempo, l’IETF ha standardizzato gli header per informare i programmi chiamanti sulla limitazione della frequenza; vedere RateLimit Header Fields for HTTP. Il nostro software li utilizza per una serie di limitatori di frequenza (vedere Fair Use Daily Limits for a Better User Experience - invantive).

Nel nostro caso, sarebbe sicuramente d’aiuto se Discourse restituisse informazioni sulla limitazione della frequenza tramite gli header; i programmi non hanno accesso al file di configurazione e non abbiamo un’idea precisa senza chiedere quali siano le definizioni. Né il nostro software chiamante può cercare di evitare un 429 provando alternative quando la limitazione della frequenza è in vista.

Stato V3

Su v3, sono presenti i seguenti header che forniscono alcune indicazioni:

  • Retry-After: numero di secondi dopo i quali la finestra di limitazione della frequenza scade e è consentito un nuovo set di chiamate API
  • Discourse-Rate-Limit-Error-Code: un’indicazione del tipo di limitazione della frequenza che viene raggiunta (come admin_api_key_rate_limit o ip_10_secs_limit).

Su HTTP 429, anche il payload contiene alcuni suggerimenti, ma nulla di aggiuntivo rispetto agli header HTTP:

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

Si noti che questi header vengono restituiti solo in caso di 429. Non è possibile prevedere un imminente fallimento per ridurre un po’ il carico.