Son değiştirilme tarihi Sonrasında değiştirilmişse, Apache neden 200 Tamam gönderir?


10

Önbellek stratejim ile ilgili temel bir davranışa sahip olmaya çalışıyorum: dosyalar önbelleğe alınmalı ve sunucu ile her seferinde yeniden doğrulanmalıdır. Bu yüzden Apache'nin geri 304 göndermesini istiyorum.

Her tarayıcı yenilemesi için gerçekleşen iletişim kutusu şunlardır:

Status Code:200 OK

Request Headers

Accept:text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Encoding:gzip,deflate,sdch
Accept-Language:fr-FR,fr;q=0.8,en-US;q=0.6,en;q=0.4
Cache-Control:max-age=0
Connection:keep-alive
Cookie: ...
Host:...
If-Modified-Since:Tue, 14 Oct 2014 15:10:37 GMT
If-None-Match:"1461-505636af08fcd-gzip"
User-Agent:Mozilla/5.0 (X11; Linux i686) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/34.0.1847.116 Safari/537.36

Response Headers

Accept-Ranges:bytes
Cache-Control:No-cache
Connection:Keep-Alive
Content-Encoding:gzip
Content-Length:1412
Content-Type:text/html
Date:Tue, 14 Oct 2014 16:58:05 GMT
ETag:"1461-505636af08fcd-gzip"
Keep-Alive:timeout=5, max=99
Last-Modified:Tue, 14 Oct 2014 15:10:37 GMT
Server:Apache/2.4.6 (Ubuntu)
Vary:Accept-Encoding

(Bu, önbelleği devre dışı bırak işaretlenmemiş olarak krom cihazlarından alınmıştır)

Yanıtın Cache-Control: No-cache Header içerdiğini ve If-modifiye-since başlığının Son değiştirilen ile eşleştiğini görebilirsiniz. ETag da eşleşir.

Bu durumda Apache 304 göndermemeli mi?

DÜZENLE

İle apag'deki ETag'leri devre dışı bırakma

 Header  unset ETag

önbellekleme davranışını daha öngörülebilir kılar ...


Sanırım Cache-Control:max-age=0önbelleği devre dışı bıraktım , böylece Cache-Control:No-cacheyanıtı görüyorsunuz .
ThoriumBR

W3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.1'den , her istek için yeniden doğrulamaya neden olduğu için Apache yapılandırmamda Cache-Control: No- cache'yi açıkça ayarladım . Yeniden doğrulama dosyanın yeniden gönderilmesini gerektiriyor mu? Ben bir 200 veya 304 olup olmadığını belirlemek için If-değiştirilmiş-beri kullanması gerektiğini söyleyebilirim.
zrz

Yanıtlar:


8

Bu eski bir hata gibi görünüyor , neden Header unset ETagfark yarattığını açıklıyor .

Apache 2.4.0+, sıkıştırma yönteminin adını otomatik olarak ETag'ye (başlıklarınızda görüldüğü gibi) ekler ve 304 yanıtını önler.

Mod_deflate'in en yeni sürümleri, bu davranışı kontrol etmek için kullanılabilen bir DeflateAlterETag öğesini destekler :

DeflateAlterETag NoChange

3
Bu doğrudur, ancak Apache 2.4 bu seçeneği içermez, sadece Apache 2.5'i içerir. Ancak kişisel olarak, Apache'nin dosya içeriğini değil, son değiştirilme tarihini temel aldığı için yararlı olan ETag'ler bulamıyorum. Bu nedenle ETag'leri kapatmak, yine de son değiştirilme tarihine dayanan If-Modified-Since başlığına geri döner. Apache'deki ETag'i, boyut, son değiştirilmiş ve / veya inode temelli hale getirmek için değiştirebilirsiniz - boyut ve son değiştirilmiş varsayılan olarak - ancak dosya içeriklerinin sağlama toplamına dayalı bir ETag hesaplamak için bir seçenek ekleyene kadar, sınırlı kullanım IMHO. Bu yüzden onları kapatıyorum.
Barry Pollard

1
@BazzaDP Bu mantıklı. 2.5 de DeflateAlterETag Removesadece bunu yapmak için bir seçenek var
Mathias R. Jessen

0

Bu, istekte biraz tuhaf olarak göze çarpıyor:

Cache-Control:max-age=0

Muhtemelen daha önemli olsa da, iade edilen içeriğin html olduğunu fark ettim. Dinamik olarak oluşturuluyor mu? Apache 304 yanıtı gönderebilir, ancak statik içerik sunmuyorsanız, bu çağrıyı yapmak Apache'nin işi değildir ve uygulama mantığınıza gelir. Örneğin çoğu php uygulaması bu tür şeyler için sınırlı desteğe sahiptir.

Bir ön uç önbellek, önbellek uygulaması değişiklik zamanını, etiketini vb. Kontrol edebildiğinden, ancak hem uygulama hem de istek üstbilgilerinin önbellek dostu olması durumunda yardımcı olabilir. Örneğin, uygulama içeriğin önbelleğe alınabileceğini belirtmek için uygun üstbilgileri ayarlamalıdır ve isteğinizdeki Önbellek denetimi üstbilgisi gibi şeyler önbelleği reddedecektir. Başlıklarınız önbellek dostu görünmüyor.


İstenen dosya, Apache'nin değişiklik zamanını doğru aldığı statik bir html dosyasıdır. (Son Değiştirilme Tarihi: Sal, 14 Eki 2014 15:10:37 GMT). URL'yi yazıp Enter tuşuna bastığımda max-age = 0 başlığı chrome tarafından gönderilen istekte. Önceki yanıtlar yüzünden orada mı?
zrz

Chrome'un otomatik olarak istekte Cache-Control: max-age = 0 eklediğini okudum (Chrome'u ilk yüklediğinizde URL'yi yazın, enter tuşuna basın). Ancak bu diğer sunucuları etkilemez (CDN'ler istekte max-age = 0 olsa bile 304 gönderir).
zrz

@zrz: aracı önbelleğe almayı sınırlamak hata ayıklama sırasında çok faydalıdır, ancak aksi takdirde performansa zarar verir. Chrome'un ne yaptığı hakkında okuduklarınızın bağlamını kontrol edin. Apache'nin yaptığı iş açısından oldukça yapılandırılabilir. Önbellek kontrolü, kaynak sunucu için değil, ara önbellekler için bir talimattır. Bununla birlikte, apache ara önbellek görevi görebilir ve her türlü şeyi yapacak şekilde yapılandırılabilir. Önbellekleme önleme talimatlarınızı alırsanız, daha çok bir başlangıç ​​sunucusundan beklediğiniz gibi davranacağınızı düşünüyorum.
mc0e

0

Apache ile yapılandırılmışsanız Cache-Control:No-cache, Apache HTTP 304 Not modifiedistemciye asla bir gönderilmez .

Bazı istekleri tekrar doğrulamak istiyorsanız, Cache-Control:No-cacheyalnızca ihtiyaç duyduğunuz sayfalara bir sayfa ekleyin. Tüm kaynakları yeniden doğrulamanız gerekmez ve bunu yaparak bant genişliğini boşa harcarsınız.


"Yeniden doğrula" terimiyle kafam karışmış gibi görünüyor. Benim için bu bir 304 olup olmadığını kontrol etmek demektir. Yanlış mıyım?
zrz

Hatalısınız. Revalidate, verileri tekrar müşteriye göndermek ve zaten aynı bilgiye sahip olsa bile her şeyi tekrar okumaya zorlamaktır. Temel olarak her istemcideki önbelleği devre dışı bırakıyorsunuz.
ThoriumBR

Bu birçok şeyi açıklıyor. Aklımda olması gereken son şey, Apache'nin bazı kaynaklar için 304 göndermesi (örneğin png), yine de Cache-Control'ün yanıtta ve istekte max-age = 0 değerinde hiçbir önbellek ayarlamaması. Bir ipucu ?
zrz

@ThoriumBR Sizi doğru yorumladıysam, her iki cevabınız da burada yanlış; no-cache (no-store'un aksine) "cache yok" anlamına gelmez ve içerik değişmediyse 304 ile sonuçlanabilir. Gerçekten de OP bunu bekledi, ancak etag sorunu nedeniyle alamıyordu. must-revalidate, eski içeriğin nasıl işlendiğiyle ilgilidir ve her zaman "verileri tekrar" göndermez.
Nick
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.