HTTP 200 ليس قراراً صادراً عن سجل EPP

الخلاصة

• تنص المراجعة 04 من مسودة EPP عبر HTTPS على أن الخادم يعيد HTTP 200 متى وصلت الرسالة إلى معالجة EPP وتولدت استجابة EPP، سواء أعلنت الاستجابة نجاح الأمر أم فشله.
• إذا لم تصل استجابة EPP صالحة مع بقاء احتمال أن الأمر بلغ المعالجة، فالمصير غير محسوم لا فاشل. ولا يقرر الإعادة إلا عميل EoH الذي يعرف دلالة الأمر الكامل، بما فيه الامتدادات، ويحافظ على الترتيب.
• يحتاج السجل والمسجّل إلى إيصال لتسوية الأمر يربط محاولة HTTP بمعرّفات EPP وأساس قابلية التكرار وحاجز الترتيب وصاحب القرار ودليل المصالحة النهائي.

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

تجعل draft-ietf-regext-epp-https-04، المنشورة في 3 سبتمبر 2026، هذا الحد صريحاً. إذا وصل طلب HTTP إلى طبقة معالجة EPP وتولدت استجابة EPP، يجب أن يحمل الغلاف الخارجي الحالة 200، بصرف النظر عن كون نتيجة EPP نجاحاً أو فشلاً. نجاح الغلاف يعني أن في داخله جواباً تطبيقياً ينبغي قراءته؛ ولا يحل محله.

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

هذا الوصف ليس تهرباً من القرار. إنه قرار دقيق بشأن حدود المعرفة: لا توجد استجابة EPP موثوقة في السجل المتاح، ولا تستبعد الآثار احتمال تنفيذ الأمر. تحويل هذا الوضع تلقائياً إلى «فشل» ثم إرسال أمر آخر يمنح بنية النقل سلطة تكرار فعل في السجل من دون أن تفهم معناه.

مظهر الويب لا يلغي حالة جلسة EPP

يعرّف RFC 5730 بروتوكول EPP بوصفه بروتوكول XML ذا حالة لإدارة كائنات في مستودع مركزي مشترك. هناك أوامر للجلسة، واستعلامات للقراءة، وتحويلات تنشئ الكائن أو تحدثه أو تجدده أو تنقله أو تحذفه. الأوامر ذرية ومصممة بحيث يمكن جعلها متكررة الأثر. عبارة «يمكن جعلها» لا تمنح كل أمر، مع أي امتداد وفي أي تنفيذ، رخصة إعادة عامة.

يبدأ الربط عبر HTTPS بطلب POST فارغ. لا ينشأ اتصال EoH إلا إذا أعاد الخادم HTTP 200 يتضمن تحية EPP وأنشأ جلسة HTTP بواسطة ملف تعريف الارتباط. وبعد نجاح login تبدأ جلسة EPP الموثقة. يحمل كل POST لاحق رسالة EPP واحدة، وتحمل كل استجابة بعد المعالجة جواب EPP واحداً.

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

يكشف خطأ الجلسة الفرق بوضوح. إذا وصل أمر بمعرّف جلسة فارغ أو غير صالح إلى طبقة EPP، فعلى الخادم إرسال خطأ EPP رقم 2002 داخل HTTP 200. الرقم الخارجي يقول إن جواب EPP نُقل؛ والرقم الداخلي يقول إن استخدام الأمر خاطئ. قراءة الأول وحده تقلب النتيجة.

«غير محسوم» حالة تشغيلية واجبة الحفظ

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

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

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

قابلية التكرار تخص الرسالة الكاملة

لا يعد RFC 9110 طريقة POST متكررة الأثر افتراضياً. لا ينبغي للعميل إعادة طلب غير متكرر تلقائياً ما لم يعرف أن دلالته الفعلية متكررة الأثر، أو يستطيع إثبات أن الطلب الأول لم يطبق. ويحظر على الوكيل إعادة الطلب غير المتكرر تلقائياً.

تضع المراجعة 04 اختباراً أدق لعميل EoH. يمكنه إعادة المحاولة فقط إذا كان العطل محتملاً أن يكون عابراً، وكانت دلالة حالة HTTP المستلمة تسمح بذلك، وعرف العميل أن أمر EPP الكامل، بما في ذلك جميع الامتدادات، متكرر الأثر على مستوى التطبيق. يجب أن تكون الرسالة هي نفسها وأن تحتفظ بـclTRID نفسه إن كان موجوداً. ولا يرسل العميل أمراً تالياً حتى يتلقى جواباً صالحاً أو يتخلى عن الجلسة.

ذكر الامتدادات جوهري. قد يبدو الفعل الأساسي آمناً للتكرار، ثم يضيف امتداد شرطاً أو زمناً أو أثراً آخر. لذا يجب أن يوثق القرار نسخة الامتداد وعقد الخدمة والرسالة التي أرسلت فعلاً. الاستشهاد العام بأن EPP «مصمم ليكون قابلاً للتكرار» لا يكفي.

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

clTRID يربط المحاولات ولا يضمن وحده إزالة التكرار

يسمح RFC 5730 للعميل بإضافة clTRID، ويتحمل العميل مسؤولية فرادته في فضائه. تجمع استجابة الخادم هذا المعرّف مع svTRID فريد يخصصه الخادم. يحمي الزوج سلامة المزامنة بين الأمر والجواب، وينبغي للطرفين تسجيله والاحتفاظ به وحمايته.

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

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

انتظار الجواب يحفظ السببية

يدعم HTTP/2 وHTTP/3 تعدد الإرسال، لكن ربط EoH يمنع وجود أكثر من طلب HTTP معلق في جلسة EPP واحدة. وإذا أنشأ وسيط طلبات متزامنة، فعلى الخادم أن يحدد هل يفشلها أم يرتبها تسلسلياً.

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

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

إيصال تسوية الأمر

يركز سجل HTTP عادة على المسار والحالة والكمون والخادم الخلفي وعدد المحاولات. ويركز سجل EPP على XML والنتيجة ومعرّفات المعاملة. المطلوب كائن حوكمة يجمع المنظورين:

1. نوع الأمر والكائن المتأثر والبصمة المعيارية للرسالة كاملة مع الامتدادات؛
2. هوية الجلسة وclTRID ومعرّف كل محاولة HTTP؛
3. وقت بدء الإرسال وآخر نقطة يمكن عندها إثبات عدم الوصول؛
4. نتيجة HTTP والمكوّن الذي أنشأها فعلاً؛
5. رمز EPP وsvTRID عند وصول جواب صالح، مع تسجيل الغياب صراحة عند عدمه؛
6. تسوية ثلاثية: نجاح مثبت، فشل مثبت، أو غير محسوم؛
7. مصدر تقييم قابلية التكرار ونطاقه ونسخته والامتدادات التي يشملها؛
8. دليل الحاجز الذي منع الأمر التالي؛
9. الشخص أو السياسة المسؤولة عن الإعادة أو التخلي أو المصالحة؛
10. دليل إغلاق القضية وتوقيته ودرجة الثقة وأي اختلاف باق بين سجلي الطرفين.

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

وتكشف The Policy Mirror توزيع السلطة الكامن في الإعداد. من يملك حق تكرار التحويل؟ من يدفع تكلفة الأثر إذا كان الطلب الأول قد نفذ؟ من يستطيع الاطلاع على الدليل والطعن فيه؟ إذا حسّن الوسيط مقياس إتاحته ونقل كلفة المصالحة إلى المسجّل أو صاحب الاسم، فقد أصبح خيار البنية التحتية سياسة لتوزيع المخاطر.

للمسودة نفسها حدود سلطة

المراجعة 04 وثيقة عمل نشطة في مجموعة REGEXT ومقصود بها Standards Track. ليست RFC، ولم تكمل مراجعة IESG، وتنتهي في 7 مارس 2027. هدف سبتمبر 2026 للتقديم إلى النشر معلم مخطط، لا دليلاً على أن التقديم أو الموافقة حدثا.

يسرد قسم التنفيذ Verisign EPP SDK وتنفيذاً من IIT-CNR/Registro.it. ويقول تنبيه RFC 7942 المصاحب إن المعلومات قدمها مساهمون، ولم تتحقق منها IETF، ولا تعني تأييداً، وليست دليلاً للمنتجات. هي دليل على خبرة تنفيذ معلنة، لا على سلوك موحد في الإنتاج.

كما تقترح المسودة قيداً في سجل IANA لامتدادات EPP. وصف القيد المقترح لا ينشئه تلقائياً. الدقة في بيان حالة الوثيقة هي الوجه الآخر للدقة في بيان حالة الأمر.

المصادر

1. IETF — EPP Transport over HTTPS، المراجعة 04
2. IETF Datatracker — حالة الوثيقة
3. IETF Datatracker — سجل التغييرات
4. مجموعة عمل REGEXT
5. RFC 5730 — Extensible Provisioning Protocol
6. RFC 5731 — EPP Domain Name Mapping
7. RFC 5734 — EPP Transport over TCP
8. RFC 9110 — HTTP Semantics
9. RFC 7942 — Improving Awareness of Running Code
10. IANA — Extensions for EPP
11. Lu Heng — Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption
12. Lu Heng — The Policy Mirror