Cloudflare, Cache Rules'a her planda Vary header kontrolleri ekledi

Cloudflare Vary desteğini yayınladı

Cloudflare, Cache Rules içinde Vary response header desteğini yayınladı ve Cloudflare bloguna göre bu özellik her planda mevcut. Vary, bir origin'in ara cache'lere hangi istek alanlarının bir yanıtı değiştirebileceğini söylemek için kullandığı standart HTTP mekanizmasıdır ve baş ağrıtmasıyla bilinir: Cloudflare, yazıya daha önce var olan bir tanımlamaya atıfla başlıyor; bu tanıma göre Vary, HTTP'nin en çirkin ve hâlâ iyileştirilmemiş köşelerinden biri ve ara katmanlar arasındaki birlikte çalışabilirliği zayıf.\n## Vary neden var

Tek bir URL'nin meşru şekilde birden fazla doğru yanıtı olabilir. Sunucular, istemcinin isteğine bağlı olarak farklı diller, image formatları, sıkıştırma şemaları veya bölgesel içerik sunar; Vary da bu seçimi etkileyen istek alanlarını belirtir. Vary olmazsa, bir URL için cache'in sakladığı ilk yanıt herkese servis edilir. Blogdaki örnekte, aynı path için tarayıcıya HTML, API istemcisine JSON döndüren bir endpoint var. Cache Vary'yi yok sayarsa, hangi temsil önce gelirse o kazanır ve diğer istemci ayrıştıramayacağı byte'lar alır.

Doğru cache'leme ama kullanışsız hale gelen

Vary'yi safça uygulamak ters sorunu yaratır. Header, hangi istek alanlarının bir yanıtı etkileyebileceğini söyler ama hangi farkların gerçekten önemli olduğunu söylemez. "en-US, fr;q=0.8" ve "fr;q=0.8, en-GB" gibi iki Accept-Language değerinin ikisi de İngilizceyi tercih eder ve yalnızca İngilizce, Fransızca ve Almanca sunan bir origin ikisi için de aynı byte'ları döndürebilir — ama ham değerleri karşılaştıran bir cache bunları güvenli biçimde eşdeğer sayamaz ve yine de ayrı varyantlar saklayabilir. Parçalanma hızla büyür; blogda açıklandığı gibi, tek bir alanda on olası değer on varyant yaratırken, üç alana yayılmış on değer 1.000 kombinasyon yaratabilir. Gerçek header'lar daha da kötü — User-Agent değerleri çok sayidadır, çerezler çoğu zaman her ziyaretçiye özgüdür ve tercih header'ları sıralama, boşluk ve quality değerleri bakımından farklılık gösterir. Sonuç, teknik olarak doğru ama kimsenin yeniden kullanmadığı kayıtlarla dolu bir cache olabilir: özdeş yanıtlar, kapasite tüketen, birbirini cache'den çıkaran, hit oranını düşüren ve daha fazla isteği origin'e geri iten soğuk varyantlara dağılmış durumda. Sorun pratikte yaygın. Cloudflare, yaklaşık 50.000 popüler siteden 120 milyondan fazla yanıtı analiz etti ve dört ya da daha fazla alanda Vary kullanan neredeyse 3.000 site buldu; bazıları 10, 23 hatta 47 alanda Vary kullanıyordu.

Header başına üç aksiyon

Özellik kararı ikiye ayırıyor. Origin, bir yanıtı hangi istek header'larının etkileyebileceğini bildirmek için hâlâ Vary kullanır; Cache Rule ise Cloudflare'ın adı geçen her header'ın değerini nasıl ele alacağına karar verir. Üç aksiyon mevcut:

• normalize, önerilen varsayılan. Cloudflare, eşdeğer isteklerin aynı kaydı paylaşması için cache'lenmiş varyantı seçmeden önce istek header'larını normalize eder. Accept, Accept-Language ve Accept-Encoding için header'a özgü kurallar geçerlidir; diğer header'larda isteğe bağlı boşluklar kırpılır ve tekrarlanan header satırları özgün sıralarında birleştirilir, büyük-küçük harf ve içindeki boşluklar korunur.
• passthrough. Header'ın ham byte'ları cache eşleştirmesinde kullanılır; büyük-küçük harf, boşluk, sıra ve yinelenen değerler korunur, birden çok header satırı virgülle sırayla birleştirilir. Bu, değer kümesi kontrollü olan ve tam değerin yanıtı değiştirdiği header'lara uyar. Respect Strong ETags devre dışıyken Cloudflare bu modda Accept-Encoding'i yine yeniden yazabilir.
• bypass. Origin o header'ı Vary içinde adlandırdığında Cloudflare yanıtı saklamaz. Bu, Cookie veya User-Agent gibi kişiselleştirilmiş, yüksek kardinaliteli veya beklenmeyen header'lara yöneliktir. Mevcut kayıtlar silinmez, bu yüzden temizlemek için bir purge gerekir. Bir kural her yanıtı Vary kullanmaya zorlamaz. Origin Vary header'ı döndürmezse Cloudflare yanıtı normal biçimde cache'ler; ancak kural isteği yukarı akışta iletmeden önce Accept ve Accept-Language'i yine yeniden yazabilir. Bireysel ayarı olmayan header'lar kuralın varsayılan aksiyonuna düşer. Cloudflare, müşterilerin zaten geçici çözümleri olduğunu belirtiyor — cache'i atlamak, origin'in içerik pazarlığı mantığını özel bir cache key'de yeniden oluşturmak, bir Worker yazmak ya da Vary for images gibi daha dar özellikleri kullanmak — ama bunların her biri ya cache'lemeden vazgeçiyor, uygulama mantığını ikizliyordu, ek kod gerektiriyordu ya da sınırlı bir kullanım durumunu kapsıyordu.

Neden önemli

Vary tam olarak iki başarısızlık modunun ortasında duruyor: Onu yok sayarsanız yanlış istemciye yanlış içerik sunarsınız; harfiyen uygularsanız cache'iniz asla yeniden kullanılmayan kayıtlara parçalanır. HTTP bunu hiç çözmedi, çünkü header, hangi istek farklarının uygulama için anlamlı olduğuna dair bir semantik taşımıyor. Cloudflare'ın cevabı bu kararı, header başına, normalize gibi makul bir varsayılanla operatöre devretmek. Yoğun içerik pazarlığı yapan siteler — image'ler, diller, encoding'ler — için bu doğrudan daha iyi hit oranlarına ve daha az origin yüküne dönüşebilir. Ve bir kurumsal plan ekstrası yerine her planda sunulduğu için web'in büyük bir kesiminde cache'lemenin taban kalitesini yükseltmesi muhtemel.