IT-Swarm.Net

ما الفرق بين Cache-Control: max-age = 0 و no-cache؟

يشير الرأس Cache-Control: max-age=0 إلى أن المحتوى يعتبر قديمًا (ويجب إعادة جلبه) على الفور ، وهو ما يسري في الواقع على نفس Cache-Control: no-cache.

581
rubyruy

كان لدي نفس السؤال ، ووجدت بعض المعلومات في عمليات البحث التي أجريتها (تم طرح سؤالك كإحدى النتائج). إليك ما قررت ...

هناك وجهان لرأس Cache-Control. جانب واحد هو المكان الذي يمكن إرساله بواسطة خادم الويب (ويعرف أيضًا باسم "خادم المنشأ"). الجانب الآخر هو المكان الذي يمكن إرساله فيه بواسطة المتصفح (المعروف أيضًا باسم "وكيل المستخدم").


عند إرسالها من قبل خادم الأصل

أعتقد أن max-age=0 يخبر ببساطة الذاكرة المخبئية (ووكلاء المستخدم) أن الاستجابة لا معنى لها من البداية ، لذاينبغيإعادة التحقق من الاستجابة (على سبيل المثال. مع عنوان If-Not-Modified) قبل استخدام نسخة مخبأة ، بينما يخبرهم no-cache أنهميجبإعادة التحقق من الصحة قبل استخدام نسخة مخبأة. من 14.9.1 ما هو قابل للتخزين المؤقت :

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

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

بمعنى آخر ، قد تختار التخزين المؤقت في بعض الأحيان استخدام استجابة قديمة (على الرغم من أنني أعتقد أنه يتعين عليها إضافة رأس Warning) ، لكن no-cache تقول أنه لا يُسمح لها باستخدام استجابة قديمة بغض النظر عن السبب. ربما تريديجب- إعادة التحقق من السلوك عند إنشاء إحصائيات البيسبول في الصفحة ، لكنك تريديجب- إعادة التحقق من السلوك عند قيامك بإنشاء الرد على شراء التجارة الإلكترونية.

على الرغم من أنك محق في تعليقك عندما تقول أن no-cache ليس من المفترض أن يمنع التخزين ، فقد يكون هناك اختلاف آخر عند استخدام no-cache. صادفت صفحة ، إزالة الغموض عن توجيهات التحكم في ذاكرة التخزين المؤقت ، التي تقول (لا أستطيع أن أؤكد صحة الأمر):

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

...

لاحظ أنه في الآونة الأخيرة ، "التحكم في التخزين المؤقت: عدم التخزين المؤقت" قد بدأ يتصرف أيضًا مثل توجيه "عدم التخزين".

جانبا ، يبدو لي أن Cache-Control: max-age=0, must-revalidate يجب أن تعني في الأساس نفس الشيء مثل Cache-Control: no-cache. لذلك ربما تكون هذه طريقة للحصول علىMUST- إبطال سلوك no-cache ، مع تجنب الترحيل الظاهر لـ no-cache إلى فعل نفس الشيء مثل no-store (أي لا توجد ذاكرة تخزين مؤقتًا على الإطلاق)؟


عندما ترسل من قبل وكيل المستخدم

أعتقد إجابة shahkalpesh تنطبق على جانب وكيل المستخدم. يمكنك أيضًا الاطلاع على 13.2.6 إلغاء استجابات متعددة .

إذا أرسل وكيل المستخدم طلبًا باستخدام Cache-Control: max-age=0 (المعروف أيضًا باسم "إعادة التحقق من النهاية إلى النهاية") ، فسوف تقوم كل ذاكرة تخزين مؤقت على طول الطريق بإعادة التحقق من صحة إدخال ذاكرة التخزين المؤقت (على سبيل المثال ، مع عنوان If-Not-Modified) وصولًا إلى خادم Origin. إذا كان الرد هو 304 (غير معدّل) ، فيمكن استخدام الكيان المخزن مؤقتًا.

من ناحية أخرى ، لا يتم إعادة إرسال طلب مع Cache-Control: no-cache (ويعرف أيضًا باسم "إعادة التحميل من النهاية إلى النهاية") والخادم يجب ألا يكون استخدم نسخة مخبأة عند الاستجابة.

548
Michael Krebs

استضافة سحابة سريعة وموثوقة وبأسعار معقولة

اشترك واحصل على $50 مكافأة خلال 30 يومًا!

الحد الأقصى للسن = 0

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

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

هذا هو الضغط Shift أثناء النقر فوق تحديث ، مما يعني ، فقط أعد كل شيء بغض النظر عن ما.

48
Gunnar Cheng

السؤال القديم الآن ، ولكن إذا واجه أي شخص آخر ذلك من خلال البحث كما فعلت ، يبدو أن IE9 سيستفيد من هذا لتكوين سلوك الموارد عند استخدام زري الرجوع والخلف. عند استخدام الحد الأقصى للعمر = 0 ، سيستخدم المستعرض الإصدار الأخير عند عرض مورد على الصحافة الخلفية/الأمامية. إذا تم استخدام عدم التخزين المؤقت ، فسيتم إعادة تعيين المورد.

يمكن الاطلاع على مزيد من التفاصيل حول التخزين المؤقت لـ IE9 على هذا msdn caching post post .

33
El Yobo

في اختباراتي الأخيرة مع IE8 و Firefox 3.5 ، يبدو أن كلاهما متوافق مع RFC. ومع ذلك ، فإنها تختلف في "الود" على خادم الأصل. يعالج IE8 استجابات no-cache بنفس دلالات max-age=0,must-revalidate. ومع ذلك ، يبدو أن Firefox 3.5 يعامل no-cache على أنه مكافئ لـ no-store ، والذي يمتص الأداء واستخدام عرض النطاق الترددي.

Squid Cache ، بشكل افتراضي ، يبدو أنه لا يقوم أبدًا بتخزين أي شيء برأس no-cache ، تمامًا مثل Firefox.

ستكون نصيحتي هي تعيين public,max-age=0 للموارد غير الحساسة التي تريد التحقق من صلاحيتها عند كل طلب ، ولكن لا تزال تسمح بمزايا الأداء والنطاق الترددي للتخزين المؤقت. للعناصر لكل مستخدم مع نفس الاعتبار ، استخدم private,max-age=0.

أود تجنب استخدام no-cache بالكامل ، حيث يبدو أن بعض المتصفحات وذاكرة التخزين المؤقت الشائعة قد تم نثرها إلى ما يعادل no-store الوظيفي.

بالإضافة إلى ذلك ، لا تحاكي Akamai و Limelight. في حين أنها تدير بشكل أساسي مصفوفات تخزين مؤقت ضخمة باعتبارها أعمالها الأساسية ، وينبغي أن تكون خبراء ، إلا أنها في الواقع لديها مصلحة راسخة في التسبب في تنزيل المزيد من البيانات من شبكاتها. جوجل قد لا يكون خيارا جيدا لمحاكاة ، أيضا. يبدو أنهم يستخدمون max-age=0 أو no-cache بشكل عشوائي حسب المورد.

26
rmalayter
 الحد الأقصى للعمر 
 عندما يتم فرض ذاكرة التخزين المؤقت الوسيطة ، عن طريق توجيه الحد الأقصى للعمر = 0 ، لإعادة التحقق من 
 إدخال ذاكرة التخزين المؤقت الخاصة به ، وقد وفر العميل العميل الخاص به المدقق في الطلب ، قد يختلف [المدقق الموفر] عن المدقق المخزن حاليًا مع إدخال ذاكرة التخزين المؤقت. 
 في هذه الحالة ، قد تستخدم ذاكرة التخزين المؤقت إما أداة التحقق من الصحة في تقديم طلبها الخاص دون التأثير على الشفافية الدلالية. 
 
 ومع ذلك ، فإن اختيار المدقق قد يؤثر على الأداء. أفضل طريقة هي أن 
 ذاكرة التخزين المؤقت الوسيطة تستخدم أداة التحقق الخاصة بها عند تقديم طلبها. إذا كان الخادم يرد على 
 بـ 304 (غير معدلة) ، فيمكن أن تقوم ذاكرة التخزين المؤقت بإرجاع نسختها التي تم التحقق من صحتها الآن إلى العميل 
 باستجابة 200 (موافق). إذا كان الخادم يرد مع كيان جديد ومدقق ذاكرة التخزين المؤقت ، 
 ، ومع ذلك ، يمكن للذاكرة الوسيطة الوسيطة أن تقارن المدقق المرتجع مع الموفر في 
 طلب العميل ، باستخدام وظيفة المقارنة القوية. إذا كانت أداة التحقق من صحة العميل تساوي 
 مساوية للخادم الأصلي ، فسوف تُرجع ذاكرة التخزين المؤقت الوسيطة ببساطة 304 (ليس [. _.] معدلة). وإلا ، فإنها تُرجع الكيان الجديد باستجابة 200 (OK). 

 إذا تضمن طلب ما التوجيه no-cache ، فلا ينبغي أن يشمل min-fresh أو 
 max-stale ، أو max-age. 

من باب المجاملة: http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.4

لا تقبل هذا كإجابة - سأضطر إلى قراءته لفهم الاستخدام الحقيقي له :)

19
shahkalpesh

أنا بالكاد خبير في التخزين المؤقت ، لكن مارك نوتنجهام هو كذلك. فيما يلي مستندات التخزين المؤقت . لديه أيضا روابط ممتازة في قسم المراجع.

استنادًا إلى قراءتي لهذه المستندات ، يبدو أن max-age=0 قد يسمح لذاكرة التخزين المؤقت بإرسال استجابة مخبأة للطلبات الواردة في "الوقت نفسه" حيث يعني "الوقت نفسه" قريبًا بدرجة كافية من بعضها البعض ويبدو أنها متزامنة مع ذاكرة التخزين المؤقت ، ولكن no-cache لن.

12
Hank Gay

بالمناسبة ، تجدر الإشارة إلى أن بعض الأجهزة المحمولة ، وخاصة منتجات Apple مثل iPhone/iPad ، تتجاهل تمامًا الرؤوس مثل عدم التخزين المؤقت أو عدم التخزين أو انتهاء الصلاحية: 0 أو أي شيء آخر قد تحاول إجبارهم على عدم إعادة استخدامه منتهية الصلاحية صفحات النموذج.

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

أنا مجرد إضافة هذا في حالة شخص ما لا يمكن معرفة سبب حصولهم على أخطاء جلسة خاصة مع iphone و ipads ، والتي تبدو إلى حد بعيد أسوأ المخالفين في هذا المجال.

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

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

هذا ببساطة لا يحدث ، لذلك ما اضطررت للقيام به هو إضافة سلاسل استعلام إلى ملفات css/js التي كنت بحاجة لفرض التحديثات عليها ، والتي تخدع الأجهزة المحمولة الغبية إلى الاعتقاد بأنه ملف ليس لديها ، مثل: ملفاتي .css؟ v = 1 ، ثم v = 2 لتحديث css/js. هذا يعمل إلى حد كبير.

مستعرضات المستخدم أيضًا ، بالمناسبة ، في حالة تركها إلى الإعدادات الافتراضية الخاصة بها ، اعتبارًا من عام 2016 ، كما أنني أستكشف باستمرار (نقوم بالكثير من التغييرات والتحديثات على موقعنا) تفشل أيضًا في التحقق من آخر تواريخ تم تعديلها على هذه الملفات ، ولكن الاستعلام طريقة سلسلة إصلاح هذه المشكلة. هذا شيء لاحظته مع العملاء والموظفين الذين يميلون إلى استخدام الإعدادات الافتراضية الأساسية للمستخدم العادي على متصفحاتهم ، وليس لديهم وعي بمشاكل التخزين المؤقت مع css/js وما إلى ذلك ، يفشلون دائمًا في الحصول على تغيير css/js الجديد ، مما يعني أن الإعدادات الافتراضية للمتصفحات ، ومعظمها MSIE/Firefox ، لا تفعل ما يُطلب منها القيام به ، فهي تتجاهل التغييرات وتتجاهل التواريخ المعدلة الأخيرة ولا تتحقق من صحتها ، حتى مع انتهاء مدة الصلاحية: 0 بشكل صريح.

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

11
Lizardx

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

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

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

0
HttpWatchSupport