شاید برایتان پیش آمده باشد که همه تنظیمات را در کش سرور و مرورگر اعمال کرده اید اما آخر هم به یک کش پایدار و مطمئن نرسیده اید
این از اون مواردی است که بقولی به آن فوت کوزه گری می گویند من ده مورد از آنها را در زیر می اورم و پیدا کردن الباقی را به خودتان وا می گذارم
1- هدر های expire (تاریخ انقضا) و max-age (طول عمر) modify (زمان آخرین تغییر) توسط سرور ارسال شود
2- پاسخ کد وضعیت HTTP یکی از کدهای 200 ، 203 ، 300 ، 301 و یا 410 را داشته باشد.
3- نوع درخواست باید HTTP GET باشد (و نه PUT یا POST)
4- اگر در درخواست هدرهای مربوط به مجوز یا Authorization وجود داشته باشد پاسخ کش نخواهد شد
5- اگر در پاسخ سرور هدرهای مربوط به مجوز یا Authorization وجود داشته باشد پاسخ به شرطی کش خواهد شد که هدر
Cache-Control ارسال شود و در پارامترهای ارسالی آن یکی از انتخاب های "s-maxage" یا "must-revalidate" یا "public" آورده شود
6- اگر یو-آر-ال یا URL دارای query string یا پرامترهای متد GET از صفحه HTML باشد معمولا کش انجام نخواهد شد مگر اینکه علاوه بر هدر Expires مانند بند 5 هدر Cache-Control ارسال شود و در پارامترهای ارسالی آن یکی از انتخاب های "s-maxage" یا "must-revalidate" یا "public" آورده شود (طبق رفرنس RFC2616 و بخش 13.9 و 13.2.1)
7- اگر پاسخ سرور با کد 200 باشد حداقل یکی از هدرهای "Etag" یا "Last-Modified" یا "Expires" و یا مانند بند 5 هدر Cache-Control ارسال شود و در پارامترهای ارسالی آن یکی از انتخاب های "s-maxage" یا "must-revalidate" یا "public" آورده شود تا عمل کش کردن پاسخ سرور در مروگر انجام شود
8- اگر هدر Cache-Control ارسال شود و یکی از انتخاب ها در آن "private" باشد کش انجام نخواهد شد مگر بصورت کش استاتیک (که ارزش امنیتی خیلی پایینی دارد و برای داده های مهم اصلا توصیه نمی شود)
9- به همین نرتیب اگر یکی از انتخاب های ما no-store در Cache-Control باش کش صورت نخواهد گرفت
10- بالاخره اینکه اگر در هدر Vary پاسخ ارسالی match-all "*" باشد کش صورت نمی گیرد (معمولا User-Agent است که بهتر است Accept-Encoding,User-Agent باشد تا همیشه کش موفقی داشته باشیم)
نویسنده: سعید عرب شیبانی (گوگل724) | نوشته شده در:
پنج شنبه 17 آذر 90 ساعت 1:45 عصر
