الخلاصة

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

لنفترض أن لوحة تشغيل قرأت Age: 20 في استجابة إعدادات مخزنة وأظهرتها باللون الأخضر. يبدو الرقم صغيراً، لكن الاستجابة تحمل max-age=10، وتقدمها الذاكرة المؤقتة كاستجابة منتهية مسموح بها أثناء تعذر الوصول إلى الأصل. قد تكون الترويسة صحيحة بينما يكون استنتاج اللوحة خاطئاً.

تفصل RFC 9111 بين عمر الاستجابة والمدة التي تبقى خلالها حديثة. يمكن إعادة استخدام الاستجابة من دون تحقق ما دام عمرها لم يتجاوز تلك المدة، ثم تصبح منتهية. الاختبار هو freshness_lifetime > current_age. لا تحدد Age المدة المطبقة ولا تعرض وحدها حساب العمر الحالي كاملاً.

لمدة بقاء الاستجابة حديثة ترتيب أولوية. في الذاكرة المشتركة تتقدم s-maxage، ثم max-age، ثم الفرق بين Expires وDate. عند غياب انتهاء صريح يمكن استخدام تقدير استدلالي في حالات محددة، ولا تفرض المواصفة خوارزمية واحدة، لذلك قد تحسب تطبيقات متوافقة مدداً مختلفة.

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

لذلك قد تظل استجابة عمرها عشرون ثانية حديثة إذا كانت المدة ستين ثانية، وتصبح منتهية إذا كانت المدة عشر ثوان. ويمكن تقديم استجابة منتهية عند انقطاع الاتصال أو وجود إذن صريح، ما لم تمنع ذلك توجيهات مثل no-cache أو must-revalidate. صحة السلوك البروتوكولي لا تعني أن سعراً أو صلاحية وصول أو إعداداً ما زال صحيحاً للأعمال.

الحل هو سجل يوضح قرار إعادة الاستخدام. وهو تجميع تحريري للأدلة، وليس عنصراً بروتوكولياً عرّفه IETF أو RFC 9111. يربط هوية الذاكرة وإعدادها، والطلب، والاستجابة المخزنة وبصمة المحتوى المسلم؛ وDate وAge الواردة والصادرة، وأوقات الطلب والاستجابة والإقامة؛ ومصدر مدة بقاء الاستجابة حديثة، والتوجيهات الفعلية، ونتيجة التحقق، وإذن تقديم المنتهي، والقرار النهائي.

المصادر