Düzenlenebilir, herkese açık bir belge için okuyucuların güncel içeriği almasını, değişmemiş sayfaların ise yeniden kullanılabilmesini istiyorsanız yeniden doğrulamayı seçin. Yayınlama gereksiniminiz HTTP önbelleğinde depolamayı özellikle hariç tutuyorsa no-store seçin.

Bu kılavuz, herkese açık bir belgeyi Mac masaüstü bilgisayarından yöneten kişiler içindir. Görev, bir yanıt ilkesi seçmek ve ardından yalnızca “Şekil kılavuzu, birinci sürüm” gibi tarafsız metin içeren sentetik bir sayfayla bunu Terminal'de denetlemektir. Bir test sayfasına ve bu sayfanın barındırma yapılandırmasına erişiminiz ya da yanıt başlıklarını yapılandırabilecek bir sağlayıcınız olmalıdır.

Belgeye hangi önbellekleme ilkesi uygun?

Yayınlama gereksinimiyle başlayın. Sayfa her yeniden kullanımdan önce denetlenmeli mi, mevcut bir kopya kısa bir süre kullanılabilir mi, yoksa HTTP önbellekleri yanıtı depolamaktan kaçınmalı mı? Bunlar RFC 9111: HTTP Caching kapsamında farklı gereksinimlerdir.

Yayınlama gereksinimi Yanıt başlığı adayı HTTP önbelleği açısından anlamı
Her yeniden kullanımdan önce denetle Cache-Control: no-cache Depolamaya izin verilir; yeniden kullanım için başarılı doğrulama gerekir.
Kısa bir güncellik aralığına izin ver Cache-Control: max-age=300, must-revalidate Yanıt güncelse yeniden kullanıma izin verilir; güncelliğini yitirince başarılı doğrulama gerekir.
Yanıtın depolanmasını hariç tut Cache-Control: no-store Önbellek yanıtı depolamamalı veya başka bir istek için kullanmamalıdır.

Beş dakikalık aralık, örnek amaçlı bir tercihtir; önerilen varsayılan değer değildir. Yalnızca belgeniz bu yeniden kullanım aralığını tolere edebiliyorsa seçin. Tek başına must-revalidate, yanıt güncelken denetim yapılmasını gerektirmez. Bu ayrımlar RFC 9111’in yanıt yönergelerine dayanır.

Sentetik şekil kılavuzunda, “üç örnek” ifadesinin “dört örnek” olarak düzeltilmesinin bir sonraki getirme işleminde denetlenmesi gerektiğini varsayalım. Çalışan bir doğrulayıcıyla no-cache ile başlayın. Gereksiniminiz bunun yerine HTTP önbelleklerinin bu belge yanıtını saklamamasını söylüyorsa no-store seçin. Sık düzenleme yapılması tek başına depolamanın hariç tutulması gerektiğini göstermez.

Ayarları değiştirmeden önce gereksinimi yazın; örneğin: “Yeniden kullanımdan önce belgeyi denetle.” Böylece somut bir kabul ölçütünüz olur ve ilke seçimini ayarın adının belirlemesini önlersiniz.

Yeniden doğrulamanın çalışması için ne gerekir?

Doğrulayıcı, istemcinin daha önce aldığı sürümü tanımlar. ETag bir varlık etiketi, Last-Modified ise değişiklik zaman damgası sağlar. RFC 9110, başarılı belge getirme işlemlerinde mevcut doğrulayıcıların gönderilmesini ve hem güçlü bir varlık etiketi hem de değişiklik tarihinin tercih edilmesini önerir. Bkz. HTTP Semantics, validators ve 200 OK.

Bunlar örnek yanıt başlığı alanlarıdır, sunucu yapılandırma kodu değildir. Yanıt gövdesinin sentetik şekil kılavuzu olduğunu varsayarlar:

Cache-Control: no-cache
ETag: "shape-guide-v1"

Daha sonraki bir istekte istemci If-None-Match: \"shape-guide-v1\" gönderebilir. Bu etiket seçili gösterimle hâlâ eşleşiyorsa koşullu GET, yanıt gövdesi olmadan 304 Not Modified alır. Artık eşleşmiyorsa normal işlem, değiştirilmiş belgeyi döndürebilir. Kurallar RFC 9110’un koşullu istekler bölümünde yer alır.

Uygulama gereksinimi, doğrulayıcının belge sürümünü takip etmesidir. Örnek etiketi kalıcı bir yapılandırmaya kopyalayıp düzenlemelerden sonra da değiştirmeden bırakmayın. Barındırma sisteminizden doğrulayıcıları tutarlı biçimde üretmesini ve gelen koşulları değerlendirmesini isteyin.

Değişmemiş bir yanıt ne kadar aktarımı önleyebilir?

Açıkça örnek amaçlı bir hesaplamayı ele alalım: belge gövdesi 80,000 bayt ve istemci belgeyi hiç düzenleme olmadan 100 kez getiriyor. Bir tam yanıtın ardından gelen 99 başarılı doğrulama, 8,000,000 baytlık belge gövdesi yerine 80,000 bayt aktarır; aradaki fark 7,920,000 bayttır.

Bu hesaplama başlıkları, sıkıştırmayı, bağlantı yükünü ve uygulama işlemlerini kapsamaz. Yalnızca gövde aktarımını açıklar. Google’ın HTTP caching explanation belgesinde aynı alışveriş açıklanır: eşleşen bir doğrulayıcı, gövdesiz bir 304 yanıtına izin verir ve istemci daha önce aldığı içeriği kullanır. Gerçek tasarruf, belgelerin ne sıklıkta değiştiğine ve istemcilerin nasıl istek gönderdiğine bağlıdır.

İlkeyi nerede yapılandırmalısınız?

Barındırma hizmetinizin, sunucunuzun veya içerik dağıtım katmanınızın oluşturduğu HTTP yanıtını yapılandırın. Yukarıdaki başlık örnekleri gereken sonucu açıklar; bir yayınlama platformu için evrensel komutlar değildir.

Düzenleyiciniz yalnızca belge metnini değiştirmenize izin veriyorsa, biçimlendirme üzerinden bir geçici çözüm eşdeğer denetim sağlamaz. WHATWG HTML Standard, Cache-Control başlığını desteklenen bir http-equiv yönergesi olarak tanımlamaz ve bu yönergelerin büyük ölçüde HTTP başlıklarından ayrı olduğunu açıklar. Bkz. HTML Standard: Pragma directives.

Desteklenen yol, barındırma sağlayıcınızın belgelenmiş yanıt başlığı yapılandırmasını kullanmak veya sağlayıcıdan bunu uygulamasını istemektir. Google’ın crawler overview belgesi de HTTP önbelleklemesini uygulamak için yayıncıları barındırma ya da içerik yönetimi sağlayıcılarına yönlendirir. Yararlı bir talepte belgenin adını, seçilen ilkeyi ve doğrulayıcı davranışını belirtin, ardından iletilen yanıtı nasıl doğrulayacağınızı sorun.

JavaScript isteği seçeneğini değiştirmek daha sınırlı bir kapsama sahiptir. WHATWG, HTTP önbelleği yokmuş gibi davranan bir Fetch no-store önbellek kipini tanımlar; no-cache ise uygun bir önbelleğe alınmış yanıt varsa koşullu istek gönderir. Bu kipler söz konusu isteği yönetir; bir betikte bunlardan birini ayarlamak, belgenin sunucu yanıtı ilkesini yapılandırmaz. Bkz. Fetch Standard’ın önbellek kipleri.

Mac’te yeniden doğrulamayı nasıl test edebilirsiniz?

Düzenleyebileceğiniz, sentetik ve herkese açık bir test belgesi kullanın. Başlamadan önce içeriğini “Şekil kılavuzu, birinci sürüm” yapın ve seçilen yanıt başlıklarının iletilmesini sağlayın. Bu testi gerçek belge içeriğinden ayrı tutun; böylece değişiklik açıkça görülebilir ve geri alınabilir.

Terminal'i açın ve aşağıdaki komutları aynı oturumda çalıştırın. Komutlar gerçek test URL’nizi ve bu sayfanın döndürdüğü doğrulayıcıyı sorar; örnek bir adres varsayılmaz. İlk istek başarısız olursa, yönlendirme döndürürse veya amaçlanan belge yanıtından başka bir şey döndürürse devam etmeyin.

printf '%s\n' 'Paste the full URL of your synthetic public test page:'
IFS= read -r page_url

curl --silent --show-error --connect-timeout 5 --max-time 20 \
  --dump-header - --output /dev/null --url "$page_url"

printf '%s\n' 'Paste its ETag value exactly, including quotes:'
IFS= read -r page_etag

check_page() {
  curl --silent --show-error --connect-timeout 5 --max-time 20 \
    --dump-header - --output /dev/null \
    --header "If-None-Match: $page_etag" --url "$page_url"
}

check_page

Komutlar GET isteği gönderir, alınan başlıkları görüntüler ve yanıt gövdesini bilerek atar. Zaman aşımları bağlantı ve aktarım sürelerini sınırlar; hatalar görünür kalır. Bu seçenekler curl kılavuzunda belgelenmiştir. İlk istek, seçtiğiniz Cache-Control değerini ve bir ETag göstermelidir. Etiket yoksa uydurma bir değer girmeyin; önce doğrulayıcı desteği sorununu çözün.

W/ öneki ve çevresindeki tırnak işaretleri dahil, etiketin tam değerini kopyalayın. Gösterim değişmemiş ve etiket eşleşiyorsa koşullu istek 304 döndürmelidir. 304 içerik taşıyamaz ve geçerli olduğu durumlarda ETag ve Cache-Control dahil, eşdeğer 200 yanıtına eşlik edecek belirtilmiş meta verileri içermelidir. Bkz. RFC 9110: 304 Not Modified.

Eski doğrulayıcıyı koruyarak düzenlemeyi test edin

Sentetik belgeyi “Şekil kılavuzu, ikinci sürüm: dört örnek.” olarak değiştirin. Güncelleme test sayfanıza ulaştıktan sonra eski etiketi aynı Terminal oturumunda tutun ve şu devam komutunu çalıştırın:

check_page

Bu belge bilerek değiştirildiği için yeni gövdenin normal bir başarılı yanıtla ve güncellenmiş doğrulayıcıyla erişilebilir olmasını bekleyin. Ardından yeni etiketi kullanarak ilk komutları tekrarlayın ve değişmemiş sürümü yeniden denetleyin. Böylece her iki durum da test edilir: değişikliği tanıma ve değişiklik olmadığını tanıma.

Gözlem Sonraki tanılama adımı
İlk istek yönlendirme döndürüyor Belgenin son URL’sini kullanıp testi yeniden başlatın.
Değişmemiş koşullu istek 200 döndürüyor Etiketi doğru kopyaladığınızı ve koşullu işlemenin etkin olduğunu denetleyin.
İçerikte bilerek yapılan bir düzenleme, eski etiketle hâlâ 304 döndürüyor Yeniden doğrulamaya güvenmeden önce güncellemenin iletilmesini ve doğrulayıcı üretimini araştırın.
İletilen ilke yapılandırmanızdan farklı Son yanıtı etkileyen barındırma ve dağıtım ayarlarını inceleyin.
İstek zaman aşımına uğruyor veya başarısız oluyor Önbellek davranışını yorumlamadan önce getirme sorununu çözün.

Bunlar tanılama ipuçlarıdır; belirli bir nedeni kanıtlamazlar. Bu yordam yanıtı ve koşullu iletişimi test eder; her tarayıcının nasıl davranacağını göstermez. no-store değerlendirilirken bu yanıt yönergesini doğrudan inceleyin. Elle oluşturduğunuz koşullu istek, tarayıcının bir yanıt depolayıp depolamadığını test etmez.

Bu, Google Arama için ne anlama geliyor?

Google’ın güncel tarayıcı belgeleri If-None-Match ile ETag ve If-Modified-Since ile Last-Modified kullanımını destekler. Google tarayıcıları için ETag önerir ve farklı tarayıcıların önbelleği farklı biçimlerde kullanabileceğini belirtir. Bkz. Overview of Google crawlers and fetchers.

Bu sayfa ayrıca diğer HTTP önbellekleme yönergelerinin desteklenmediğini belirtirken max-age seçeneğinin Last-Modified ile birlikte olası bir yeniden tarama ipucu olarak kullanılmasını da önerir. Belgelerde tanımlanan bu sınırlar göz önüne alındığında, tarayıcı odaklı no-store veya no-cache ilkenizin Googlebot’un getirme zamanlamasını belirlediğini varsaymayın. Doğrulayıcıları, belgelenmiş koşullu getirme yolu olarak uygulayın ve test edin.

Google, 304 yanıtının işleme sistemlerine içeriğin değişmediğini bildirdiğini, ancak Arama’da dizine eklemeyi başka şekilde etkilemediğini açıklar. Başarılı bir 200 yanıtı da dizine eklemeyi garanti etmez. Bunlar How HTTP status codes affect Google’s crawlers belgesinde açıklanır.

Belge gereksiniminize uygun ilkeyi seçin ve ardından test kanıtlarını saklayın: ilk yanıt, değişmemiş bir koşullu yanıt ve bilerek yapılan bir düzenlemeden sonraki yanıt. Yeniden kullanımdan önce denetlenmesi gereken herkese açık bir belge için yeniden doğrulama, uygulanabilir bir başlangıç noktasıdır. HTTP önbelleğinde depolamanın hariç tutulması bizzat gereksinimse no-store seçin.

Kaynaklar