الخلاصة

  • أظهر RFC 2295 التمثيلات المرتبطة بعنوان URI واحد عبر قائمة متغيرات قابلة للقراءة آلياً، لكن استجابة القائمة لم تتضمن بيانات أي متغير.
  • ظل الاختيار والجلب والعرض مراحل منفصلة؛ إذ أمكن للخادم إعادة التمثيل المختار ضمن شروط محددة، كما أمكن للعميل اختيار متغير معلن وطلبه بنفسه.

المورد الواحد قد يملك أكثر من إجابة

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

قدم RFC 2295، «التفاوض الشفاف على المحتوى في HTTP»، آلية تجريبية تجعل البدائل مرئية. سمّت مذكرة مارس 1998 كل نسخة «متغيراً»، وربطت أوصافاً مقروءة آلياً بقائمة تخص مورداً قابلاً للتفاوض. وكان حقل Alternates قادراً على إيراد URI لكل خيار وخصائص مثل نوع الوسيط واللغة وجودة المصدر والميزات. وتعني «الشفافية» هنا أن المتغيرات الموجودة داخل خادم المصدر باتت مرئية للأطراف الخارجية؛ لا أن جميع المتصفحات تتفاوض تلقائياً أو أن عملية الاختيار تختفي عن الأنظار.

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

ثلاثة سجلات، لا واقعة واحدة

استجابة القائمة جردٌ للخيارات. يعرّفها RFC 2295 بأنها تعيد قائمة المتغيرات من دون بياناتها. يستطيع وكيل مستخدم يدعم التفاوض الشفاف تقييم الخيارات ثم جلب أحدها بطلب HTTP عادي إلى URI الخاص به. ويفصل مثال الوثيقة الخطوتين بوضوح: يعيد الخادم القائمة أولاً، ثم يطلب العميل paper.1، والاستجابة الثانية وحدها تحمل الورقة. وقد تتضمن استجابة 300 Multiple Choices نصاً يتيح الاختيار اليدوي، سواء لمستخدم أو لوكيل لا يتفاوض. ومع ذلك تبقى القائمة غير التمثيل المختار.

لم يكن الخادم مجرد أمين فهرس. فـ«استجابة الاختيار» (choice response) تعيد تمثيل أفضل متغير، ويمكنها أيضاً إرفاق القائمة. لكن ذلك يتطلب معلومات كافية كي يختار الخادم نيابة عن وكيل المستخدم، كما يجب أن يحقق المتغير شرط الجوار في URI الذي حددته الوثيقة. وجاء RFC 2296، وهو مذكرة تجريبية مرافقة، بخوارزمية للاختيار عن بُعد وجعل النتيجة مشروطة: إذا لم تثبت الأدلة وجود أفضل متغير بجودة إيجابية ومحددة، أو أخفق شرط الجوار، أعادت الخوارزمية قائمة لا استجابة اختيار. وكان بوسع العميل تطبيق خوارزميته المحلية وجلب خيار آخر إذا بقيت القائمة متاحة.

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

كانت الذاكرة المخبأة جزءاً من التصميم

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

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

نص RFC 2295 بوضوح على أنه Experimental، وأنه لا يحدد معياراً للإنترنت. واقتصرت آليته على طلبي GET وHEAD، لا على كل معاملات HTTP. يمكن استعادة طموح الوثيقة من نصها: إتاحة فحص البدائل وتوزيع الاختيار بين العملاء والخوادم والذاكرات المخبأة. لكن المصادر المتاحة هنا لا تثبت تعداداً لدعم المتصفحات أو معدل انتشار أو نتيجة ملموسة للمستخدمين. فالمتغير المعلن قد لا يُجلب، واستلام استجابة لا يثبت ما رآه شخص على الشاشة.

المصادر