الخلاصة

  • وحّدت RFC 2109 حقلي Set-Cookie وCookie لبناء جلسة منطقية من طلبات واستجابات HTTP منفصلة، مستقلة عن الاتصال الشبكي الدائم.
  • حدّدت Domain وPath وMax-Age وSecure وقواعد التخزين المؤقت حركة الحالة، وطالبت بتحكم المستخدم وقيّدت الطلبات التلقائية المضمّنة أو المعاد توجيهها.
  • أثبتت إعادة القيمة أن وكيل المستخدم اختار حالةً وفق القواعد، لا أن الشخص الحالي معروف أو موافق أو مخوّل، ولا أن الأمر حديث أو نجح أثره.

الجلسة لم تكن اتصالاً مفتوحاً

توضح RFC 2109 أن الجلسة سياق منطقي، لا اتصالاً شبكياً مستمراً. يستطيع الاتصال أن ينتهي وتستمر الجلسة عبر اتصال آخر، كما يستطيع الاتصال أن يبقى بينما يرفض الخادم جلسة قديمة. يبدأ الأصل بـ Set-Cookie، وقد يواصل وكيل المستخدم بـ Cookie، ويستطيع الطرفان الإنهاء، ويطلب Max-Age=0 الحذف.

بهذا بقيت ثلاثة سجلات مستقلة: حالة النقل، والحالة المحفوظة في المتصفح، وقرار الخادم بقبول الجلسة. لا يثبت أي واحد منها الاثنين الآخرين.

اسم العميل كان تفسيراً من التطبيق

في المثال تتراكم Customer وPart_Number وShipping. تعيدها قواعد الاختيار عندما يطابق المسار. هذا يثبت الإصدار والحفظ والاختيار، لكنه لا يعيد توثيق من يمسك الجهاز، ولا يؤكد أن خيار الشحن ما زال قراراً حالياً، ولا أن استجابة HTTP تعني دفعاً أو شحناً أو تسليماً.

كانت القيمة معتمة لوكيل المستخدم، مع أنها قد تكون مقروءة لمن يفحص الحقل. طبقت Domain قواعد المطابقة التاريخية، واختارت Path بادئات URI، وحددت Max-Age عمراً مقصوداً، وعرّفت Version=1 النسخة. وقد تظهر ملفات بالاسم نفسه مع مسارات مختلفة. هذه قواعد إرسال، وليست قواعد سرية أو صلاحية مؤسسية.

Secure نصيحة لا توقيعاً

وصف Secure وسيلةً آمنة، لكنه ترك لوكيل المستخدم تحديد مستوى الأمان المناسب. لم يشفر الحقل بذاته، ولم يثبت الشخص أو يربط أمراً بتفويض حديث. وحذّر قسم الأمن بصورة منفصلة من قراءة الحقول النصية أو تغييرها في الطريق.

سواء حمل الملف نصاً واضحاً أو مفتاح قاعدة بيانات، بقي على التطبيق أن يتحقق من المعنى والحالة. وجود القيمة ليس سلامةً، والسلامة وحدها ليست تفويضاً.

الذاكرة لم تلغ التخزين المؤقت

فصل الحالة عن URL ومحتوى الوثيقة كان ضرورياً للحفاظ على فائدة الذاكرات الوسيطة. يمكن إعادة استخدام المحتوى العام، بينما لا ينبغي حفظ محتوى جلسة خاصة في ذاكرة مشتركة. تمرر الوسائط حقول Cookie وتحترم الصلاحية وprivate وno-cache="set-cookie".

لذلك فوجود تمثيل مخزن، وصدور Set-Cookie، وقبول المتصفح للحالة، وقبول الأصل للجلسة لاحقاً أربع وقائع. وفّرت RFC 2068 مفردات HTTP/1.1 المعاصرة. أما ذاكرات HTTP/1.0 فلم تملك دوماً وسيلة عامة لاستثناء حقل بعينه، ما سمح بخطر تخزينه.

الإعادة التلقائية كانت مشكلة خصوصية منذ البداية

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

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

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

أكدت RFC 2964 لاحقاً الموافقة المستنيرة. واستبدلت RFC 2965 RFC 2109 بعد خبرة التنفيذ. ثم وثّقت RFC 6265 الممارسة المنتشرة، وينتمي نص مراجعة المؤلفين لـ RFC 10025 إلى جيل أحدث. تعاقب الوثائق لا يثبت انتقال أي متصفح بعينه.

إيصال حالة ضمن سلسلة أدلة

يجب فصل الأفعال: أصدر الخادم؛ قبل الوكيل؛ احتفظ المستخدم؛ اختار السياق؛ قبل الخادم الجلسة؛ أجازت السياسة؛ ثُبتت العملية؛ ولوحظ الأثر. يتحدث Cookie عن جزء واحد فقط.

تعيد Running-Code Primacy للـ Lu Heng الادعاء إلى التنفيذ الفعلي. وتحصر Minimum Initial Specification الطبقة المشتركة في الحد الأدنى. وتمنع Reality Layers سجلاً رمزياً من استعارة سلطة سجل آخر. وحّدت RFC 2109 الذاكرة، لا هوية الإنسان ولا تفويضه.

المصادر