CDN purge से visitor के browser में पहले से रखी files नहीं मिटतीं। व्यापक purge या cache TTL बढ़ाने से पहले response का रास्ता जाँचें।
HTML और version वाले assets की तुलना करें
- साफ़ browser session से ठीक page और asset माँगें। Status, Age, Cache-Control, ETag/Last-Modified और मौजूद होने पर CDN cache-status header दर्ज करें।
- जाँचें कि navigation पर HTML revalidate होता है और content-hashed JS/CSS लंबे समय तक cache होता है। बदल सकने वाले URL पर immutable, एक-वर्षीय policy कभी न लगाएँ।
केवल stale layer को purge करें
- यदि CDN पुरानी bytes लौटाता है, तो ठीक उसी URL या version को purge करके दो networks से दोबारा जाँचें। केवल एक browser stale हो तो edge rules बदलने से पहले fresh profile जाँचें।
- बदलाव के बाद logged-in और public pages अलग-अलग सत्यापित करें। Personalized responses shared caches में नहीं जाने चाहिए; headers capture करें और पिछले rule का rollback रखें।
उदाहरण और अपेक्षित नतीजा
- Page के लिए
curl -sS -D page.headers -o page.html PAGE_URLचलाएँ; hashed asset के लिएasset.headersऔरasset.binजैसे अलग नाम रखें। सहेजी गईpage.htmlदेखें या origin से build identifier मिलाएँ। Deployment के बाद दोनों GET requests दोहराएँ औरAgeतथा CDN status header की तुलना करें;Cache-ControlऔरETagभी देखें। HTML default रूप से cache न हो सकता है, इसलिए पहले साइट के असली rules देखें। - अगर केवल एक browser profile stale है, तो उसका service worker और local cache जाँचें। CDN पुराना HIT दे तो केवल प्रभावित path purge करें और fresh profile में फिर जाँचें। Origin भी पुराना हो तो पहले deployment/origin ठीक करें। असंबंधित paths purge न करें।