एप्लिकेशन और HTTP कैश अलग रखें
Redis, Workers KV और HTTP कैश की गारंटी अपने आप समान नहीं होती। Workers KV अंततः सुसंगत है: लिखी जानकारी तुरंत हर जगह नहीं दिखती। नीचे के निर्देश HTTP कैश के हैं; ये अकेले एप्लिकेशन कैश कॉन्फिगर नहीं करते।
| HTTP उत्तर निर्देश | मुख्य अर्थ | सीमा |
|---|---|---|
| no-cache | भंडारण संभव, पुनः उपयोग से पहले सत्यापन। | इसका अर्थ भंडारण निषेध नहीं। |
| no-store | इस उत्तर को कैश में न रखें। | पुरानी प्रतियाँ अपने आप नहीं हटाता। |
| private | साझा कैश में भंडारण नहीं। | प्रमाणीकरण का नियम नहीं। |
| max-age | उत्तर की ताजगी की अवधि। | सभी डेटा की सुसंगति सुनिश्चित नहीं करता। |
सही व्यक्ति के लिए सही उत्तर जाँचें
- संसाधन, पैरामीटर, भाषा और अधिकार के अनुसार कुंजी भिन्नताएँ तय करें। जाँचें कि एक खाते को दूसरे का निजी उत्तर न मिले।
- अधिकतम उम्र, अमान्यकरण और बदलाव या हटाने के बाद व्यवहार तय करें। छोटा TTL तुरंत सुसंगत पढ़ने की गारंटी नहीं देता।
- एक साथ समाप्ति, कैश विफलता और मूल सर्वर विफलता जाँचें। जरूरत पर रीफ्रेश जोड़ें और पुराने उत्तर केवल व्यावसायिक नियम अनुमति दें तब दें।
कैश हिट दर से आगे मापें
देरी, त्रुटि, मूल सर्वर का भार और गलत या पुराने उत्तर देखें। शेष राशि, आरक्षित स्टॉक और अधिकार को सार्वजनिक कैटलॉग से अलग गारंटी चाहिए हो सकती है। तेज कैश को अनियंत्रित वैकल्पिक सत्य-स्रोत न बनने दें।
प्राथमिक स्रोत
API कैशिंग को एक्सेस डिसीजन को सेव करना चाहिए।
जब कीज़ रिक्वेस्टर परमिशन को इग्नोर करती हैं, तो रिस्पॉन्स कैश एक गलत क्वेरी को फास्ट बना सकता है। जब कोई ग्राफ़ पब्लिक और प्राइवेट ऑब्जेक्ट को कंबाइन करता है, तो रिस्क बढ़ जाता है।
- कैशिंग से पहले पब्लिक, प्राइवेट और रोल-डिपेंडेंट फील्ड को क्लासिफाई करें।
- एक अकाउंट के तहत रिस्पॉन्स को टेस्ट करें और दूसरे के तहत रिक्वेस्ट करें।
- परमिशन या डेटा में बदलाव के बाद रिजल्ट को इनवैलिड करें।
प्राथमिक स्रोत: OWASP — GraphQL Cheat Sheet. संबंधित विधि: व्यावहारिक मार्गदर्शिका पढ़ें.
कैश की ताज़गी भी मापें
काल्पनिक उदाहरण: डेटा किसी ग्राहक या देखे गए परिणाम का नहीं है।
दो रीड तेज़ हैं, लेकिन स्रोत बदलने के बाद एक अभी भी पुरानी उपलब्धता दिखाती है।
- मान, संस्करण, पढ़ने की जगह और बदलाव से बीता समय तुलना करें। प्रणाली के अनुबंध के अनुसार अमान्य करना, समाप्ति और स्रोत तक पहुँच जाँचें।
- हर उपयोग के लिए स्वीकार्य पुरानापन तय करें और अंतर निगरानी में रखें। कम विलंब डेटा की संगति साबित नहीं करता।
प्राथमिक स्रोत: IETF — RFC 9111, HTTP Caching. संबंधित विधि: व्यावहारिक मार्गदर्शिका पढ़ें.
छोड़े गए उपडोमेन: नियंत्रण के साथ CNAME हटाएँ
DNS नाम को नियंत्रित संसाधन से जोड़ें और सेवा छोड़ने से पहले निर्भरताएँ बंद करें।
- नाम, CNAME शृंखला, प्रदाता संसाधन और जिम्मेदार व्यक्ति दर्ज करें। DNS को अधिकृत खाते की सूची से मिलाएँ। HTTP त्रुटि, NXDOMAIN या गायब संसाधन जाँच का संकेत है, कब्जे की संभावना का प्रमाण नहीं; प्रदाता सुरक्षा अलग होती है।
- संदर्भ हटाएँ या नियंत्रित लक्ष्य चुनें, फिर संसाधन छोड़ें। पुराने TTL और कैश देखें; प्रामाणिक DNS और कई रिज़ॉल्वर जाँचें। जरूरी स्वामित्व सत्यापन रखें, सभी TXT रिकॉर्ड न हटाएँ।
- लिंक, रीडायरेक्ट, OAuth कॉलबैक, webhook और कुकी डोमेन देखें। संसाधन पहले ही छोड़ा गया हो तो DNS सुधारें और घटना प्रक्रिया से संभावित खुलासे की जाँच करें। हर हटाने के बाद DNS और संसाधन मिलाएँ।
दोहराने योग्य स्वीकृति मामला
काल्पनिक उदाहरण: डेटा किसी ग्राहक या देखे गए परिणाम का नहीं है।
मामले के इनपुट देखें
{
"name": "portal.example",
"cname_present": true,
"resource_deleted": true,
"provider_claimability": "not_verified",
"takeover_observed": false,
"expected": "remove_or_replace_mapping_and_review_exposure"
}अपेक्षित निर्णय
काल्पनिक उदाहरण: portal.example हटाए संसाधन को दिखाता है। CNAME हटाएँ या नियंत्रित लक्ष्य चुनें; गायब संसाधन अकेले तीसरे पक्ष का कब्जा साबित नहीं करता।
क्या त्रुटि पृष्ठ कब्जे की संभावना साबित करता है?
नहीं। संसाधन स्थिति और प्रदाता आरक्षण या स्वामित्व सत्यापन देखें। जोखिम साबित करने के लिए संसाधन दावा न करें।
प्राथमिक स्रोत: Microsoft — Prevent dangling DNS entries. संबंधित विधि: व्यावहारिक मार्गदर्शिका पढ़ें.
ETag, HTTP कैश और समवर्ती बदलाव
इस संस्करण में विस्तृत संदर्भ टिप्पणियाँ अंग्रेज़ी में उपलब्ध हैं।
Revalidation does not replace cache isolation
A matching If-None-Match can justify 304 for the selected representation after access checks. It does not by itself select the correct user variant.
- Separate variant selection, authorisation and validator comparison.
- Test weak and strong tags with If-None-Match: the comparison is weak.
- Read no-cache as validation before reuse, rather than no-store.
Explore ETag comparisons and the simulator →
References reviewed · RFC 9110 · §13 · RFC 9111 · RFC 6585 · §3
GraphQL: त्रुटियाँ, सूचियाँ और आंशिक डेटा
इस संस्करण में विस्तृत संदर्भ टिप्पणियाँ अंग्रेज़ी में उपलब्ध हैं।
GraphQL result: follow the error path
Aliases belong to the result; list indices start at zero. These details determine where a client should flag missing data.
- Compare absent data, partial data and data: null.
- Keep the original path even when a parent becomes null.
- Test permissions, quotas and interface states separately.
Explore GraphQL responses and nullability →
GraphQL Specification · September 2025 · Published edition · September 2025