Cache ve koşullu istekler
Service worker ve offline cache
Cache sandığın şey tek katman değildir.
Kavramı anlayalım
Service worker kendi scope’u içinde fetch akışını yakalayıp network veya Cache API’den yanıt seçebilir. Cache API ile saklanan yanıtlar normal HTTP freshness davranışını kendiliğinden aynı biçimde uygulamaz; uygulamanın stratejisi gerekir. Network-first, cache-first ve stale-while-revalidate farklı doğruluk/latency tercihleri taşır.
Eski worker, eski asset ve yeni HTML uyumsuzluğu deployment sorunu yaratabilir. Sürümlenen cache isimleri, activation ve cleanup planı olmalıdır. Logout sonrası kişisel offline verinin kalması ayrı privacy riskidir. URL-only key ile başka kullanıcı hesabını offline cache’ten göstermek ciddi hatadır.
Secure context gerekir; localhost geliştirme istisnaları public HTTP production için güvenlik izni anlamına gelmez. DevTools Application panelinde worker ve storage’ı ayrıca incele. Browser cache’i kapatınca worker’ın devre dışı olduğunu varsayma. Eğitim sayfası yeni bir service worker kaydetmez; mevcut site davranışı korunur.
“Güncelledim ama eski sayfa geliyor” sorunlarını çözmek için.
Disable cache bütün offline cache’i kapatır sanmak.
Aynı konu. Üç farklı derinlik.
Network response ≠ service-worker responseDevTools yanıt kaynağını kontrol et.
Bu sayfa dış sunuculara istek göndermez. HTTP mesajları temsili, HTTP/1.1 biçiminde okunabilir gösterimlerdir; HTTP/2 ve HTTP/3 wire formatı değildir. example.test ayrılmış öğretim alan adıdır. Komut ve JavaScript örneklerini yalnız kendi test ortamında uygula; gerçek token veya cookie yayımlama.
Önce kendin dene.
Logout yaptıktan sonra offline hesap sayfası kalmalı mı?
Çözümü ve açıklamasını göster
Deliberate retention and isolation policy requiredBilinçli privacy/retention kararı olmadan hayır; hesaplar arasında sızıntı testi gerekir.