HTTP ETag - HTTP ETag

HTTP
Metodi di richiesta
Campi di intestazione
Codici di stato di risposta
Metodi di controllo dell'accesso di sicurezza
Vulnerabilità di sicurezza

L' ETag o tag di entità fa parte di HTTP , il protocollo per il World Wide Web . È uno dei numerosi meccanismi forniti da HTTP per la convalida della cache Web , che consente a un client di effettuare richieste condizionali. Questo meccanismo consente alle cache di essere più efficienti e di risparmiare larghezza di banda, poiché un server Web non ha bisogno di inviare una risposta completa se il contenuto non è cambiato. Gli ETag possono essere utilizzati anche per il controllo ottimistico della concorrenza per impedire che gli aggiornamenti simultanei di una risorsa si sovrascrivano a vicenda.

Un ETag è un identificatore opaco assegnato da un server Web a una versione specifica di una risorsa trovata in un URL . Se la rappresentazione della risorsa in quell'URL cambia, viene assegnato un nuovo e diverso ETag. Utilizzati in questo modo, gli ETag sono simili alle impronte digitali e possono essere rapidamente confrontati per determinare se due rappresentazioni di una risorsa sono uguali.

Generazione ETag

L'uso di ETag nell'intestazione HTTP è facoltativo (non obbligatorio come per altri campi dell'intestazione HTTP 1.1). Il metodo con cui vengono generati gli ETag non è mai stato specificato nella specifica HTTP.

I metodi comuni di generazione di ETag includono l'utilizzo di una funzione hash resistente alle collisioni del contenuto della risorsa, un hash del timestamp dell'ultima modifica o anche solo un numero di revisione .

Al fine di evitare l'uso di dati cache obsoleti, i metodi utilizzati per generare ETag dovrebbero garantire (per quanto possibile) che ogni ETag sia unico. Tuttavia, una funzione di generazione di ETag potrebbe essere giudicata "utilizzabile", se si può dimostrare (matematicamente) che la duplicazione di ETag sarebbe "accettabilmente rara", anche se potrebbe o si verificherebbe.

RFC-7232 afferma esplicitamente che gli ETag dovrebbero essere consapevoli della codifica del contenuto , ad es 

ETag: "123-a" – for no Content-Encoding
ETag: "123-b" – for Content-Encoding: gzip

Alcune funzioni di checksum precedenti che erano più deboli di CRC32 o CRC64 sono note per soffrire di problemi di collisione di hash. Quindi non erano buoni candidati per l'uso nella generazione di ETag.

Convalida forte e debole

Il meccanismo di ETag supporta sia forte la convalida e la convalida deboli . Si distinguono per la presenza di un iniziale "W/" nell'identificatore ETag, come: 

"123456789"   – A strong ETag validator
W/"123456789" – A weak ETag validator

Una corrispondenza ETag fortemente convalidante indica che il contenuto delle due rappresentazioni delle risorse è identico byte per byte e che anche tutti gli altri campi entità (come Content-Language) sono invariati. Gli ETag forti consentono la memorizzazione nella cache e il riassemblaggio di risposte parziali, come con le richieste di intervallo di byte .

Una corrispondenza ETag con validazione debole indica solo che le due rappresentazioni sono semanticamente equivalenti , il che significa che per scopi pratici sono intercambiabili e che possono essere utilizzate copie memorizzate nella cache. Tuttavia, le rappresentazioni delle risorse non sono necessariamente identiche byte per byte e quindi gli ETag deboli non sono adatti per le richieste dell'intervallo di byte. Gli ETag deboli possono essere utili nei casi in cui gli ETag forti non sono pratici da generare per un server Web, ad esempio con contenuti generati dinamicamente .

Utilizzo tipico

Nell'uso tipico, quando viene recuperato un URL, il server Web restituirà la rappresentazione corrente della risorsa insieme al suo valore ETag corrispondente, che viene inserito nel campo "ETag" di un'intestazione di risposta HTTP: 

ETag: "686897696a7c876b7e"

Il cliente può quindi decidere di memorizzare nella cache la rappresentazione, insieme al suo ETag. Successivamente, se il client desidera recuperare nuovamente la stessa risorsa URL, determinerà prima se la versione dell'URL memorizzata nella cache locale è scaduta (tramite le intestazioni Cache-Control e Expire). Se l'URL non è scaduto, recupererà la risorsa memorizzata nella cache locale. Se viene determinato che l'URL è scaduto (non è aggiornato ), il client invierà una richiesta al server che include la sua copia precedentemente salvata dell'ETag nel campo "If-None-Match". 

If-None-Match: "686897696a7c876b7e"

In questa successiva richiesta, il server può ora confrontare l'ETag del client con l'ETag per la versione corrente della risorsa. Se i valori ETag corrispondono, il che significa che la risorsa non è cambiata, il server potrebbe inviare una risposta molto breve con uno stato HTTP 304 Non modificato . Lo stato 304 dice al client che la sua versione memorizzata nella cache è ancora valida e che dovrebbe usarla.

Tuttavia, se i valori ETag non corrispondono, il che significa che la risorsa è probabilmente cambiata, viene restituita una risposta completa che include il contenuto della risorsa, proprio come se gli ETag non fossero utilizzati. In questo caso, il client può decidere di sostituire la sua versione precedentemente memorizzata nella cache con la rappresentazione della risorsa appena restituita e il nuovo ETag.

I valori ETag possono essere utilizzati nei sistemi di monitoraggio delle pagine Web . Il monitoraggio efficiente delle pagine Web è ostacolato dal fatto che la maggior parte dei siti Web non imposta le intestazioni ETag per le pagine Web. Quando un monitor Web non ha alcun indizio se il contenuto Web è stato modificato, tutto il contenuto deve essere recuperato e analizzato utilizzando risorse di elaborazione sia per l'editore che per l'abbonato.

Rilevamento ETag non corrispondente

Un sito web difettoso può a volte non riuscire ad aggiornare l'ETag dopo che la sua risorsa semantica è stata aggiornata. A partire dal 2019, un esempio di un importante sito di questo tipo è export.arxiv.org . Di conseguenza, la risposta restituita in modo non corretto è lo stato 304 e il client non riesce a recuperare la risorsa aggiornata. Per rilevare un sito web così pieno di bug:

  • Memorizza nella cache la risposta e l'ETag, supponendo che ci sia un ETag e che la risposta non sia stata interrotta.
  • Per una richiesta successiva che avrebbe incluso l'intestazione If-None-Match, non inviare questa intestazione con una probabilità casuale del 20%. Con questa probabilità, se la risposta restituisce un contenuto alterato ma lo stesso ETag di quello precedentemente memorizzato nella cache, contrassegna il sito Web come bacato e disabilita la memorizzazione nella cache di ETag. Come promemoria, per un ETag forte, il confronto del contenuto può essere byte per byte, mentre, per un ETag debole, verificherebbe solo l'equivalenza semantica.

Monitoraggio tramite ETags

Gli ETag possono essere utilizzati per tracciare gli utenti unici, poiché i cookie HTTP vengono sempre più eliminati dagli utenti attenti alla privacy. Nel luglio 2011, Ashkan Soltani e un team di ricercatori dell'UC Berkeley hanno riferito che un certo numero di siti Web, incluso Hulu , utilizzavano gli ETag per scopi di monitoraggio. Hulu e KISSmetrics hanno entrambi cessato di "respawnare" a partire dal 29 luglio 2011, poiché KISSmetrics e oltre 20 dei suoi clienti stanno affrontando un'azione legale collettiva sull'uso di cookie di tracciamento "non cancellabili" che coinvolgono parzialmente l'uso di ETags.

Poiché gli ETag vengono memorizzati nella cache dal browser e restituiti con successive richieste per la stessa risorsa, un server di monitoraggio può semplicemente ripetere qualsiasi ETag ricevuto dal browser per garantire che un ETag assegnato persista indefinitamente (in modo simile ai cookie persistenti ). Ulteriori intestazioni di memorizzazione nella cache possono anche migliorare la conservazione dei dati ETag.

Gli ETag possono essere scaricati svuotando la cache del browser (le implementazioni variano).

Riferimenti

link esterno