الخلاصة

  • حدّد RFC 2965 في أكتوبر 2000 مسار ترقية: يواصل العميل الذي يدعم الأسلوبين إرسال قيمة التعريف القديمة في Cookie عند الاقتضاء، ويعلن فهمه للإصدار الجديد في Cookie2: $Version="1". ويمكن للخادم المستعد أن يرد عبر Set-Cookie2.
  • منح Set-Cookie2 الخادم خيار Port لتقييد المنافذ التي يعود إليها التعريف، وخيار CommentURL لإتاحة شرح استخدامه. الإعلان عن القدرة ليس دليلاً على انتقال الخادم، ووجود رابط شرح لا يثبت أن إنساناً فتحه أو وافق عليه.
  • RFC 6265 الصادر في أبريل 2011 ألغى RFC 2965 وطلب نقله إلى الحالة التاريخية، وعدّ Cookie2 وSet-Cookie2 متقادمين. ووضع Cookie وSet-Cookie، كما جرى استعمالهما فعلاً، في مركز المعيار الجديد.

إعلان القدرة ليس تبادلاً للبيانات

يحتاج الموقع إلى تمييز طلب عن طلب آخر. يرسل الخادم تعريفاً صغيراً، ويعيده المتصفح في زيارة لاحقة تنطبق عليها شروط الإرسال. سبقت هذه الفكرة محاولة الترقية: فقد وصف RFC 2109 في فبراير 1997 تبادل الحالة في HTTP. المشكلة التي واجهت مصممي البروتوكول سنة 2000 كانت جماعية. كيف يتحدث متصفح جديد مع خادم جديد بينما يظل ملايين المشاركين الآخرين على لسان أقدم؟

جاء جواب RFC 2965 على شكل إشارة قدرة. العميل الذي يعرف القواعد الجديدة والقديمة يرسل Cookie2: $Version="1" ليقول للخادم إنه يستطيع التعامل مع النسخة الجديدة. ويواصل إرسال Cookie حين يعيد تعريفاً وصله بالطريقة القديمة. إذا فهم الخادم الإشارة، يستطيع استخدام Set-Cookie2 في الرد. وإذا لم يفهمها، يتجاهلها؛ ويبقى المسار المألوف صالحاً. هكذا لا يضطر كل خادم إلى الترقية في اللحظة التي يترقى فيها المتصفح.

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

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

لماذا أراد المصممون طريقاً جديداً؟

قدّم المسار الجديد ضوابط محددة. من بينها خاصية Port في Set-Cookie2. إذا غابت الخاصية، أمكن أن يعود التعريف إلى أي منفذ مناسب على المضيف نفسه. إذا حضرت فارغة، اقتصر الإرجاع على المنفذ الذي تلقى منه العميل التعريف. وإذا ضمت قائمة، اقتصر الإرجاع على المنافذ المذكورة. لخدمتين تعملان على مضيف واحد، كان ذلك وسيلة لكتابة حد أدق من الحد الذي يحدده اسم المضيف وحده.

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

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

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

سنة 2011: المعيار يتبع الحركة على الطريق

في RFC 6265 الصادر في أبريل 2011 تبدّل مركز الثقل. قال واضعوه إن الأوصاف السابقة، ومنها RFC 2109 وRFC 2965، لم تصف الاستعمال الفعلي للتعريفات على الإنترنت بالقدر الكافي. حددوا طريقة إصدار الخادم لـSet-Cookie ومعالجة العميل لـCookie مع اهتمام خاص بالتوافق مع الخوادم القائمة. صار العقد المكتوب يصف حركة المرور الجارية بدلاً من انتظارها عند مخرج الترقية.

وجاء القرار الإداري بوضوح مماثل. ألغت الوثيقة RFC 2965، وطلبت نقلها مع RFC 2109 إلى الحالة التاريخية، وأعلنت تقادم Cookie2 وSet-Cookie2. يسجل قسم تسجيل الحقول الاسمين بوصفهما ملغيين. انتهى دور شارة القدرة وحقل الرد المرافق لها في وصف الويب المعتمد سنة 2011.

لم تمنح العودة إلى الاسمين الشائعين حدوداً مثالية. تذكر وثيقة 2011 بنفسها مشكلات أمن وخصوصية في نموذج التعريفات الجاري. وهي تشير إلى أن التعريفات الخاصة بمضيف واحد تشترك بين منافذه، بينما تفصل قاعدة الأصل في المتصفح عادة محتوى منفذ عن محتوى منفذ آخر. هنا تظهر قيمة الحد الذي حاولت خاصية Port في سنة 2000 التعبير عنه. اختيار وصف الممارسة السائدة لم يجعل كل تفاصيل الممارسة مريحة.

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

حين يصبح التوافق إقامة دائمة

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

في الويب الموزع لا يملك محرر المواصفة مفتاح نشر واحداً. الخادم يختار حقل رده، والمتصفح يختار ما يعلنه وما يخزنه، والتطبيقات تبنى فوق السلوك الذي تجده متاحاً. يستطيع النص أن يرسم جسراً؛ عبور الجسر قرار آلاف الإصدارات. بعد أحد عشر عاماً دوّن RFC 6265 أين انتهت الحركة. خرج Cookie2 ليعلن أن الباب الجديد مفتوح، ثم صار الباب نفسه قطعة من تاريخ البروتوكول.