الخلاصة

  • أضافت النسخة draft-ietf-rpp-core-01 المؤرخة في 2 نوفمبر قواعد لإعادة توجيه الطلبات داخل بروتوكول RPP الذي تناقشه مجموعة عمل في IETF. الوثيقة مسودة إنترنت وليست RFC.
  • لا يستخدم الخادم إلا HTTP 307 أو 308 مع عنوان HTTPS مطلق. وإذا اختار العميل اتباع التحويل، فعليه حفظ المحتوى والترويسات، ومنها RPP-Cltrid.
  • لا تُرسل ترويستا Authorization وRPP-Authorization إلى منشأ مختلف تلقائياً؛ يلزم أن يعرف العميل أنه اسم بديل للمنشأ الأول، أو أن يملك بيانات اعتماد صالحة للمنشأ الجديد.

الإشارة إلى الباب لا تمنح حق فتح الخزنة

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

القاعدة الأولى تخص العملية نفسها. لا يوجه الخادم العميل إلا برمز 307 أو 308؛ فهذان الرمزان يحافظان على طريقة HTTP. ويجب أن تتضمن ترويسة Location عنوان HTTPS مطلقاً. يمكن للعميل اتباع التوجيه، لكنه حين يفعل يرسل المحتوى والترويسات نفسها، بما فيها معرّف المعاملة RPP-Cltrid. بذلك لا تتحول العملية أثناء عبورها إلى معاملة غامضة جديدة. أما رموز التحويل الأخرى، حتى إن صدرت عن وسيط، فهي خطأ في البروتوكول.

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

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

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

المصادر الأصلية