الخلاصة

  • عرّف RFC 2068 رقم إصدار HTTP باعتباره تصريحاً عن تنسيق الرسالة والحد الأقصى لقدرة مُرسِلها على فهم التخاطب اللاحق، لا قائمةً بالميزات التي استُخدمت فعلاً.
  • عندما يفسر الوكيل رسالة ثم ينشئ رسالة للوصلة التالية، يصبح هو المُرسِل ويجب أن يعلن إصداراً يطابق قدرته هو، لا قدرة العميل السابق.
  • سمح التطور داخل الإصدار الرئيسي الواحد بحقوق جديدة بشرط أن يبني المُرسِل الأحدث رسالة تبقى صالحة للمستقبِل الأقدم إذا أزيلت الحقول التي لا يعرفها.

الرقم الذي لا يصف كل ما حدث

ظهرت صياغة سياسة الإصدارات قبل HTTP/1.1. فقد وثّق RFC 1945 في مايو/أيار 1996 الاستخدام الشائع لـ HTTP/1.0، وميّز بين الخصائص التي نُفذت بصورة متسقة وتلك النادرة أو غير المتسقة. كان الاسم الواحد يغطي واقعاً تنفيذياً غير متجانس؛ لذلك لم يكن ممكناً أن يعمل الرقم كجرد دقيق لكل ميزة في كل برنامج.

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

حافظ RFC 2068، المنشور في يناير/كانون الثاني 1997، على هذا الفصل وجعله التزاماً أوضح. فالطلب أو الاستجابة المعرّفان وفق تلك المواصفة يكتبان HTTP/1.1 في سطر البداية. ويعني هذا الإعلان أن التطبيق المُرسِل متوافق، على الأقل بصورة مشروطة، مع المواصفة. وإصدار التطبيق هو أعلى إصدار يستطيع أن يحقق له ذلك المستوى من التوافق.

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

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

الوكيل يتكلم بصوته لا بصوت العميل

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

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

جاء RFC 2145 في مايو/أيار 1997 لأن المقصود بأرقام الإصدار أثار التباساً وجدلاً ومشكلات في قابلية التشغيل البيني. وقد لخّص القاعدة بوضوح: أرقام إصدارات HTTP مكوّنات تخص كل وصلة، وليست خصائص من طرف إلى طرف. لا «يمرر» الوكيل رقم الطلب أو الاستجابة كما لو كان ملكاً للرسالة الأصلية.

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

حق التجديد مشروط برسالة يمكن أن تفقد الجديد

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

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

اختبار الحذف هذا يضع كلفة الابتكار على مَن اختار الخاصية الجديدة. ليس مطلوباً من التطبيق القديم أن يتنبأ بالمستقبل؛ المطلوب من التطبيق الجديد أن يترك بعد زوال إضافته نواة قديمة مكتملة. ولهذا لا يجوز مثلاً لخادم HTTP/1.1 أن يرسل استجابة تعتمد على Transfer-Encoding: chunked لطلب HTTP/1.0 ثم يتوقع من العميل أن يتجاهل اسم الحقل وحسب. حذف المعلومة في تلك الحالة يفسد تأطير جسم الرسالة نفسه.

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

وثيقة التوضيح جزء من التاريخ وليست إحصاءً

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

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

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

في 1999 أبقى RFC 2616 على هذا الفصل وأحال صراحة إلى RFC 2145. وفي 2014 صاغ RFC 7230 بصورة أوضح أن الرقم الفرعي يعلن قدرة تخاطب مستقبلية حتى إذا استخدمت الرسالة الحالية مجموعة متوافقة إلى الوراء فقط. وسجل أيضاً أن الانتقال من RFC 2068 إلى RFC 2616 لم يرفع الرقم الفرعي. مراجعة الوثيقة، وتغيير الالتزام، وتغيير الإشارة على السلك أحداث مختلفة.

ثم فصل RFC 9110 في 2022 دلالات HTTP المشتركة عن صيغ الرسائل الخاصة بـ HTTP/1.1 وHTTP/2 وHTTP/3. هذه الإصدارات الرئيسية تتعايش ولا ينبغي إسقاط آلية الرقم الفرعي في HTTP/1.1 آلياً على تفاوضها وصيغها المختلفة. وعندما يعيد وسيط توجيه رسالة، يصبح الإصدار هو البروتوكول الذي استخدمه ذلك الوسيط في تلك الوصلة، بينما يؤدي Via وظيفة سجل مختلفة عن التصريح الحالي.

بين نشر المواصفة وتشغيل القدرة

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

هذه مقارنة بأثر رجعي، وليست دليلاً على أن مؤلفي HTTP توقعوا أفكار Lu Heng المؤسسية أو المتعلقة بالسجلات الموزعة أو أيدوها. فائدتها هنا أضيق: إبقاء RFC المنشور، ورقم الإصدار المعلن، والبرنامج المثبت، والميزة المستخدمة، والعملية المكتملة كطبقات إثبات منفصلة.

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

المصادر