RFC 2616'dan
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.1
no-cache
Önbellek içermeyen yönerge bir alan adı belirtmezse, önbellek, kaynak sunucu ile başarılı bir yeniden doğrulama olmadan sonraki bir isteği karşılamak için yanıtı KULLANMAMALIDIR. Bu, bir başlangıç sunucusunun istemci isteklerine eski yanıtlar döndürmek üzere yapılandırılmış önbellekler tarafından bile önbelleğe alınmasını engellemesine olanak tanır.
Böylece ajanları tüm yanıtları yeniden doğrulamaya yönlendirir .
Bunu ile karşılaştırıldı
mutlaka revalidate
Önbellek tarafından alınan bir yanıtta must-revalidate yönergesi mevcut olduğunda, bu önbellek girdiyi bayatladıktan sonra ilk olarak özgün sunucu ile yeniden doğrulamadan yanıt vermemek için KULLANMAMALIDIR.
Böylece ajanları eski yanıtları yeniden doğrulamaya yönlendirir .
Özellikle, ilgili olarak no-cache, kullanıcı aracıları bu direktif üzerine gerçekten de bu yönergeyi ampirik olarak ele alıyor mu?
Ne anlamı var no-cacheolmadığını must-revalidateve max-age?
Bu yoruma bakın:
http://palpapers.plynt.com/issues/2008Jul/cache-control-attributes/
no-cache
Bu yönerge, tarayıcıya sayfayı önbelleğe almama talimatı veriyor gibi görünse de, ince bir fark vardır. RFC'ye göre “önbellek yok” yönergesi, tarayıcıya sayfayı önbellekten sunmadan önce sunucuyla yeniden doğrulaması gerektiğini bildirir. Yeniden doğrulama, uygulamanın bant genişliğini korumasını sağlayan düzgün bir tekniktir. Tarayıcının önbelleğe aldığı sayfa değişmediyse, sunucu bunu tarayıcıya bildirir ve sayfa önbellekten görüntülenir. Bu nedenle, tarayıcı (en azından teoride) sayfayı önbelleğinde saklar, ancak yalnızca sunucuyla yeniden doğruladıktan sonra görüntüler. Uygulamada IE ve Firefox, tarayıcıya sayfayı önbelleğe almama talimatı veriyormuş gibi önbelleksiz yönergeyi ele almaya başladılar. Bu davranışı yaklaşık bir yıl önce gözlemlemeye başladık.
Bu konuda daha resmi bir şey var mı?
Güncelleme
Mutlaka yeniden direktif yönergesi, yalnızca temsile ilişkin bir isteğin doğrulanmaması, sessizce gerçekleştirilmeyen bir finansal işlem gibi yanlış işlemle sonuçlanabiliyorsa sunucular tarafından kullanılmalıdır.
Bu, şimdiye kadar hiç kalbe almadığım bir şey. RFC, hafifçe tekrar doğrulamamayı söylüyor. Mesele şu ki, web hizmetleriyle, olumsuz bir görünüm almalı ve bilinmeyen istemci uygulamalarınız için en kötüsünü almalısınız. Eski kaynakların soruna neden olma potansiyeli vardır.
Ve Son Değişiklik veya ETag'ler olmadan az önce düşündüğüm başka bir şey, tarayıcı yalnızca tüm kaynağı tekrar alabilir. Ancak ETags ile Chrome'un en azından her istekte yeniden doğrulanmış gibi göründüğünü gözlemledim. Bu da, hem bu direktifleri tartışmalı hem de en azından kötü adlandırılmış yapar, çünkü istek yine de 'daima yeniden doğrulamaya' neden olan diğer başlıkları da içermedikçe düzgün bir şekilde yeniden doğrulayamazlar.
Sadece son noktayı daha açık hale getirmek istiyorum. Sadece must-revalidatebir ETag veya Last-Modified ayarlayarak ancak dahil etmeyerek, aracı, içeriği karşılaştırmak için sunucuya gönderecek hiçbir şeyi olmadığından yalnızca içeriği tekrar alabilir.
Ancak, ampirik testlerim ETag veya değiştirilmiş başlık verileri yanıtlara dahil edildiğinde, ajanın must-revalidatebaşlığın varlığına bakılmaksızın her zaman yine de yeniden doğruladığını göstermiştir .
Dolayısıyla, must-revalidatebayat olduğunda bir 'bypass önbelleği' zorlamaktır, bu sadece bir ömür / yaş ayarladığınızda gerçekleşebilir, bu nedenle must-revalidateyaş veya diğer üstbilgileri olmayan bir yanıt üzerine ayarlanırsa, o no-cachezamandan beri etkili bir şekilde eşdeğer hale gelir. cevap derhal bayat kabul edilecektir.
- Sonunda Gili'nin cevabını işaretleyeceğim!