304 / If-modifiye-beri / HEAD isteklerini önlemek için başlıklar


31

İçerik önbelleğe alındıktan sonra sunucuya yapılan tüm istekleri kesin olarak durdurmak için hangi başlıkları göndermeliyim?

Çok yüksek gecikmeli bir sunucumuz (Sigh, VMWare) var, bu yüzden HEADsunucuya bir istek göndermek bile + 40ms sürüyor.

Şu anda bunlar, gönderilen / alınan başlıklar;

İlk istek

Müşteri gönderir;

GET http://dugong:8080/Rvi24mYJkxFRGNzq73PPvgWGh1j/IMG_2071.jpg HTTP/1.1
Host: dugong:8080
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:9.0) Gecko/20100101 Firefox/9.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip, deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Pragma: no-cache, no-cache, no-cache
Cache-Control: no-cache, no-cache, no-cache

Sunucu yanıt verir;

HTTP/1.1 200 OK
Server: nginx/1.0.11
Date: Wed, 01 Feb 2012 14:51:51 GMT
Content-Type: text/plain
Vary: Accept-Encoding
Last-Modified: Tue, 31 Jan 2012 10:45:11 GMT
Content-Length: 14
Expires: Thu, 31 Jan 2013 14:51:51 GMT
Cache-Control: max-age=31536000

Böylece gelecekte 365 güne ayarlanmış bir Cache-Controlve Expiresbaşlık gönderir . Maalesef ikinci yenilemede nesneyi bir If-Modified-Sincebaşlık ile tekrar ister .

İkinci istek

GET http://dugong:8080/Rvi24mYJkxFRGNzq73PPvgWGh1j/IMG_2071.jpg HTTP/1.1
Host: dugong:8080
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:9.0) Gecko/20100101 Firefox/9.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip, deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
If-Modified-Since: Tue, 31 Jan 2012 10:45:11 GMT
Cache-Control: max-age=0

Tepki;

HTTP/1.1 304 Not Modified
Server: nginx/1.0.11
Date: Wed, 01 Feb 2012 14:58:00 GMT
Vary: Accept-Encoding
Expires: Thu, 31 Jan 2013 14:58:00 GMT
Cache-Control: max-age=31536000

Ne yazık ki aptal modası geçmiş proxy yazılımı nedeniyle kullanamayız Keep-Aliveveya uygulamanın önüne başka bir sunucu / proxy koyarız. Ayrıca, sunucunun performansını iyileştiremeyiz ve ağ gecikmesini azaltamayız. 301 talebinden kurtulmak için hangi başlıkları gönderebileceğimizi anlamaya çalışıyorum. ETag'leri kullanmayı denedim ama bu bir fark yaratmıyor, yine de bir If-modified-sincebaşlık gönderiyor . Ayrıca Last-Modifiedbaşlığı kaldırmayı da denedim, ancak bu önbellekleme olmadan standart bir GET isteğine neden oluyor (Günlükleri kontrol ediyor, sunucu hala istek alıyor).

Müşteriler, Firefox (çoğunlukla), IE 7, 8 ve (bazı) 9, Chrome ve Safari’nin bir karışımıdır, ancak bu davranış test edilen tüm tarayıcılarda görünmektedir.

TL; DR;

Korkunç ağ, istemcilere, hiçbir zamanIf-modified-since sunucuya, önbelleklerini doğrulamak için sunucuya hiçbir zaman istek göndermemelerini ve içeriğin önbelleğe alınmalarını sağlamak için önbelleğe alınmalarını istemem gerektiğini söylemeliyim Expires?

Muhtemelen bariz bir şeyi özlüyorum ama denediğim her şey aynı sonuçları veriyor gibi görünüyor.

Uygulama sunucumuzun önünde bulunan bir NGINX sunucumuz var, böylece istediğim gibi herhangi bir başlığı ekleyebilir / silebilirim. Proxy'imiz Keep-Alive'ı desteklemiyor ve onların korkunç ağ performansını artırmanın bir yolunu bilmiyor. Kötü yazılım tasarımı nedeniyle, web uygulaması her sayfa yüklemesinde +100 kaynak yükler (Evet, kurumsal yazılım berbat), nesne başına ~ 40-50ms gecikme süresiyle.


1
Hmm, bu garip. Son Kullanma Tarihi ve maksimum yaş başlıkları, görüntünün daha fazla talep edilmesini önlemelidir. Düzenleme: Bu arada, bir JPG olarak gönderme ile anlaşma text/plainnedir?
DisgruntledGoat

1
@DisgruntledGoat Ahh, bir .jpg dosyasının aslında bir metin belgesi yerine bir resim olduğunu kabul ettin. Benim dünyama = hoş geldiniz) (Aslında bu benim test için 'Merhaba Dünya' içeren bir metin dosyası var, yazılım sadece türünden bağımsız olarak tüm dosyaları sırayla IMG_xxxx.jpg yeniden adlandırır ha Serin).?
Smudge

http istek başlıklarını belirlemek için ne kullanıyordun?
barlop

Yanıtlar:


25

Kullanıcı temsilcilerinin size ne göndermeye karar vereceğini gerçekten kontrol edemezsiniz. Söz konusu dosya tarayıcının önbelleğinde ise ve yeni bir sürümü kontrol etmesi gerektiğine karar verirse, o zaman olacaktır. Bu makaleye göre , bunlar tarayıcıların If-Modified-Since kullanarak isteyeceği durumlardır:

  • Önbelleğe alınmış girişin son kullanma tarihi yok ve içeriğe tarayıcı oturumunda ilk kez erişiliyor
  • Önbelleğe alınmış girişin son kullanma tarihi var, ancak süresi dolmuş
  • Kullanıcı Yenile düğmesini tıklatarak veya F5 tuşuna basarak bir sayfa güncellemesi istedi.

Bu nedenle, önbelleğe almanızı test etmek için sayfayı yeniden yüklüyorsanız, tarayıcı görüntüleri yeniden isteyeceği için çalışmaz. Bir bağlantıyı ve ardından başka bir bağlantıyı ilk sayfaya geri döndürmeyi deneyin. Kullanıcılarınız düzenli olarak sayfalar yüklüyorsa, bunu önlemek için site / uygulama yapınızı yeniden düşünmeniz gerekebilir.

Yardımcı olabilecek bir şey, önbellek kontrol başlığına yani "genel" eklemek Cache-Control: public, max-age=31536000. Son zamanlarda bir yıldan fazla bir son kullanma tarihinin geçersiz olduğunu da öğrendim . Son kullanma tarihiniz tam olarak bir yıl olduğundan, belki birkaç gün veya hafta kadar düşürülmesi, dosyanın tarayıcı önbelleklerinde kalmasını ve atılmamasını sağlar.


İlginçtir, süreleri 60 güne indiririm ve genel bayrağını eklerim ve ne olacağını görürüm. Bu F5s yerine link tıklamalarında gerçekleşiyor gibiydi (Firebug ve sunucu kayıtlarına göre)
Smudge

Teknik olarak, HTTP / 1.1 spesifikasyonu yalnızca "sunucuların bir yıldan uzun sürdüğü tarihler göndermemelidir" (muhtemelen bu sürenin dolmasından çok saçma bir zaman alacağı için) ve gelecekteki "yaklaşık bir yıl" ın uygun son kullanma tarihi olduğunu söylüyor. süresi dolması beklenmeyen bir içeriğe gönderme zamanı.
Ilmari Karonen

1
Uğraşırken biraz sonra ben 365d son kullanma etkilemiyor sonucuna ettik bizim güvenli olması için aşağı düştü ettik ancak istemcileri, öyle görünüyor Cache-Control: public,...bu spesifik duruma anahtar oldu.
Leke

Gereksiz gidiş gelişleri düzelten "halk" başlığını mı kastediyorsunuz? Denedim, ama başarılı
olamadım

2
Cevabım net değilse , sayfanın tarayıcınıza yeniden yüklenmesi dosyaları tekrar isteyecektir . Sayfaları açmak için bağlantıları tıkladığınızda tarayıcı önbelleğini kullanır.
DisgruntledGoat


3

Aynı sorunu yaşadım ve İstekler sunucuya 304durumuyla yanıt vermesi için kesinlikle isabet ediyor - 304 'i C # ile gönderiyorum ve kesinlikle sunucuya isabet ediyor ..

Sadece Cache-Control: privateayarlamıştım. Hayır max-ageve hayır ExpiresBeklendiği gibi işletilir; Beklediklerime göre If-Modified-Sincedeğeri test ettiğim yerde sunucuya vur ve beklemeden geri 304w / boş yanıt gövdesi - başka 200& yanıt gövdesini doldur.

ExpiresBaşlığın ayarlanması istenen sonuçları verdi, 200 - (from cache)istemcide & hiçbir HTTP isteği sunucuya çarpmadı.

Ama .. O ayar buldum İKİ max-age= & Expiresdeğil göndermeye tarayıcıları neden olabilir If-Modified-Sincebaşlığında VE hiç önbelleğine değil değerleri eşleşmiyor eğer .

Önbelleğe alma sorunlarınız varsa ve farklı başlıkları birlikte kullandıysanız, farkında olmanız gereken bir şey var.


1

Biraz konu dışı ama belki yardımcı olabilir. Önbelleğe alınmış içerik istekleriniz için bir başka gelişme, sessionStorage uygulamasında önbelleğe almaktır, böylece sunucudan önbelleği doğrulamasını ve bir 304 almasını istemenize gerek kalmaz. Örneğin google, konsolu açıp sessionStorage yazın. CSS veya DOM’leri sessionStorage ile önbelleğe aldıklarını göreceksiniz. ofc, eski IE tarayıcılarında bunu kullanamazsınız.


0

Kaynak kodunuza bakın ve başka bir sayfaya geçmek için META REFRESH olmadığından emin olun. Bunun yerine sendRedirect gibi bir şey kullanın. Kurulumumda META REFRESH IE’de 304 üretiyor ancak Chrome üretmiyor. sendRedirect bunu her iki tarayıcıda da üretmiyor.

<meta http-equiv="refresh" content="0;URL='nextpage'" />    

vs

<% response.sendRedirect("nextpage") %>
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.