الخلاصة

  • تتيح RFC 9110 للعميل أن يرسل Upgrade ليدعو إلى تغيير البروتوكول على الاتصال نفسه، ويجوز للخادم تجاهل الدعوة، بينما يجب على الوسيط إزالة الحقل الخاص بالاتصال قبل إعادة التوجيه العادية.
  • يبدأ إثبات الانتقال المكتمل باستجابة صالحة 101 Switching Protocols تختار بروتوكولاً عرضه العميل، ثم يربط اكتمال الطلب الأصلي بأول تبادل صالح في البروتوكول الجديد.

لنتخيل لوحة ترحيل ترى Upgrade: websocket في طلب عميل فتسجل الجلسة فوراً بوصفها «WebSocket مفعلاً». لكن وكيلاً بين العميل والخادم الأصلي يطبق ترويسة Connection ويحذف الدعوة الخاصة بهذه الوصلة. لا يراها الخادم الأصلي مطلقاً، ويرد برد عادي 200 OK عبر HTTP/1.1. لا يغير أي طرف بروتوكوله، إلا أن اللوحة تسجل نجاحاً لأنها عاملت العرض كأنه نتيجة.

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

تعرف RFC 9110 Upgrade بوصفها آلية للانتقال من HTTP/1.1 إلى بروتوكول آخر على الاتصال نفسه. يجوز للعميل إرسال قائمة مرتبة من البروتوكولات لدعوة الخادم إلى التغيير حسب التفضيل. ويجوز للخادم تجاهل الدعوة. لذلك يعبر الحقل عن الاستعداد والتفضيل، لا عن القبول أو نجاح التفاوض أو الجاهزية التشغيلية.

والدعوة خاصة بالاتصال. يجب على مرسل Upgrade أن يدرج upgrade أيضاً في Connection. تمنع هذه القاعدة الوسطاء من تمرير الخيار المستلم تلقائياً كأنه من طرف إلى طرف. يزيل الوسيط الحقول المسماة في Connection أولاً. وإذا كان الوكيل يدعم البروتوكول المطلوب واختار دعوة الوصلة التالية، فيجوز له إنشاء Upgrade جديد خاص بتلك الوصلة، ويجب أن يدرج upgrade في حقل Connection الذي ينشئه للرسالة المعاد توجيهها. لذلك لا يثبت الالتقاط عند حافة العميل أن الخادم الأصلي تلقى العرض نفسه، كما لا يثبت الالتقاط عند الأصل أن الرد وصل إلى العميل بلا تغيير. ويجب على خادم HTTP/1.0 تجاهل Upgrade إذا تلقاها.

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

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

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

تختلف هذه العدسة عن R067 بشأن اكتمال Via، وR064 بشأن Alt-Svc والمسار البديل، وStrategic Local بشأن استعادة الأولوية، وB842 بشأن ربط معرفات IPv6 المؤقتة. الحدث هنا هو تبدل بروتوكول تطبيق مرتبط باتصال واحد، ودليله إيصال مرتب للتفاوض والتبادل.

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

المصادر