(Słabe) ETags i Last-Modified

Question

O ile rozumiem specyfikacje, ETag, który został wprowadzony w RFC 2616 (HTTP/1.1) jest następcą (sort) dla Last-Modified-Header, który jest zaproponuj, aby architekt oprogramowania bardziej kontrolował proces rewalidacji pamięci podręcznej.

Jeśli oba rekordy sprawdzania poprawności pamięci podręcznej (jeśli nie ma żadnych odpowiedników i jeśli zmodyfikowano je od) są obecne, zgodnie z RFC 2616, klient (tj. Przeglądarka) powinien używać ETag podczas sprawdzania, czy zasób ma zmienione. Zgodnie z sekcją 14.26 RFC 2616, serwer NIE MOŻE odpowiedzieć z niezmodyfikowaną wersją 304, jeśli ETag przedstawiony w nagłówku If-None-Matcher został zmieniony, a serwer musi zignorować dodatkowy nagłówek If-Modified-Since-Header , Jeśli obecny. Jeśli przedstawiony ETag jest zgodny, NIE MOŻE wykonać żądania, chyba że Data w Nagłówku z Ostatnią Zmodyfikowaną tak mówi. (Jeżeli przedstawiony ETag pasuje, serwer powinien odpowiadać z 304 niemodyfikowane w przypadku GET- lub head-prośbę ...)

Sekcja ta pozostawia pole do pewnych spekulacji:

• Silny ETag ma zmienić "za każdym razem", zmienia się zasób. Tak więc, posiadanie odpowiedzi na coś innego, jak 304 Nie Zmieniony na żądanie z niezmienionym ETag i Nagrywek If-Zmodyfikowany, którego dawka nie pasuje, jest trochę sprzeczne, ponieważ silny ETag mówi, że zasób był niezmodyfikowany. (Chociaż to nie jest śmiertelne, ponieważ serwer może ponownie wysłać ten sam zasób niezmienione.)
• ...

... O.K. Podczas pisania tego, pytanie sprowadzało się do odpowiedzi:

Powyższa (mała) sprzeczność powstała z powodu słabych ETag. Zasób oznaczony słabym ETag mógł ulec zmianie, mimo że ETag tego nie zrobił. Tak więc, w przypadku słabego ETag byłoby błędem, odpowiedzieć z 304 Nie Zmieniony, gdy ETag się nie zmienił, ale data podana w If-Modified-Since nie pasuje, prawda?

Answer 1

Różnica między zwykłym (silnym) ETag i słabym ETag jest taka, że ​​pasujący silny ETag gwarantuje, że plik jest identyczny dla bajtu, podczas gdy pasujący słaby ETag wskazuje, że treść jest semantycznie taka sama. Więc jeśli zawartość pliku zmieni się, słaba ETag również powinna się zmienić.

W przedstawionym scenariuszu plik na serwerze może być nowszy niż kopia zapisana w pamięci podręcznej w kliencie - ale ponieważ pasuje do niego, jest on semantycznie równoważny kopii w pamięci podręcznej, więc zwrot 304 byłby akceptowalny. odpowiedź.