تذكرتان وملف كوكي واحد: احتاج المتصفح إلى درجين

Summary

• عرضت مسودة W3C الأولى لـWeb Storage في 23 أبريل 2009 مشكلة حجز رحلتين عبر نافذتين للموقع نفسه. قد يجعل ملف كوكي يتذكر حجزاً «جارياً» واحداً قرار إحدى النافذتين يتسلل إلى الأخرى.
• خصص sessionStorage مساحة مرتبطة بالنافذة العليا وأصل الموقع، بينما خصص localStorage مساحة للأصل تتشاركها نوافذه وتبقى بعد الجلسة؛ ولا تنتقل قيم التخزين المحلي تلقائياً مع كل طلب HTTP.

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

هذا المشهد مأخوذ من مسودة Web Storage التي نشرها W3C في 23 أبريل 2009. تصور الوثيقة عميلاً يشتري تذكرتين في نافذتين للموقع نفسه. إذا سجّل الموقع الرحلة الجارية في ملف كوكي، فقد يتسرب قرار نافذة إلى الأخرى، وربما يشتري العميل تذكرتين للرحلة نفسها من دون أن يلاحظ. تتحدث المسودة عن مشكلة تصميمية صغيرة بحجم فاتورة حقيقية.

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

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

يحدد الأصل صاحب الدرج. لكل موقع مساحاته، ولا يستطيع موقع آخر فتحها كما يشاء. لذا لا يكفي السؤال «في أي موقع حُفظت القيمة؟» عند متابعة الحجز؛ بل يلزم أيضاً تحديد النافذة التي تجري فيها العملية. هذا الفصل يحول دون أن يصبح زرا الاختيار في شاشتين مختلفتين مفتاحاً واحداً لحجز واحد.

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

تفصل توصية الإصدار الثاني لعام 2016 طريقة التعامل مع الدرجين. تدير setItem وgetItem وremoveItem وclear المفاتيح والقيم. إذا فشلت كتابة أو إزالة، يبقى محتوى المساحة السابق؛ وقد ترمي setItem الخطأ QuotaExceededError عند نفاد الحصة أو منع التخزين. تستقبل المستندات الأخرى التي تصل إلى المساحة نفسها حدث storage عند تغييرها. المطلوب اتساق ما تراه البرامج، من دون اشتراط انتظار اكتمال الكتابة الفعلية على القرص في كل استدعاء.

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

يوضح سجل W3C الزمني انتقال الوثيقة من مسودة 2009 إلى توصيتي 2013 و2016. بقي مثال التذكرتين مفيداً لأنه يضع كل ذاكرة في مكانها: الحجز الجاري في نافذته، والمسودة طويلة العمر في أصل الموقع، وملف الكوكي في الطلب الذاهب إلى الخادم. يستطيع المسافر عندها الانشغال بالسؤال الصعب حقاً: هل تستحق الرحلة الرخيصة الاستيقاظ قبل الفجر؟