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

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 بتوحيد الرؤوس لإبلاغ البرامج المتصلة بحدود المعدل؛ انظر RateLimit Header Fields for HTTP. يستخدم برنامجنا هذه الحدود لمجموعة من محددات المعدل (انظر Fair Use Daily Limits for a Better User Experience - invantive).

في حالتنا، سيساعد بالتأكيد عندما تعيد Discourse معلومات حد المعدل من خلال الرؤوس؛ لا تملك البرامج إمكانية الوصول إلى ملف التكوين وليس لدينا فكرة دقيقة دون أن نسأل ما هي التعريفات. كما لا يمكن لبرنامجنا المتصل محاولة التهرب من 429 عن طريق تجربة بدائل عندما يكون حد المعدل قريبًا.

حالة V3

على v3، توجد الرؤوس التالية التي توفر بعض الإرشادات:

  • Retry-After: عدد الثواني التي تنتهي بعدها نافذة حد المعدل ويسمح بمجموعة جديدة من استدعاءات واجهة برمجة التطبيقات.
  • 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. لا يمكن التنبؤ بفشل قادم للتراجع قليلاً.