आदर्श HTTP कैश विभिन्न प्रकार के संसाधनों के लिए हेडर को नियंत्रित करता है

Question

मैं हेडर का एक न्यूनतम सेट खोजना चाहता हूं, जो "सभी" कैश और ब्राउज़रों के साथ काम करता है ( एचटीटीपीएस का उपयोग करते समय भी !)।

मेरी वेब साइट पर, मेरे पास तीन प्रकार के संसाधन होंगे:

(1) हमेशा उपलब्ध (सभी उपयोगकर्ताओं के लिए सार्वजनिक / बराबर)

^{उदाहरण: 0A470E87CC58EE133616F402B5DDFE1C.cache.html ( GWT द्वारा जनरेट किया गया ऑटो )}

• इन फ़ाइलों को स्वचालित रूप से एक नया नाम सौंपा जाता है, जब वे सामग्री बदलते हैं (एमडी 5 पर आधारित)।

• HTTPS का उपयोग करते समय भी उन्हें जितना संभव हो उतना कैश किया जाना चाहिए (इसलिए मुझे लगता है, मुझे सेट करना चाहिए Cache-Control: public, विशेष रूप से फ़ायरफ़ॉक्स के लिए?)

• यदि क्लाइंट ने सामग्री को बदल दिया है, तो उन्हें मान्य करने के लिए क्लाइंट को राउंड-ट्रिप करने के लिए क्लाइंट की आवश्यकता नहीं होनी चाहिए।

(2) कभी-कभी (सभी उपयोगकर्ताओं के लिए सार्वजनिक / समान) बदलना

^{उदाहरण: index.html, mymodule.nocache.js}

• जब साइट का एक नया संस्करण तैनात किया जाता है, तो ये फाइलें URL को बदले बिना अपनी सामग्री को बदल देती हैं।

• उन्हें कैश किया जा सकता है, लेकिन हर बार अमान्य होने के लिए शायद एक राउंड-ट्रिप की आवश्यकता होती है।

(3) प्रत्येक अनुरोध के लिए व्यक्तिगत (निजी / उपयोगकर्ता विशिष्ट)

^{उदाहरण: JSON प्रतिक्रियाएँ}

• इन संसाधनों को बिना किसी भी परिस्थिति में डिस्क पर अनएन्क्रिप्ट किए कैश नहीं किया जाना चाहिए। (शायद छोड़ कर मेरे पास कुछ विशिष्ट अनुरोध होंगे जिन्हें कैश किया जा सकता है।)

---

मेरे पास एक सामान्य विचार है कि किस हेडर पर मैं शायद प्रत्येक प्रकार के लिए उपयोग करूंगा, लेकिन हमेशा कुछ ऐसा होता है जो मुझे याद आ सकता है।

Comments

आपके उत्तर और टिप्पणियों और लिंक के लिए धन्यवाद। मैं अभी भी थोड़ा प्रयोग कर रहा हूं, लेकिन मुझे लगता है, मैं एक समाधान प्राप्त कर सकूंगा!

— क्रिस लेचर

# 3 हासिल करना आम तौर पर संभव नहीं है।

— एरिकलाव

इन्हें भी देखें: stackoverflow.com/questions/6491789/…

— मिकीको रैंटलैनेन

Answer 1

मैं शायद इन सेटिंग्स का उपयोग करूंगा:

1. Cache-Control: max-age=31556926- किसी कैश द्वारा प्रतिनिधित्व कैश किया जा सकता है। कैश्ड प्रतिनिधित्व को 1 वर्ष के लिए नया माना जाना चाहिए:

   एक प्रतिक्रिया के रूप में "कभी भी समाप्त नहीं होता है" को चिह्नित करने के लिए, एक मूल सर्वर उस प्रतिक्रिया को भेजे जाने के समय से लगभग एक वर्ष की समाप्ति की तारीख भेजता है। HTTP / 1.1 सर्वर भविष्य में एक वर्ष से अधिक समय की समाप्ति की तारीख नहीं भेजते ।

2. Cache-Control: no-cache- प्रतिनिधियों को किसी भी कैश द्वारा कैश करने की अनुमति है। लेकिन कैश कैश कॉपी को जारी करने से पहले सत्यापन के लिए मूल सर्वर के लिए अनुरोध प्रस्तुत करना चाहिए।
3. Cache-Control: no-store - कैश को किसी भी हालत में प्रतिनिधित्व कैश नहीं करना चाहिए।

देखें मार्क नॉटिंघम की कैशिंग ट्यूटोरियल अधिक जानकारी के लिए।

Comments

@Gumbo: एक बात जो मुझे बहुत पक्की है, वह यह है कि मुझे सार्वजनिक रूप से सेट करने की आवश्यकता है , जब मैं चाहता हूं कि फ़ायरफ़ॉक्स 3+ को सार्वजनिक फ़ाइलों को डिस्क में HTTPS का उपयोग करते समय डिस्क पर कैश करना चाहिए: stackoverflow.com/questions/174348/…

— क्रिस लेरन

कुछ ब्राउज़र, जैसे IE, कैश-कंट्रोल का इलाज करना शुरू कर रहे हैं: नो-कैश जैसे कि यह कोई स्टोर नहीं था। यह वास्तव में RFC के अनुसार नहीं है, लेकिन यह जानबूझकर डिस्क पर अनएन्क्रिप्टेड संग्रहीत किए जाने से संवेदनशील डेटा को रोकने के लिए नो-कैश का उपयोग करने की MANY द्वारा की गई गलती को "ठीक" करने के लिए किया गया है।

— AviD

@chris_l, मैं इस लिंक पर हुआ: palisade.plynt.com/issues/2008Jul/cache-control-attributes । मुझे याद नहीं है कि पिछले संस्करणों ने कैसे व्यवहार किया था, हालांकि मुझे लगता है कि IE7 ने भी ऐसा किया।

— एवीडी

इसके अलावा, फ़ायरफ़ॉक्स को अब HTTPS संसाधनों को कैश करने के लिए कैश-कंट्रोल में पब्लिक की आवश्यकता नहीं है। लेकिन आपका सबसे अच्छा दांव कुल मिलाकर सिर्फ आपकी साइट का परीक्षण करना है, जबकि ट्रैफ़िक को देखना है, जैसे फ़िडलर।

— एरिकलाव

100 साल के कैश कंट्रोल मूल्य को सेट करने की सलाह नहीं दी जाती है। सबसे पहले, युक्ति अधिकतम 1 वर्ष की सिफारिश करता है। दूसरी बात, IE8 और उससे कम समय में 68 साल से अधिक के किसी भी परिणाम का परिणाम होता है: blogs.msdn.com/b/ieinternals/archive/2010/01/26/…

— EricLaw

Answer 2

मामले एक और दो वास्तव में एक ही परिदृश्य हैं। आपको Cache-Control: publicएक URL सेट करना चाहिए और फिर साइट का बिल्ड नंबर / संस्करण शामिल करना चाहिए ताकि आपके पास अपरिवर्तनीय संसाधन हों जो संभावित रूप से हमेशा के लिए टिक सकें। आप Expiresभविष्य में हेडर को एक वर्ष या उससे अधिक समय पर सेट करना चाहते हैं, ताकि क्लाइंट को नए सिरे से जांच जारी करने की आवश्यकता न हो।

केस 3 के लिए, आप अधिकतम लचीलेपन के लिए निम्नलिखित में से सभी कर सकते हैं:

"Cache-Control", "no-cache, must-revalidate"
"Expires", 0
"Pragma", "no-cache"

Comments

नए बिल्ड के लिए अलग-अलग URL शायद एक विकल्प नहीं हैं: a) यह क्लाइंट को हमेशा के लिए उपलब्ध फ़ाइलों को फिर से डाउनलोड करने के लिए मजबूर करेगा। इससे बचने के लिए उन्हें अनोखे नाम मिलते हैं। b) मेरी साइट का मुख्य URL सिर्फ https://www.example.com/c होना चाहिए ) मैं चाहता हूं कि बुकमार्क हमेशा मेरी साइट के नवीनतम संस्करण को देखें (कल्पना करें, स्टैकओवरफ्लो प्रश्न के बुकमार्क में साइट की बिल्ड संख्या शामिल होगी)।

— क्रिस लेचर

हाय क्रिस, यह दृष्टिकोण आमतौर पर दस्तावेजों के बजाय CSS और JS संसाधनों के लिए उपयोग किया जाता है। मैं मानता हूं कि यह दस्तावेज़ पहचानकर्ताओं के लिए लागू नहीं है, इस मामले में आपको बस कैशे-नियंत्रण सार्वजनिक, अंतिम-संशोधित और हेडर पर एटैग सेट करना चाहिए, जो हर बार नए सिरे से जांच का कारण बनेगा और यदि कोई बदलाव नहीं हुए तो केवल 304 वापस भेज दिए जाएंगे पिछले डाउनलोड के बाद से। वैकल्पिक रूप से, आप जेएस के माध्यम से प्रत्येक पृष्ठ में वास्तविक गतिशील पृष्ठ सामग्री डाउनलोड कर सकते हैं ताकि आप प्रभावी कैशिंग की अनुमति देते हुए URL को संरक्षित कर सकें।

— एंड्रयू एल

हां, यह बहुत अधिक तरीका है, GWT मेरे लिए इसे संभालता है: My index.html (कभी-कभी बदलते हुए) में mymodule.nocache.js (कभी-कभी बदलते हुए) शामिल होते हैं, जिसमें स्वचालित रूप से सही हमेशा के लिए शामिल-योग्य फ़ाइलें (js का बड़ा भाग, GWT प्रबंधित होता है) छवि बंडलों, ...) केवल एक चीज जो मुझे छोड़ती है, प्रत्येक प्रकार के लिए सही http हेडर सेट कर रही है। मैं इन हेडर को कम से कम करना चाहता हूं, क्योंकि वे ट्रांसफर वॉल्यूम के बड़े प्रतिशत के लिए जिम्मेदार हैं। तो क्या मुझे पिछले-संशोधित और ईटाग आदि दोनों की आवश्यकता है ?

— क्रिस लेचर

"एक्सपायर" वास्तव में एक तारीख होने की आवश्यकता है, न कि संख्या 0. यह "दिनांक" हेडर के समान मूल्य होना चाहिए। Mnot.net/cache_docs

— ल्यूक हचिसन