Yapıp yapmamak söz konusu olduğunda mevcut durum nedir
Transfer-Encoding: gzip
veya a
Content-Encoding: gzip
örneğin sınırlı bant genişliğine sahip istemcilerin sıkıştırılmış bir yanıtı kabul etme isteklerini işaret etmelerine izin vermek istediğimde ve sunucu sıkıştırıp sıkıştırmayacağına dair son söze sahip olduğunda .
İkincisi, örneğin sıkıştırmayı halletmesine izin verirseniz, Apache'nin mod_deflate ve IIS'nin yaptığı şeydir. Sıkıştırılacak içeriğin boyutuna bağlı olarak ek yapar Transfer-Encoding: chunked.
Ayrıca Vary: Accept-Encoding, soruna zaten işaret eden bir a da içerecektir . Content-Encodingvarlığın bir parçası gibi görünüyor, bu nedenle Content-Encodingtutarları varlığın bir değişikliğine değiştirmek, yani farklı bir Accept-Encodingbaşlık aracı, örneğin bir önbellek, aksi takdirde özdeş varlığın önbelleğe alınmış sürümünü kullanamaz.
Bu konuda kaçırdığım kesin bir cevap var mı (ve bu, bazı apache haber gruplarında uzun bir ileti dizisindeki bir mesajın içine gömülü değil)?
Şu anki izlenimim:
- Aslında Transfer-Kodlama, mevcut sunucu ve istemci uygulamaları tarafından çoğunlukla İçerik Kodlama ile yapılan şeyi yapmanın doğru yolu olacaktır.
- İçerik Kodlama, anlamsal çıkarımları nedeniyle birkaç sorun taşır (sunucu
ETagbir yanıtı şeffaf bir şekilde sıkıştırdığında ne yapmalıdır ?) - Nedeni tavuk'n'egg: Tarayıcılar bunu desteklemiyor çünkü sunucular desteklemiyor çünkü tarayıcılar
Bu yüzden doğru yolun bir olacağını varsayıyorum Transfer-Encoding: gzip(ya da bedeni ek olarak parçalarsam, olur Transfer-Encoding: gzip, chunked ). Ve bu durumda, taşıma seviyesinde bir şey olduğu için dokunmaya Varyveya ETagbaşka herhangi bir başlığa gerek yok .
Şimdilik Transfer-Encoding, diğerlerinin her şeyden önce endişe duyduğu bir şey olan 'atlamalı atlama' konusunu çok fazla umursamıyorum , çünkü vekiller sıkıştırılmamış ve sıkıştırılmamış olarak müşteriye iletebilir. Bununla birlikte, orijinal istek uygun bir Accept-Encodingbaşlığa sahipse, proxy'ler de bunu olduğu gibi (sıkıştırılmış) iletebilir , bu da bildiğim tüm tarayıcılar için verilidir.
Btw, bu sorun en az on yıl öncesine ait, bkz. Ör. Https://bugzilla.mozilla.org/show_bug.cgi?id=68517 .
Bununla ilgili herhangi bir açıklama memnuniyetle karşılanacaktır. Hem standartlara uygun hem de pratik olarak kabul edilenler açısından. Örneğin, yalnızca şeffaf "İçerik Kodlamasını" destekleyen HTTP istemci kitaplıkları, pratikliğe aykırı bir argüman olacaktır.