الخلاصة

  • تحدد Retry-After المدة التي ينبغي انتظارها قبل طلب لاحق، ولا تضمن وقت التعافي.
  • قد تكون القيمة تاريخ HTTP مطلقاً أو تأخيراً بالثواني، لذلك يدخل ضبط الساعة والتفسير في سلسلة الدليل.
  • تصف 503 أو 429 الاستجابة المرصودة، لا السعة المستقبلية ولا حالة كل التبعيات.
  • ينبغي أن يربط سجل قرار إعادة المحاولة بين التعليمات وبيانات حديثة عن حالة الخدمة والنتيجة الفعلية.

لنتخيل متحكماً للتعافي يتلقى 503 Service Unavailable مع Retry-After: 120. يحجز كل الطلبات، ويضع علامة خضراء بعد دقيقتين، ثم يطلق الطابور كله في الثانية نفسها. يُغلق الحادث قبل نجاح أي طلب جديد. وعند انتهاء المدة يبقى الخادم الأصلي مقيداً، وتظل إحدى التبعيات غير متاحة، فتطيل موجة المحاولات المتزامنة الحمل الزائد.

كانت الترويسة صحيحة، أما استنتاج التعافي فكان مضافاً من خارجها.

يعرّف RFC 9110 Retry-After تعريفاً محدوداً: فهي تشير إلى المدة التي ينبغي لوكيل المستخدم انتظارها قبل طلب متابعة. يستطيع الخادم مع 503 اقتراح وقت مناسب للمحاولة، وفي رد إعادة التوجيه يمكن للحقل أن يبين المدة التي يُستحسن انتظارها قبل اتباع العنوان الجديد. لا يحول أي منهما الوقت إلى توقع لصحة الخدمة.

للحقل شكلان: تاريخ HTTP يحدد نقطة زمنية، أو عدد غير سالب من الثواني بعد استلام الرد. يعتمد الأول على الساعات، ويعتمد الثاني على وقت الاستلام الفعلي وكيفية احتساب الوسطاء والطوابير والمؤقتات للزمن. حفظ الموعد المحسوب وحده يمحو التعليمات الأصلية.

يصف RFC 9110 حالة 503 بأنها عجز مؤقت بسبب حمل زائد أو صيانة مجدولة. يمكن اقتراح موعد جديد، لكن المعيار لا يضمن زوال القيد في تلك اللحظة، ولا يوجب على كل خادم مثقل أن يستخدم 503. قد يكون التعافي أبكر أو أبطأ أو جزئياً أو خاصاً بمنطقة أو بسياق وصول، وقد تعوقه تبعية أخرى.

يعرّف RFC 6585 حالة 429 Too Many Requests. يمكن أن تحمل Retry-After، لكن طريقة تعريف المستخدم وعد الطلبات متروكة للخادم. قد تختلف الحدود بين رمز دخول وحساب ومسار ومستأجر وحافة. المؤقت المنفصل عن هذا النطاق لا يثبت قبول الطلب التالي.

يحفظ سجل قرار إعادة المحاولة الطلب والرد ونقطة الرصد والحالة والقيمة الأصلية وشكلها ووقت الاستلام والوقت المحسوب ومصدر الساعة والعمر الذي أضافه الوسيط. ويربطها بنطاق الحساب أو الرمز أو المسار أو المستأجر من دون حفظ أسرار.

ثم يسجل طريقة زيادة الفاصل بين المحاولات، والتفاوت العشوائي المضاف إلى هذا الفاصل، وميزانية المحاولات، والحد الأقصى للطلبات المتزامنة، والإلغاء، ووقت الإرسال الفعلي. وقبل السماح بالمحاولة الجديدة يضيف فحوصاً حديثة لحالة الخدمة والموارد المتاحة والتبعيات والتفويض. وأخيراً يحفظ الرد اللاحق ونتيجة المعاملة. انتهاء الانتظار، ونجاح الفحص، والسماح بالمحاولة، واكتمال المعاملة أحداث مترابطة لكنها ليست حدثاً واحداً.

المصادر

RFC 9110 — HTTP Semantics؛ RFC 6585 — Additional HTTP Status Codes.