الخلاصة

  • احتاج مشروع marketplaceMCI عام 1994 إلى إبقاء بيانات الطلب والفوترة والشحن بين طلبات الويب. رفضت MCI اقتراح Netscape الأول بتخزين الحالة على الخادم، واشترطت حفظها على جهاز العميل.
  • حوّلت Netscape هذا الشرط إلى ميزة عامة في المتصفح: يرسل الخادم قيمة حالة، ثم يعيدها المتصفح في طلبات لاحقة ضمن نطاقها. لكن القيمة وحدها لا تثبت هوية الشخص الذي يستخدم المتصفح.
  • حاول RFC 2109 عام 1997 وضع قواعد لآلية كان التنفيذ والتوافق قد شكّلاها بالفعل. وأقرت قواعده بحدود تحكم المستخدم، وإمكان قراءة القيم، وانعدام الحماية أثناء النقل.

عربة التسوق جعلت نسيان البروتوكول مشكلة منتج

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

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

يظهر خيار التصميم في سجل قضائي لاحق، لا في حكاية عن مخترع منفرد. ففي اجتماع يوم 10 أغسطس 1994، رفضت MCI اقتراح Netscape الأول بحفظ الحالة على الخادم. واشترطت تخزين المعلومات على حاسوب العميل. ووصفت المحكمة الاتفاق على هذا الشرط العام بأنه غير متنازع عليه، مع تسجيل الخلاف على بعض التفاصيل التقنية.

غيّر الشرط مكان الذاكرة القصيرة الأجل للتطبيق. فالمتصفح سيحتفظ بكائن صغير للحالة بين اتصالاته بالخادم. وتولى مبرمج Netscape، Lou Montulli، معالجة المشكلة. وذكر لاحقاً أنه طُلب منه في صيف ذلك العام ابتكار طريقة لعربة تسوق تعالج طبيعة HTTP الخالية من الجلسات، لكنه لم يتذكر أن MCI كانت العميل المعني تحديداً. وشهد Marc Andreessen بأن مشروع MCI أفضى في النهاية إلى ملفات Cookie، وأن Netscape عممت الميزة. تربط هذه الإفادات حاجة العميل بقرار المنتج، من دون أن تجعل كل تفاصيل التصميم يقينية.

صار المتصفح حاملاً لحالة التطبيق

تشرح النسخة المحفوظة من مواصفات Netscape الآلية ببساطة. يرفق الخادم كائن حالة برد HTTP، ويحفظه المتصفح ثم يعيده في طلبات لاحقة تطابق عناوينها نطاق ملف Cookie. يختار تطبيق الخادم القيمة ويحدد معناها؛ أما المتصفح فيحفظها ويرسلها مجدداً.

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

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

تضع المحكمة مسودة شيفرة ملفات Cookie في مستودع Netscape في 3 أو 4 أكتوبر 1994، مع تغييرات لاحقة في يومي 6 و13 أكتوبر. واختلف طرفا الدعوى حول التاريخ الدقيق لاكتمال التطبيق العملي. لذلك يكون التسلسل الأكثر تحفظاً هو: حاجة عميل وتصميم خلال الصيف، ثم شيفرة في أوائل أكتوبر بحسب السجل القضائي، ثم تعميم الميزة في متصفح Netscape. لا يوجد يوم اختراع واحد متفق عليه.

جاء المعيار بعد اقتراح المتصفح

في فبراير 1997 نشر David Kristol وMontulli وثيقة RFC 2109 بعنوان «آلية إدارة الحالة في HTTP». وشرحت حقلي الاستجابة Set-Cookie والطلب Cookie، وحاولت تثبيت صياغتهما. كما خصصت قسماً تاريخياً للتوافق مع اقتراح Netscape الأصلي. كان التوحيد القياسي يتطلب التعامل مع شيفرة وسلوك متداولين بالفعل.

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

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

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

المصادر وحدود الأدلة