الخلاصة

  • سمح HTTP/2 بإعادة استخدام اتصال دائم ومتعدد التدفقات لطلبات تحمل مكوّنات سلطة URI مختلفة، متى دعمت نتيجة DNS والشهادة هذا الاستنتاج. كانت تلك أدلة كافية لمحاولة العميل، لكنها لم تكشف كل اختيار داخلي للخدمة جرى عند تفاوض الاتصال الأول.
  • ترفض 421 Misdirected Request اقتران أصل معيّن باتصال معيّن. لا تعلن انتقال URI، ولا سوء صياغة الطلب، ولا فشل TLS بالضرورة. يجوز للعميل إعادة العملية نفسها عبر اتصال آخر حتى إن لم تكن الطريقة تكرارية آمنة؛ أما الوكيل العادي فلا يجوز له إنشاء 421.
  • أضافت RFC 8336 إطار ORIGIN كي يعلن خادم HTTP/2 مسبقاً Origin Set الخاص بالاتصال، ويلزم العميل الداعم بحذف الأصل من مجموعة ذلك الاتصال بعد 421. واحتفظ HTTP/3 بالحالة فوق QUIC، لأن المسألة الدائمة هي حدود السلطة داخل قناة مشتركة لا خاصية عارضة في TCP.

الاسم الثاني كان صالحاً على الشهادة

لدى العميل اتصال مشفّر مفتوح للأصل الأول. ثم يحتاج إلى مورد من اسم ثانٍ. يشير DNS إلى العنوان نفسه، وتضم شهادة النظير الاسم الثاني أيضاً. فتح اتصال جديد يعني تفاوضاً آخر وحالة نقل إضافية وانتظاراً كان يمكن تجنبه. أما الاتصال القائم فقد تم توثيقه وأصبح قادراً في HTTP/2 على حمل تدفقات متوازية.

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

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

كان لدى العميل سبب وجيه للمحاولة، ولدى الخادم معرفة محلية أدق بالرفض. احتاج HTTP إلى جواب يحفظ الحقيقتين معاً؛ فكان 421.

حدّد Host المقصود ولم يعيّن من يجيب

عرف HTTP مبكراً أن عنوان النقل ليس اسم مورد. حين بدأت مواقع عديدة تشترك في عنوان IP واحد، لم يعد مقصد TCP كافياً لمعرفة مساحة الأسماء التي يريدها العميل. لذلك ألزم HTTP/1.1 الطلب بحقل Host، ويحمل :authority عادةً المعنى نفسه في HTTP/2 وHTTP/3.

حل ذلك سؤالاً عند المرسل: أي أصل أقصد؟ ولم يحل سؤالاً آخر عند المستقبل: هل هذا الأصل مهيأ على هذه الخدمة وفي سياق هذا الاتصال؟

تحافظ RFC 9110 على الفصل. يميز المضيف والمنفذ في URI المستهدف مساحة أصل عن غيرها من المساحات التي قد يديرها الخادم. وبعد معرفة الهدف، يبقى على الخادم أن يقرر المعالجة أو التمرير أو إعادة التوجيه أو الرفض، وأن يتحقق من متطلبات المخطط وسياق الاتصال.

ينقل Host نية العميل. لكنه لا يمنح كل عملية قابلة للوصول خلف المقبس حق التحدث باسم ذلك المضيف.

جعل HTTP/2 الاستنتاج مجدياً اقتصادياً

نُشرت المواصفة الأصلية لـ HTTP/2، وهي RFC 7540، في مايو 2015. أعطت الاتصالات الدائمة والتدفقات المتعددة قيمة أكبر للقناة المفتوحة. وكان يجوز إعادة استخدام اتصال واحد لطلبات تختلف مكوّنات سلطتها في URI متى بدا خادم الأصل ذا سلطة عليها.

في TCP غير المشفّر، اعتمد ذلك على أن يحل اسم المضيف الجديد إلى عنوان IP نفسه. وفي HTTPS لزم أيضاً أن تكون الشهادة صالحة للمضيف وفق الفحوص التي كان العميل سيجريها لو فتح اتصالاً جديداً. وهكذا أمكن لأسماء subjectAltName متعددة، أو لاسم شامل مناسب، أن تدعم عدة أصول.

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

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

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

رفض 421 العلاقة لا وجود الأصل

أدخلت RFC 7540 حالة 421 Misdirected Request. وانتقل تعريفها الحالي إلى RFC 9110 ضمن دلالات HTTP العامة. تعني أن الخادم غير قادر أو غير راغب في إنتاج استجابة ذات سلطة لـ URI المستهدف.

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

يستطيع خادم الأصل إنشاء 421، وكذلك بوابة تتصرف نيابة عنه. لكن RFC 9110 تمنع الوكيل من إنشائها. فلو استطاعت عقدة تمرير عادية إصدار الحكم نفسه، لما عرف العميل هل رفض الأصل سياق الاتصال أم فضّل وسيط طريقاً آخر لمصلحته.

قيمة الدليل السلبي تعتمد على مصدره. لذلك بقي حق الرفض عند الحد الذي يملك خريطة خدمة الأصل.

الوصول والتوثيق وقبول السياق ثلاث قضايا

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

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

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

يحصر 421 الحكم في الحافة التي فشلت: أصل واحد على اتصال واحد. فلا يحوّل دليلاً محدوداً إلى امتياز شامل، ولا يحوّل رفضاً محدوداً إلى انهيار شامل.

أعادت المحاولة اختيار السياق لا معنى الطلب

يجوز للعميل بعد 421 إعادة الطلب على اتصال مختلف، كاتصال جديد خاص بالأصل أو اتصال إلى خدمة بديلة مناسبة. وتسمح RFC 9110 بذلك سواء كانت الطريقة تكرارية آمنة أم لم تكن.

لا ينبغي تحويل هذه العبارة إلى إذن عام بإعادة كل عملية كتابة بعد كل عطل شبكي. لـ421 معنى محدد: رفض المستجيب إنتاج جواب الأصل ذي السلطة في السياق الحالي. وتغيير الاتصال يصحح مسار التسليم، لا يكرر عملاً بعد نتيجة تطبيق مجهولة.

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

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

التصحيح في مركبة الطلب، لا في هوية المورد.

لم يكن 421 إعادة توجيه بلا عنوان

تقترح إعادة التوجيه هدفاً آخر، وتقدم عادةً Location يغيّر URI التالي. أما 421 فلا يعيّن هدفاً بديلاً، ولا يقول إن المحتوى انتقل.

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

وليس 421 هو 400 Bad Request، لأن صياغة الرسالة قد تكون سليمة. وليس 403 Forbidden، لأن جوهره ليس صلاحية المستخدم على المورد. وليس إنذار TLS، إذ يمكن أن يكون نجاح فحص الشهادة هو السبب الذي شجّع على إعادة الاستخدام أصلاً.

الحالة الضيقة تمنع طبقة واحدة من إعادة تعريف مشكلة طبقة أخرى.

نقل ORIGIN بعض المعرفة إلى ما قبل الخطأ

التصحيح التفاعلي يضيف زمناً: يرسل العميل الطلب، يستلم 421، ثم يختار اتصالاً آخر. لذلك عرّفت RFC 8336، الصادرة في مارس 2018، إطار ORIGIN في HTTP/2 كي يعلن الخادم الأصول التي يمكن استعمال اتصال من أجلها.

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

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

وعند استلام 421، يجب على العميل الذي يطبق RFC 8336 حذف الأصل من Origin Set لذلك الاتصال. يصبح الرفض معرفة تغيّر الاختيار التالي، لا صفحة خطأ تُنسى.

مفتاح الذاكرة الصحيح هو الأصل مع الاتصال. حظر الأصل في كل مكان استنتاج أوسع من الدليل، وعدم التذكر يعيد الخطأ نفسه.

دلّ Alt-Svc على طريق ولم ينشئ سلطة ذاتية

يتيح Alt-Svc للأصل إعلان مضيف أو منفذ أو بروتوكول آخر كخدمة بديلة. وقد يختار العميل ذلك المسار بعد 421. لكن الإعلان لا يلغي فحوص السلطة ولا يغيّر Origin Set من تلقائه.

يقدم DNS دليلاً على الوصول. وتقدم الشهادة دليلاً على الهوية. ويسمي Alt-Svc بديلاً. ويصف ORIGIN نية استخدام اتصال. ويعرف المستقبل السياق الذي اختير فعلاً. لكل إشارة ادعاء محدود.

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

غيّر HTTP/3 النقل وأبقى الحد

حلت مواصفة HTTP/2 الحالية، RFC 9113، محل RFC 7540 وأبقت إعادة الاستخدام بين الأصول و421. ونقلت RFC 9114 HTTP إلى QUIC مع بقاء الحكم نفسه.

اتصالات HTTP/3 دائمة أيضاً ويمكن إعادة استخدامها لسلطات URI مختلفة. وقبل استعمال اتصال قائم لأصل جديد، يجب على العميل التحقق من شهادة الخادم لذلك الأصل. إذا لم تكن مقبولة مُنعت إعادة الاستخدام. وإذا كانت مقبولة، يبقى للخادم أن يعيد 421 حين لا يريد استعمال ذلك الاتصال لأصل بعينه.

يكشف هذا الاستمرار جوهر المسألة. وُلدت 421 داخل HTTP/2، ثم انتقلت إلى دلالات HTTP المستقلة عن الإصدار، وبقيت في HTTP/3. فالمشكلة ليست TCP ولا نوع إطار محدداً. تظهر كلما أمكن لقناة فعالة أن تحمل عدة أسماء بينما يملك المستقبل سياق خدمة لا يراه المرسل.

تتغير وسيلة النقل، ولا يتغير سؤال من يملك حق الإجابة عن الاسم.

يجب مراقبة الحافة المرفوضة

لا يشرح عداد إجمالي لحالات 421 سبباً. ينبغي ربط كل حالة بمخطط الهدف ومضيفه ومنفذه، وطريقة الطلب، وإصدار HTTP، ومعرف الاتصال والتدفق، والطرف البعيد، وSNI وALPN، وأسماء الشهادة، ونتيجة DNS التي دعمت إعادة الاستخدام، ومصدر Alt-Svc، وOrigin Set، والواجهة والخادم الخلفي المختارين، وصفة مُصدر 421، والاتصال التالي ونتيجته.

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

قد يكون 421 منفرد تصحيحاً سليماً لتخمين أداء متفائل. أما التكرار الذي لا يتقارب بعد تغيير الاتصال فهو علامة الخلل الدائم.

مشاركة القناة لم تكن مشاركة الحكم

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

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

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

يسجل سجل IANA لرموز حالة HTTP الحالة 421 باسم Misdirected Request ويحيل إلى RFC 9110. يثبت التسجيل اسماً ومرجعاً صالحين للتشغيل البيني، لكنه لا يثبت معدل الاستخدام، ولا أن كل عميل يعيد المحاولة، ولا صحة إعداد أي منظومة بعينها.

كان الاتصال حقيقياً، وكان الأصل الثاني حقيقياً. الذي لم يكن حقيقياً هو تفويض الاتصال الأول لتمثيل الثاني. سجّل 421 غياب ذلك التفويض من دون محو أي طرف.