Wenn die Ratenbegrenzung erreicht wird, einen Retry-After-Header zurückgeben

Merkmal
1

Hi,

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

5 „Gefällt mir“
Available settings for global rate limits and throttling
2

Sure, sounds like a good suggestion

3 „Gefällt mir“
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 „Gefällt mir“
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

Guter Vorschlag!

In der Zwischenzeit hat die IETF die Header zur Information aufrufender Programme über Ratenbegrenzungen standardisiert; siehe RateLimit Header Fields for HTTP. Unsere Software verwendet sie für eine Reihe von Ratenbegrenzern (siehe Fair Use Daily Limits for a Better User Experience - invantive).

In unserem Fall wäre es definitiv hilfreich, wenn Discourse Ratenbegrenzungsinformationen über Header zurückgeben würde; die Programme haben keinen Zugriff auf die Konfigurationsdatei und wir haben ohne Nachfrage keine genaue Vorstellung, was die Definitionen sind. Noch kann unsere aufrufende Software versuchen, eine 429 zu umgehen, indem sie Alternativen ausprobiert, wenn die Ratenbegrenzung in Sicht ist.

V3 Status

Auf v3 sind die folgenden Header vorhanden, die einige Hinweise geben:

  • Retry-After: Anzahl der Sekunden, nach denen das Ratenbegrenzungsfenster abläuft und ein neuer Satz von API-Aufrufen zulässig ist
  • Discourse-Rate-Limit-Error-Code: ein Hinweis darauf, welche Art von Ratenbegrenzung getroffen wurde (z. B. admin_api_key_rate_limit oder ip_10_secs_limit).

Bei HTTP 429 enthält auch die Nutzlast einige Hinweise, aber nichts Zusätzliches im Vergleich zu den HTTP-Headern:

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

Beachten Sie, dass diese Header nur bei 429 zurückgegeben werden. Es ist nicht möglich, einen bevorstehenden Fehler vorherzusagen, um sich etwas zurückzuhalten.