الخلاصة

  • يوصي RFC 9111 بأن تصاحب no-store الاستجابة التي تحمل must-understand. المخزن الذي لا يعرف التعليمة الجديدة يتجاهلها، لكنه يظل قادراً على اتباع القاعدة المحافظة القديمة.
  • لا يعني «الفهم» قراءة اسم التعليمة أو التعرف إلى ثلاثة أرقام. بل يعني معرفة رمز الحالة وتنفيذ كل السلوك المتعلق بالتخزين المؤقت الذي تحدده مواصفاته.
  • تجاهل no-store المشروط يزيل حاجزاً واحداً فقط. تبقى قواعد الطريقة والتفويض والذاكرة المشتركة وقابلية التخزين والحداثة وإعادة الاستخدام مستقلة، ولا تنشأ أي ضمانة للخصوصية.

استجابة واحدة لجيلين

لنتصور أن مخزنين وسيطين استقبلا Cache-Control: must-understand, no-store.

نُشر الأول قبل ظهور must-understand. تفرض قواعد توسيع Cache-Control عليه تجاهل أي تعليمة لا يتعرف إليها. لذلك يتجاوز التعليمة الأولى، ثم يرى no-store التي يعرفها ويمتنع عن حفظ الاستجابة.

أما الثاني فينفذ must-understand. ومع ذلك لا يحصل فوراً على إذن بالتخزين. يجب أن يتعرف إلى رمز الحالة، وأن يكون قد طبق جميع أحكام التخزين المؤقت الخاصة بذلك الرمز. عندئذ فقط يوصي RFC 9111 بأن يتجاهل no-store المصاحبة، ثم يختبر بقية شروط التخزين.

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

تبدأ المشكلة حين تختصر وثيقة التشغيل الآلية في must-understand وحدها. يوحي الاسم بأمر شامل، مع أن المخزن الذي لم ينفذها ملزم بتجاهلها. ومن دون no-store لا تصل إليه خطة التراجع المقصودة. وحدة النشر الحقيقية هي الزوج، ودليل الأهلية هو السلوك المنفذ لا ظهور الكلمة في الرأس.

التعرف لا يساوي الفهم

يعرف RFC 9111 «فهم» رمز الحالة تعريفاً عملياً: أن يتعرف المخزن إلى الرمز وأن ينفذ كل ما تحدده مواصفاته من سلوك متعلق بالتخزين المؤقت.

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

يوضح اختلاف المواصفات السبب. يقرر RFC 6585 عدم تخزين الاستجابات ذات الرموز 428 و429 و431 و511. في المقابل، يعرّف RFC 7538 الاستجابة 308 Permanent Redirect بأنها قابلة للتخزين افتراضياً ما لم تمنعها دلالة الطريقة أو ضوابط صريحة. لا تمثل هذه الأمثلة قائمة كاملة، لكنها تظهر أن أحكام الرموز قد تتباين جوهرياً.

إذا كان منتج يعرض اسم 429 صحيحاً لكنه يحتفظ بالاستجابة كمدخل عادي، فهو يتعرف إلى الرمز من دون أن يفهمه بالمعنى المطلوب. وكذلك فإن اختبار محلل must-understand وحده يثبت سلامة الصياغة، لا مطابقة السلوك.

ينبغي للسجل القابل للتدقيق أن يفصل خمس حقائق: الرمز المستلم، والتعرف إليه، وتنفيذ قواعده، ودعم التعليمة نفسها، ونتيجة بقية شروط التخزين وإعادة الاستخدام. تحويلها إلى خانة واحدة باسم «مدعوم» يجعل الشرط شهادة ذاتية.

المنع القديم هو الذي يؤمن المسار الجديد

يجب على الذاكرة الوسيطة تجاهل تعليمات التخزين غير المعروفة حتى لا تكسر الإضافات البرامج المنشورة. يشرح RFC 9111 نمط الإضافات السلوكية: تُرسل التعليمة الجديدة مع قاعدة قديمة؛ فيتبع غير العارف السلوك القديم، ويفهم العارف كيف تعدل الجديدة المتطلبات السابقة.

في هذا الزوج تمثل no-store المكبح القديم. لا تناقض must-understand، بل تصنع النتيجة المحافظة الافتراضية. يعرف المخزن المؤهل الشرط الضيق الذي يتيح له رفع ذلك المكبح.

ولحذفها أثر حقيقي. إذا أرسل الخادم must-understand وحدها، تجاهلها المخزن القديم ولم يتلقَّ إشارة التراجع. قد يمتنع عن التخزين لسبب آخر، لكن آلية الانتقال لم تعد هي التي تحمي المسار.

يستخدم النص المعياري SHOULD لإضافة no-store وكذلك لتجاهلها عند تحقق الشروط. إنها توصية معيارية قوية لا أمراً مطلقاً ولا تفصيلاً اختيارياً. من يخرج عنها يحتاج إلى تفسير تقني لكيفية تصرف المشاركين القدامى.

إزالة منع لا تحقق سائر الشروط

لا تعني عبارة «تجاهل no-store» أن «خزّن الاستجابة». الاستثناء يزيل قيداً واحداً فحسب.

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

ثم تأتي إعادة الاستخدام كقرار مستقل. يجب أن يطابق المدخل الطلب الجديد وأن يكون حديثاً أو قد اجتاز التحقق أو يجوز تقديمه بعد انتهاء حداثته. لا يصنع must-understand حداثة، ولا ينفذ تحققاً، ولا يصلح مفتاحاً يخلط بين المستخدمين.

لذلك لا يكفي سجل يقول must_understand=true. المطلوب هو الرمز ومرجعه، وإصدار التنفيذ والاختبار، ووجود التعليمتين، ونتيجة بقية الشروط، وقرار التخزين الفعلي، ثم أي إعادة استخدام لاحقة.

السجل العام إحداثية لا شهادة مطابقة

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

ظهور must-understand في جدول لا يثبت تنفيذها في ملف ثنائي. وتسجيل رمز لا يثبت أن وحدة التخزين تطبق قواعده. ولا يجوز تعميم نجاح اختبار رمز واحد على رموز مستقبلية.

تحتاج القدرة إلى ملف إثبات صغير: إصدار المحرك والوحدة، والمواصفة المعتمدة، والمتطلبات المختبرة، والنتيجة. توفر التعليمة نقطة تفرع قابلة للتشغيل البيني، لكنها لا تنتج هذا الإثبات.

يشير سجل تغييرات RFC 9111 إلى أن must-understand أضيفت كي لا تُلزم الذاكرات بفهم معاني رموز الاستجابة الجديدة إلا عند وجودها. يستطيع الخادم أن يقول إن القواعد الخاصة مهمة لهذه الاستجابة، لكنه لا يستطيع إعلان وسيط بعيد مجهول مؤهلاً.

ليست ختماً للخصوصية

ينبه RFC 9111 إلى أن no-store ليست وسيلة موثوقة أو كافية لضمان الخصوصية. قد تعصيها ذاكرة خبيثة أو مخترقة، وقد تتعرض الشبكة للتنصت. لا يوسع اقترانها بـmust-understand هذا الوعد.

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

لم تختبر هذه الدراسة مورداً تجارياً، ولم تقس الانتشار أو التسرب أو الحوادث. المسارات أمثلة تحليلية مشتقة من النصوص العامة.

المصادر وحدود الدليل

تمثل السجلات والتصويبات لقطة عند تاريخ البحث. تثبت المصادر دلالة البروتوكول وقراءة الحوكمة، لا دعوى الدعم الشامل في المنتجات.