الخلاصة

  • يحمل draft-ietf-regext-epp-https-04 تاريخ 3 سبتمبر 2026 وهو Internet-Draft نشط لمجموعة REGEXT. ليس RFC ولا موافقة من IETF ولا دليلاً على التبني التشغيلي.
  • عندما يصل الطلب إلى طبقة EPP وتنتج استجابة EPP، يعيد الخادم HTTP 200 (OK) سواء نجح الأمر أم فشل. كل رمز يصف طبقة مختلفة.
  • إذا كان التنفيذ قد حدث ولم تصل استجابة EPP صالحة، تبقى النتيجة غير محسومة. يجب ألا يعيد الوسطاء POST تلقائياً؛ وحده عميل EoH الذي يفهم الأمر كاملاً وامتداداته يستطيع اتخاذ القرار مع حفظ المعرّف والترتيب.

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

هذه هي الحدود التي يوضحها draft-ietf-regext-epp-https-04. بروتوكول EPP حوار XML ذو حالة بين عميل تزويد ومستودع مشترك. يفرض RFC 5730 ترتيب الأوامر واستمرار الجلسة وتنسيق كل أمر مع استجابته. المشروع لا يحول EPP إلى REST، بل ينقل الحوار القائم داخل طلبات POST كي يستفيد المشغل من جدران تطبيقات الويب وموازنة الحمل والرصد في الطبقة السابعة.

تبدأ الوصلة بطلب POST فارغ إلى عنوان يُسلّم خارج البروتوكول. تحمل الاستجابة الصحيحة تحية EPP ونوع application/epp+xml وتعليمتي no-store وnosniff وملف تعريف ارتباط للجلسة. ثم ينشئ نجاح <login> جلسة EPP موثقة.

الرقم 200 ليس موافقة على الأمر

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

أما 4xx و5xx فتصفان تعذّر طبقة HTTP: طلباً مشوهاً، نوع محتوى غير مدعوم، حداً للحجم أو المعدل، حملاً زائداً أو عطلاً في البوابة. عندها لم يتلق العميل نتيجة EPP ذات حجية. لكن الرمز الخارجي وحده لا يثبت دائماً أن المعالجة لم تبدأ.

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

لذلك يجب ربط حالة HTTP ورمز EPP ومعرّف معاملة العميل. الأول يحدد مسار الطلب في البنية الشبكية، والثاني يسجل قرار المستودع، والثالث يثبت أن أي تعافٍ لاحق لا يزال تابعاً للنية الأصلية.

ضياع الاستجابة لا يلغي التنفيذ

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

إعادة POST آلياً قد تنشئ فعلاً ثانياً. لا يعرّف HTTP طريقة POST على أنها idempotent. صُممت أوامر EPP بحيث يمكن جعلها كذلك، إلا أن الأمان يعتمد على الأمر المحدد بكل امتداداته. الوكيل العام يرى مهلة وPOST؛ لا يفهم معنى عملية السجل.

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

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

تعدد مسارات HTTP لا يبيح توازي أوامر السجل

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

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

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

يذكر المشروع تنفيذاً تطويرياً في Verisign SDK يدعم HTTP/1.1 وHTTP/2، وترتيباً مختلفاً قليلاً لدى Registro.it منذ 2009. ويحذر النص نفسه من أن هذه إفادات مساهمين لم تتحقق منها IETF. إنها قرينة على التجربة، لا إثباتاً للانتشار أو المطابقة أو الجودة.

تفصل منهجية Heng Lu في طبقات الواقع بين تسليم HTTP وقرار EPP وحالة المستودع ونشر DNS ومشاهدة المستخدم. وتضع أولوية الشيفرة العاملة قرار التعافي لدى من يفهم الأمر ويحفظ معرّفه ويوقف ما بعده ويستعلم عن الحالة ذات الحجية.

يحدّث HTTPS وسيلة النقل، لكنه لا يحول سجلي النتيجة إلى حقيقة واحدة.

المصادر