الخلاصة

  • كانت RFC 2774 تحول GET إلى M-GET وPUT إلى M-PUT عند وجود امتداد إلزامي، كي يرفض الخادم غير المدرك للإطار طريقة مجهولة بدلاً من إسقاط الشرط وتنفيذ العملية الأساسية.
  • كان المستقبِل المتوافق يعيد 510 حين يعجز عن استيفاء سياسة الامتداد، ويستخدم Ext أو C-Ext لإثبات تنفيذ الإعلانات الإلزامية؛ ثم نُقلت التجربة إلى Historic وصارت الحالة والحقول المرتبطة بها متقادمة.

نجاح في الأسلاك وفشل في العقد

لنفترض أن عميلاً يرسل مستنداً بطريقة PUT، لكنه يشترط أن يطبق امتداد جديد قيداً إضافياً. يقرأ الخادم الحديث الإعلان ويطبق القيد ثم يحفظ المورد. أما الخادم القديم فيفهم PUT وحدها، ويتجاوز الحقول غير المعروفة، ويحفظ البايتات نفسها من دون القيد. يستطيع الاثنان إعادة 200 OK.

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

نُشرت RFC 2774 في فبراير 2000 بوصفها Experimental، واقترحت عدم السماح لهذا الالتباس بالاختباء. الطلب ذو الامتداد الإلزامي لا يستخدم اسم الطريقة المعتاد، بل يضيف السابقة M-. من لا يعرف الإطار يرى M-PUT لا PUT، فيفشل قبل أن ينفذ نسخة ناقصة من قصد المرسل.

عدم التوافق كحد وقائي

المستقبِل الذي يعرف الإطار لا يحذف السابقة مباشرة. عليه أولاً تحديد كل الإعلانات الإلزامية، والتحقق من قدرته على تطبيقها على الرسالة، ثم إعادة 510 Not Extended إذا غاب الدعم عن أي منها. لا ينفذ دلالات الامتدادات والطريقة الأساسية إلا بعد اجتياز هذه الخطوات.

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

القوة والنطاق في أربع قنوات

قسم الإطار الإعلانات وفق محورين. يمكن أن يكون الامتداد إلزامياً أو اختيارياً، وأن يعمل من الطرف إلى الطرف أو في وصلة واحدة. نتجت الحقول Man وOpt وC-Man وC-Opt.

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

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

ما الذي كان يعنيه 510 تحديداً؟

لم يكن 510 عطلاً عاماً في الخادم. وصفه القسم السابع بأنه عدم استيفاء سياسة الوصول الخاصة بالمورد. ينبغي للاستجابة أن تقدم المعلومات اللازمة لصياغة طلب موسع يمكن قبوله.

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

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

النجاح احتاج إلى إقرار مستقل

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

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

أين يمكن أن يضيع المعنى؟

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

لهذا استخدمت RFC 2774 ‏Cache-Control: no-cache="Ext" في استجابة استوفت طلباً إلزامياً نهائياً. وأضافت قيمة Expires منتهية مسبقاً للتعامل مع وكلاء HTTP/1.0. وإذا اختلفت الاستجابة وفق حقل ذي سابقة رقمية، وجب أن يذكر Vary ذلك الحقل وحقل الإعلان الذي يمنحه معناه.

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

من Experimental إلى Historic

بدأت الوثيقة بتحفظ رسمي. أوضحت ملاحظة IESG أنها طُلبت أصلاً كـProposed Standard، لكن الآراء المختلطة وغياب توافق واضح حول تطور HTTP أديا إلى نشرها كتجربة. لم تقل الملاحظة إن ذلك يثبت عيباً تقنياً، وحذرت من اعتبارها مخططاً عاماً لكل امتدادات HTTP.

في 2021، وافقت IETF على نقل RFC 2774 وتجارب HTTP أخرى إلى Historic. يقول السجل إن التجارب انتهت وإنه لا يوجد دليل على استخدام واسع. تسجل IANA اليوم 510 باسم Not Extended (OBSOLETED)، وتضع Man وOpt وC-Man وC-Opt وExt وC-Ext في حالة obsoleted.

لا تقيس المصادر حجم الانتشار ولا تثبت سبباً وحيداً للمآل. إنها تثبت قرار دورة الحياة: الآلية العامة لم تعد جزءاً من ممارسة HTTP الحالية.

بقيت قابلية التمديد بطريقة أخرى

ما زالت RFC 9110 تصف نقاط تمديد دائمة للطرق ورموز الحالة وأسماء الحقول ومخططات المصادقة وتوجيهات التخزين المؤقت. تمنح السجلات الواضحة وسياسات المراجعة هذه الأسماء معانيها وحالتها، من دون إعادة مصفوفة RFC 2774.

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

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

المصادر