रिसोर्स · 63
HTTP कैशिंग: पर्सनलाइज़्ड रिस्पॉन्स को सुरक्षित रखें
शेयर्ड, प्राइवेट और एप्लीकेशन कैश को अलग करें, एक्सेस-राइट में बदलाव के बाद कीज़, रीवैलिडेशन और इनवैलिडेशन की जांच करें।
अपडेटेड · 6 min
यह गाइड क्या पाने में मदद करती है
- इन्वेंट्री लेयर्स
- रिटेंशन चुनें
- कीज़ को इंस्पेक्ट करें
- रीवैलिडेशन करें और बदलें
जल्दी से चेक करें
- क्या नो-कैश का मतलब है कि कुछ भी नहीं रखा गया है?
- क्या वैरी एक्सेस राइट्स को प्रोटेक्ट करता है?
- क्या हर API को कैश किया जाना चाहिए?
स्टेप-बाय-स्टेप तरीका
- 1
इन्वेंट्री लेयर्स
ब्राउज़र, CDN, प्रॉक्सी, सर्विस वर्कर और एप्लिकेशन कैश की लिस्ट बनाएं। पब्लिक और पर्सनलाइज़्ड रिस्पॉन्स को क्लासिफ़ाई करें। एक HTTP पॉलिसी कोड में इम्प्लीमेंट किए गए कैशिंग को ऑटोमैटिकली डिस्क्राइब नहीं करती है।
डिलिवरेबल: लेयर्स और ओनर्स डायग्राम।
- 2
रिटेंशन चुनें
RFC 9111 डायरेक्टिव्स को अलग करता है: नो-कैश को रीयूज़ से पहले वैलिडेशन की ज़रूरत होती है, नो-स्टोर रिलेवेंट HTTP स्टोरेज को रोकता है, और अनक्वालिफाइड प्राइवेट शेयर्ड स्टोरेज को बाहर करता है। इनमें से कोई भी अकेले सिस्टम की कॉन्फिडेंशियलिटी की गारंटी नहीं देता है।
डिलीवरेबल: हर रिस्पॉन्स के लिए रिटेंशन पॉलिसी।
- 3
कीज़ को इंस्पेक्ट करें
रिप्रेजेंटेशन बदलने का तरीका, URI और डाइमेंशन चेक करें। रिक्वेस्ट फ़ील्ड्स से जुड़ी अलग-अलग चिंताएँ; यह ऑथराइज़ेशन नहीं है। एप्लीकेशन लेयर्स में छूटी हुई भाषा, फ़ॉर्मैट नेगोशिएशन और अकाउंट कॉन्टेक्स्ट देखें।
डिलीवरेबल: कीज़ और सेपरेशन टेस्ट।
- 4
रीवैलिडेशन करें और बदलें
नए और पुराने रिस्पॉन्स, डेटा अपडेट और रद्द किए गए राइट्स को टेस्ट करें। ETag, कंडीशनल वैलिडेशन और ओरिजिन-अनअवेलेबल बिहेवियर को इंस्पेक्ट करें। पहले सही रिस्पॉन्स रद्द होने के बाद सेंसिटिव हो सकता है।
डिलीवरेबल: पहले और बाद के ट्रेस।
- 5
दो अकाउंट के साथ रिप्ले
काल्पनिक पहचान और मार्कर का इस्तेमाल करें। वार्म और कोल्ड कैश के साथ एक ही URI पर अल्टरनेट रिक्वेस्ट करें। असली टोकन रिकॉर्ड किए बिना लॉगआउट, डायरेक्ट लिंक और लॉगिंग चेक करें।
डिलीवरेबल: नेगेटिव टेस्ट और इनवैलिडेशन स्ट्रैटेजी।
दोबारा इस्तेमाल होने वाली वर्कशीट
अपने ऑथराइज़्ड ऑब्ज़र्वेशन के साथ पूरा करें। ये फ़ील्ड एक वर्किंग टेम्पलेट हैं, देखे गए नतीजे नहीं।
| फ़ील्ड | रिकॉर्ड करने के लिए जानकारी |
|---|---|
| रिस्पॉन्स | पब्लिक या पर्सनलाइज़्ड; डाइमेंशन |
| लेयर | कैश, ओनर और की |
| पॉलिसी | रिटेंशन, फ्रेशनेस और वैलिडेशन |
| ट्रायल | फिक्शनल अकाउंट, बदलाव और ऑब्ज़र्वेशन |
काल्पनिक काम का उदाहरण
उदाहरण वाली स्थिति
काल्पनिक उदाहरण: एक CDN दो टेस्ट अकाउंट के लिए एक ही URI पर प्रोफ़ाइल रिस्पॉन्स का दोबारा इस्तेमाल करता है।
फैसला और उम्मीद का सबूत
सिनेरियो लीकेज का पता लगाता है, पॉलिसी और कीज़ की जांच करता है, फिर सुधार और एक्सेस रद्द होने के बाद रिप्ले करता है।
मैकेनिज़्म में अंतर बताएं
| मैकेनिज़्म | मकसद | वेरिफ़िकेशन या लिमिटेशन |
|---|---|---|
| नो-कैश | ज़रूरी वैलिडेशन के साथ स्टोरेज की इजाज़त दें | इसे नो स्टोरेज न समझें |
| अनक्वालिफाइड प्राइवेट | शेयर्ड कैशिंग को बाहर करें | इसे कॉन्फिडेंशियलिटी गारंटी न समझें |
| नो-स्टोर | ज़रूरी HTTP स्टोरेज को रोकें | एप्लीकेशन कैश और हिस्ट्री को अलग-अलग चेक करें |
मैनेजमेंट इंडिकेटर
| इंडिकेटर | यह क्या मापता है | पहला एक्शन |
|---|---|---|
| अकाउंट सेपरेशन | दूसरे अकाउंट से कोई मार्कर नहीं | बॉडी, लिंक और मेटाडेटा को इंस्पेक्ट करें |
| एज और वैलिडेशन | पॉलिसी के हिसाब से दोबारा इस्तेमाल करें | एक्सपायरी और अनअवेलेबल ओरिजिन को टेस्ट करें |
| इनवैलिडेशन में देरी | सही रिप्रेजेंटेशन तक का समय | हर लेयर का नाम बताएं जो अभी भी स्टेल है |
आम गलतियाँ
- इसे नो स्टोरेज न समझें
- इसे कॉन्फिडेंशियलिटी गारंटी न समझें
- एप्लीकेशन कैश और हिस्ट्री को अलग-अलग चेक करें
अक्सर पूछे जाने वाले सवाल
क्या नो-कैश का मतलब है कि कुछ भी नहीं रखा गया है?
नहीं। इसे दोबारा इस्तेमाल करने से पहले वैलिडेशन की ज़रूरत होती है; यह नो-स्टोर की तरह स्टोरेज को नहीं रोकता है।
क्या वैरी एक्सेस राइट्स को प्रोटेक्ट करता है?
नहीं। यह रिप्रेजेंटेशन चुनने में हिस्सा लेता है; ऑथराइज़ेशन अलग रहता है।
क्या हर API को कैश किया जाना चाहिए?
नहीं। फ़ायदे लागत, फ्रेशनेस और रिस्क पर निर्भर करते हैं। सेंसिटिव रिस्पॉन्स शेयर्ड कैश से बचने को सही ठहरा सकते हैं।
ऑफ़िशियल रेफ़रेंस
रेफ़रेंस इस तरीके को सपोर्ट करते हैं। अपने कॉन्टेक्स्ट के हिसाब से चेक को एडजस्ट करें; वे सर्टिफ़िकेशन नहीं हैं। ओरिजिनल रेफ़रेंस टाइटल और सोर्स डॉक्यूमेंट दूसरी भाषा में हो सकते हैं।
संदर्भ जाँच की तारीख .
