ETag sau eticheta de entitate este unul dintre anteturile de serviciu ale protocolului HTTP/1.1 reglementat de specificația RFC 7232 , care poate fi setat de un server web în faza de generare a unui răspuns la o solicitare primită de la un client . Conținutul antetului ETag este un identificator a cărui valoare depinde direct de starea resursei care este încărcată de client . În viitor, acest identificator este utilizat pentru a actualiza starea resursei descărcate la originalul ei, situat pe serverul Web . Acest lucru se realizează prin trimiterea unei cereri către serverul HTTP/1.1 specificând identificatorul ETag ca valoare antet - If-None-Match . Serverul, după ce a găsit un astfel de antet, pe baza unei comparații a valorii acestuia cu starea curentă a resursei, informează clientul că copia stocată în memoria cache a clientului este actualizată, adică. nu este nevoie să descărcați din nou sau, în caz contrar, trebuie să descărcați cea mai recentă versiune.
Un ETag este un identificator privat atribuit de un server web unei versiuni specifice a unei resurse găsite într-o adresă URL. Dacă conținutul resursei pentru această adresă se schimbă cu unul nou, este atribuit un nou ETag. Utilizarea ETag-urilor în acest fel este similară cu utilizarea amprentelor digitale, puteți compara și determina rapid dacă două versiuni ale unei resurse sunt identice sau nu. Compararea ETag-urilor are sens numai cu etag-uri de la aceeași adresă URL , ID-urile obținute de la adrese URL diferite pot fi egale sau nu, indiferent de resurse, deci compararea lor nu are sens.
Utilizarea ETag-urilor într-un antet HTTP este opțională (la fel ca și alte câmpuri de antet HTTP 1.1). Metoda prin care sunt generate ETag-urile nu a fost niciodată specificată în specificația HTTP.
Metodele obișnuite pentru crearea unui ETag includ utilizarea unei funcții hash rezistente la coliziuni a conținutului resursei, un hash al orei ultimei modificări sau chiar doar un număr de versiune.
Pentru a evita folosirea datelor cache învechite, metodele utilizate pentru generarea ETag-urilor ar trebui să asigure (în măsura în care este practic) că fiecare ETag este unic. Cu toate acestea, o funcție de creare a ETag-urilor poate fi considerată „utilă” dacă se poate dovedi (matematic) că crearea de ETag-uri identice este „acceptabil de rară”, chiar dacă poate sau va avea loc.
Se știe că unele funcții de control timpurii, cum ar fi CRC32 și CRC64, suferă de această problemă de coliziune . Din acest motiv, nu sunt buni candidați pentru utilizarea în generarea ETag-ului.
Mecanismul ETag acceptă atât verificările puternice, cât și cele slabe. Ele se disting prin prezența unui W/identificator ETag principal, de exemplu "123456789"(verificare ETag puternică), W/"123456789"(verificare ETag slabă).
O verificare puternică ETag verifică dacă conținutul din ambele resurse este identic octet cu octet și că toate celelalte câmpuri (cum ar fi Limba conținutului) sunt aceleași. Etichetele puternice permit ca răspunsurile parțiale să fie stocate în cache și asamblate, ca și în cazul cererilor de interval de octeți.
O verificare slabă ETag verifică doar dacă două resurse sunt echivalente din punct de vedere semantic, ceea ce înseamnă că, în scopuri practice, sunt interschimbabile și că pot fi utilizate copiile stocate în cache. Cu toate acestea, aceste resurse nu sunt neapărat identice octet cu octet, astfel încât ETag-urile slabe nu sunt potrivite pentru solicitările de interval de octeți. ETag-urile slabe pot fi utile în cazurile în care ETag-urile puternice nu sunt practice pentru a fi generate de un server web, cum ar fi în cazurile cu conținut generat dinamic.
În utilizare normală, atunci când o adresă URL este preluată, serverul web va returna resursa împreună cu valoarea ETag corespunzătoare, care se află în câmpul HTTP ETag:
ETag: "686897696a7c876b7e"
Clientul poate stoca în cache resursa împreună cu ETag-ul acesteia. Ulterior, dacă clientul dorește o pagină de la aceeași adresă, va trimite o copie ETag salvată anterior a acesteia împreună cu cererea în If-None-Match.
If-None-Match: "686897696a7c876b7e"
La această solicitare ulterioară, serverul poate compara acum ETag-ul clientului cu ETag-ul pentru versiunea curentă a resursei. Dacă valorile ETag se potrivesc, ceea ce înseamnă că resursa nu s-a schimbat, serverul poate trimite înapoi un răspuns foarte scurt cu o stare HTTP de 304 Not Modified . Starea 304 îi spune clientului că versiunea sa de cache este încă actualizată și că ar trebui să o folosească.
Cu toate acestea, dacă valorile ETag nu se potrivesc, ceea ce înseamnă că este posibil ca resursa să se fi schimbat, atunci răspunsul complet, inclusiv conținutul resursei, este returnat ca și cum ETag-ul nu ar fi fost folosit. În acest caz, clientul poate decide să înlocuiască versiunea resursei din cache cu versiunea recent returnată și noul ETag.
ETag poate fi folosit în paginile web pentru monitorizarea modificărilor și notificări. Monitorizarea eficientă a paginilor web este îngreunată de faptul că majoritatea site-urilor web nu setează anteturile Etag pe paginile web. Când monitorul web nu are nicio idee dacă conținutul web a fost modificat, tot conținutul trebuie preluat și analizat folosind resursele de calcul atât ale editorului conținutului, cât și ale celui care dorește să-l vizualizeze.
ETag-urile pot fi folosite pentru a urmări utilizatori unici [1], deoarece cookie-urile HTTP pot fi șterse de utilizatorii care caută confidențialitate. În iulie 2011, Ashkan Soltani și o echipă de cercetători de la UC Berkeley au raportat că o serie de site-uri web, inclusiv Hulu.com, foloseau ETag pentru a urmări astfel de ținte [2] . Hulu și KISSmetrics au încetat să facă acest lucru din 29 iulie 2011 [3] , deoarece KISSmetrics și peste 20 dintre clienții săi se confruntă cu un proces colectiv pentru utilizarea cookie-urilor de urmărire „nedemontabile”, în parte legate de utilizarea ETag [4] .
| http | |
|---|---|
| Concepte generale |
|
| Metode | |
| Titluri |
|
| Codurile de stare | |