Tag ET HTTP

Tag ETag lub znacznik podmiotu jest częścią protokołu HTTP , protokołu sieci World Wide Web . Jest to jeden z kilku mechanizmów, które HTTP zapewnia do pamięci podręcznej sieci Web , co pozwala klientowi na wysyłanie żądań warunkowych. Mechanizm ten pozwala na zwiększenie wydajności pamięci podręcznych i oszczędza przepustowość, ponieważ serwer WWW nie musi wysyłać pełnej odpowiedzi, jeśli zawartość nie uległa zmianie. ETags mogą być również używane do optymistycznej kontroli współbieżności, aby zapobiec wzajemnemu zastępowaniu jednoczesnych aktualizacji zasobu.

ETag to nieprzejrzysty identyfikator przypisany przez serwer WWW do określonej wersji zasobu znalezionego pod adresem URL . Jeśli reprezentacja zasobu pod tym adresem URL kiedykolwiek ulegnie zmianie, przypisywany jest nowy i inny znacznik ETag. Używane w ten sposób znaczniki ET są podobne do odcisków palców i można je szybko porównać w celu ustalenia, czy dwie reprezentacje zasobu są takie same.

Generowanie ETagów

Użycie ETagów w nagłówku HTTP jest opcjonalne (nie obowiązkowe jak w przypadku niektórych innych pól nagłówka HTTP 1.1). Metoda generowania znaczników ETag nigdy nie została określona w specyfikacji HTTP.

Typowe metody generowania ETag obejmują użycie odpornej na kolizje funkcji skrótu zawartości zasobu, skrótu znacznika czasu ostatniej modyfikacji, a nawet samego numeru wersji .

Aby uniknąć używania nieaktualnych danych z pamięci podręcznej, metody używane do generowania ETagów powinny gwarantować (na tyle, na ile jest to praktyczne), że każdy ETag jest unikalny. Jednak funkcję generowania ETag można uznać za „użyteczną”, jeśli można udowodnić (matematycznie), że powielanie ETag byłoby „akceptowalnie rzadkie”, nawet gdyby mogło lub miało miejsce.

RFC-7232 wyraźnie stwierdza, że ETAgi powinny być świadome kodowania treści , np

ETag: „123-a” – bez kodowania treści ETag: „123-b” – dla kodowania treści: gzip

niektóre wcześniejsze funkcje sum kontrolnych , które były słabsze niż CRC32 lub CRC64, miały problemy z kolizją mieszania. W związku z tym nie były dobrymi kandydatami do wykorzystania w generowaniu ETag.

Mocna i słaba walidacja

Mechanizm ETag obsługuje zarówno silną , jak i słabą weryfikację . Wyróżnia je obecność początkowego „W/” w identyfikatorze ETag, ponieważ:

„123456789” – Silny walidator ETag W/„123456789” – Słaby walidator ETag

Silnie weryfikujące dopasowanie ETag wskazuje, że zawartość dwóch reprezentacji zasobów jest identyczna bajt po bajcie i że wszystkie inne pola encji (takie jak Content-Language) również pozostają niezmienione. Silne tagi ET umożliwiają buforowanie i ponowne składanie częściowych odpowiedzi, tak jak w przypadku żądań o zakresie bajtów .

Słabo weryfikujące dopasowanie ETag wskazuje tylko, że te dwie reprezentacje są semantycznie równoważne , co oznacza, że ze względów praktycznych są one wymienne i że można używać kopii w pamięci podręcznej. Jednak reprezentacje zasobów niekoniecznie są identyczne bajt po bajcie, a zatem słabe znaczniki ETag nie są odpowiednie dla żądań zakresu bajtów. Słabe tagi ET mogą być przydatne w przypadkach, w których generowanie silnych tagów ET jest niepraktyczne dla serwera WWW, na przykład w przypadku treści generowanych dynamicznie .

Typowe użycie

W typowym użyciu, gdy pobierany jest adres URL, serwer sieci Web zwraca bieżącą reprezentację zasobu wraz z odpowiadającą mu wartością ETag, która jest umieszczana w polu „ETag” nagłówka odpowiedzi HTTP:

ETag: "686897696a7c876b7e"

Klient może następnie zdecydować o buforowaniu reprezentacji wraz z jej ETag. Później, jeśli klient chce ponownie pobrać ten sam zasób adresu URL, najpierw określi, czy wersja adresu URL przechowywana lokalnie w pamięci podręcznej wygasła (za pomocą nagłówków Cache-Control i Expire). Jeśli adres URL nie wygasł, pobierze zasób z pamięci podręcznej lokalnie. Jeśli zostanie stwierdzone, że adres URL wygasł (jest nieaktualny ), klient wyśle żądanie do serwera, które zawiera wcześniej zapisaną kopię ETag w polu „Jeśli-None-Match”.

Brak dopasowania: „686897696a7c876b7e”

W przypadku tego kolejnego żądania serwer może teraz porównać ETag klienta z ETag dla bieżącej wersji zasobu. Jeśli wartości ETag są zgodne, co oznacza, że zasób się nie zmienił, serwer może odesłać bardzo krótką odpowiedź ze HTTP 304 Not Modified . Status 304 mówi klientowi, że jego wersja w pamięci podręcznej jest nadal dobra i że powinien z niej korzystać.

Jeśli jednak wartości ETag nie są zgodne, co oznacza, że zasób prawdopodobnie się zmienił, zwracana jest pełna odpowiedź zawierająca zawartość zasobu, tak jakby znaczniki ETag nie były używane. W takim przypadku klient może zdecydować się na zastąpienie wcześniej zbuforowanej wersji nowo zwróconą reprezentacją zasobu i nowym ETag.

Wartości ETag mogą być wykorzystywane w systemach monitorowania stron WWW . Skuteczne monitorowanie stron internetowych utrudnia fakt, że większość stron internetowych nie ustawia nagłówków ETag dla stron internetowych. Gdy monitor sieci nie ma wskazówek, czy zawartość sieci została zmieniona, cała zawartość musi zostać pobrana i przeanalizowana przy użyciu zasobów obliczeniowych zarówno wydawcy, jak i subskrybenta.

Niedopasowane wykrywanie ETag

Błędna strona internetowa może czasami nie zaktualizować ETag po zaktualizowaniu jej zasobów semantycznych. Od 2019 roku przykładem znanej takiej witryny jest export.arxiv.org . W rezultacie nieprawidłowo zwrócona odpowiedź ma stan 304, a klient nie może pobrać zaktualizowanego zasobu. Aby wykryć taką błędną witrynę:

Buforuj odpowiedź i ETag, zakładając, że istnieje ETag i że odpowiedź nie została przerwana.
W przypadku kolejnego żądania, które zawierałoby nagłówek If-None-Match, nie wysyłaj tego nagłówka z losowym prawdopodobieństwem 20%. Z takim prawdopodobieństwem, jeśli odpowiedź zwróci zmienioną treść, ale ten sam ETag, co poprzednio w pamięci podręcznej, oznacz witrynę jako błędną i wyłącz dla niej buforowanie ETag. Dla przypomnienia, dla silnego ETag, porównanie zawartości może być bajt po bajcie, podczas gdy dla słabego ETag sprawdzałoby tylko równoważność semantyczną.

Śledzenie za pomocą ETagów

ETagi mogą być używane do śledzenia unikalnych użytkowników, ponieważ pliki cookie HTTP są coraz częściej usuwane przez użytkowników świadomych prywatności. W lipcu 2011 r. Ashkan Soltani i zespół badaczy z UC Berkeley poinformowali, że wiele stron internetowych, w tym Hulu , używa ETagów do śledzenia. Hulu i KISSmetrics przestały „odradzać się” od 29 lipca 2011 r., Ponieważ KISSmetrics i ponad 20 jego klientów stoi w obliczu pozwu zbiorowego w związku z wykorzystaniem „nieusuwalnych” śledzących plików cookie , częściowo obejmujących użycie ETags.

Ponieważ znaczniki ETag są zapisywane w pamięci podręcznej przeglądarki i zwracane wraz z kolejnymi żądaniami tego samego zasobu, serwer śledzący może po prostu powtórzyć dowolny znacznik ET otrzymany z przeglądarki, aby zapewnić, że przypisany znacznik ETag będzie trwał przez czas nieokreślony (w sposób podobny do trwałych plików cookie ) . Dodatkowe nagłówki buforowania mogą również poprawić zachowanie danych ETag.

ETagi można opróżniać, czyszcząc pamięć podręczną przeglądarki (implementacje są różne).

ETag w specyfikacji HTTP/1.1
O Etags and Datestamps autorstwa Larsa R. Clausena (2004)

Linki zewnętrzne

Dokumentacja serwera Apache HTTP — dyrektywa FileETag
Edycja sieci Web: Wykrywanie problemu z utraconą aktualizacją przy użyciu Unreserved Checkout , Uwaga W3C, 10 maja 1999 r.
Demonstracja na żywo pliku cookie zombie przy użyciu ETags
Stare projekty rozwojowe SQUID - wsparcie ETag Zarchiwizowane 23 września 2012 r. W Wayback Machine (ukończone w 2001 r.)
Używanie ETagów do zmniejszania przepustowości i obciążenia dzięki Spring & Hibernate