الخلاصة

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

تصل إلى العنوان الصحيح بطلب مختلف

حين يبحث عميل RDAP عن الجهة المسؤولة عن مورد إنترنت انتقل بين سجلين إقليميين، قد تقوده بيانات تخصيص IANA إلى الخادم الأول ثم تحيله استجابة HTTP إلى الجهة التي تملك السجل حالياً. هذه هي الحالة التي يشرحها مشروع REGEXT في القسم 4.1. وإذا حمل الطلب معاملاً يطلب عرضاً إضافياً، يصبح على الخادم الأول أن يختار ما يُكتب في رابط Location. العنوان التالي قد يكون صحيحاً، لكن صحته وحدها لا تجيز نقل كل قيمة وصلت إلى الخادم الأول.

تحدد RFC 9224 طريقة العثور على خدمة RDAP المعتمدة انطلاقاً من سجلات تخصيص IANA. ويوضح مشروع REGEXT أن خريطة التخصيص تلك لا تعكس انتقال الموارد لاحقاً بين سجلات الإنترنت الإقليمية. لهذا تصبح إعادة التوجيه مهمة في الوصول إلى السجل الإقليمي صاحب السلطة الفعلية. اختيار المعاملات ليس مسألة هامشية؛ إنه يحدث على طريق البحث العادي عن الجهة التي تملك الإجابة.

تُلزم RFC 7480 الخوادم بتجاهل معاملات الاستعلام غير المعروفة. ويضيف مشروع الامتدادات شرطاً عند إنشاء رابط إعادة التوجيه: لا تنسخ المعاملات تلقائياً. فقد تحتوي اعتماداً أمنياً أو معلومات تتبع لا تخص الخادم التالي. ولا يكفي أن تكون الوجهة قادرة على فهم المعامل؛ ينبغي أيضاً أن تكون متلقياً مناسباً لمحتواه. القدرة على القراءة شيء، وحق الاطلاع على القيمة شيء آخر.

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

أين يصلح المعامل فعلاً؟

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

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

تسجل صفحة الوثيقة في IETF أن النسخة 17 مؤرخة في 27 أكتوبر 2026، وهي مسودة إنترنت نشطة لمجموعة REGEXT، وحالتها لدى IESG هي «I-D Exists». لم تصدر بعد بوصفها RFC. وكانت قاعدة معاملات إعادة التوجيه موجودة قبل هذه النسخة؛ الأهمية هنا في المسؤولية التي يعرضها النص الحالي عند حدود كل جهة.

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

المصادر