الخلاصة

  • طلب Upgrade أو CONNECT يعرض انتقالاً محتملاً، ولا يثبت أن الخادم اختار محلل البروتوكول الجديد.
  • إذا رُفض الطلب، فقد تُقرأ البيانات التي أرسلها العميل مبكراً بوصفها HTTP/1.1، لا بوصفها بداية القناة التي توقعها.

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

تحدد RFC 9931 العلامات اللازمة بوضوح. قبول Upgrade يظهر في 101 Switching Protocols، وقبول CONNECT في استجابة ناجحة من فئة 2xx. اكتمال الطلب شرط سابق كي يبدأ العميل بروتوكولاً محدثاً، لكنه ليس شرطاً كافياً. هذه ليست دقة لغوية؛ إنها حدود اختصاص بين من أرسل البايتات ومن يملك تفسيرها.

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

وتشتد المسألة حين يحمل عميل موثوق لدى الخادم محتوى اختاره طرف غير موثوق. قد ينقل متصفح مساراً أو رؤوساً أو محتوى مصدره أصل آخر؛ وقد يمرر عميل وكيل payload من تطبيق محلي. فإذا دُفع ذلك المحتوى قبل 2xx لطلب CONNECT ثم رفض الوكيل النفق، فقد يقرأه الوكيل ضمن قواعد HTTP/1.1 الباقية. تصف RFC 9931 تهريب الطلبات واستغلال افتراضات المحلل بوصفهما مخاطرتين مشروطتين. وهي لا تثبت حادثة في شبكة بعينها ولا تصف كل إرسال مبكر بأنه هجوم ناجح.

يضع تحديث connect-udp حدّاً دقيقاً لهذا النوع من التحسين. الإرسال المتفائل لحزم UDP مسموح مع HTTP/2 أو الأحدث فقط؛ أما مع HTTP/1.x فهو ممنوع بسبب خطر تهريب الطلبات. ولا يعني ذلك أن HTTP/2 يثبت الوجهة أو التسليم أو صلاحية المستخدم أو نتيجة الخدمة. إنه قرار محدود بألا تُنقل كلفة غموض المحلل في HTTP/1.x إلى الطرف الذي يتلقى البايتات.

وبالمثل، على عميل الوكيل الذي يرسل CONNECT نيابةً عن عملاء TCP غير موثوقين أن ينتظر 2xx قبل تمرير payload، أو أن يرسل Connection: close. وعلى خادم الوكيل، بعد رفض CONNECT، إغلاق الاتصال الأساسي قبل معالجة أي طلب لاحق. هذه ضوابط لترتيب الأدلة: من وفر المحتوى، من قرر الانتقال، أي محلل بقي فعالاً، ومن يملك قرار الفعل التالي. وهي ليست شهادة بأن الاتصال مصادق عليه أو أن الإجراء اللاحق جائز.

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

المصادر