2. Validators (Validatori)

Questa specifica definisce due forme di metadati comunemente utilizzati per osservare lo stato delle risorse e testare le precondizioni: date di modifica (Sezione 2.2) e tag di entità opachi (Sezione 2.3). Metadati aggiuntivi che riflettono lo stato delle risorse sono stati definiti da varie estensioni di HTTP, come Web Distributed Authoring and Versioning (WebDAV, [RFC4918]), che sono al di fuori dell'ambito di questa specifica. Un valore di metadati di risorsa è chiamato "validatore" (validator) quando viene utilizzato all'interno di una precondizione.

2.1. Weak versus Strong (Debole versus forte)

I validatori esistono in due varianti: forti o deboli. I validatori deboli sono facili da generare ma sono molto meno utili per i confronti. I validatori forti sono ideali per i confronti ma possono essere molto difficili (e occasionalmente impossibili) da generare in modo efficiente. Piuttosto che imporre che tutte le forme di risorse aderiscano alla stessa forza del validatore, HTTP espone il tipo di validatore in uso e impone restrizioni su quando i validatori deboli possono essere utilizzati come precondizioni.

Un "validatore forte" (strong validator) è metadati di rappresentazione che cambiano valore ogni volta che si verifica una modifica ai dati di rappresentazione che sarebbe osservabile nel corpo del payload di una risposta 200 (OK) a GET.

Un validatore forte potrebbe cambiare per motivi diversi da una modifica ai dati di rappresentazione, ad esempio quando viene modificata una parte semanticamente significativa dei metadati di rappresentazione (ad esempio Content-Type), ma è nell'interesse del server di origine modificare il valore solo quando è necessario invalidare le risposte memorizzate detenute da cache remote e strumenti di authoring.

Le voci di cache possono persistere per periodi arbitrariamente lunghi, indipendentemente dai tempi di scadenza. Pertanto, una cache potrebbe tentare di validare una voce utilizzando un validatore che ha ottenuto in un passato lontano. Un validatore forte è unico in tutte le versioni di tutte le rappresentazioni associate a una particolare risorsa nel tempo. Tuttavia, non vi è alcuna implicazione di unicità tra le rappresentazioni di risorse diverse (cioè, lo stesso validatore forte potrebbe essere in uso per rappresentazioni di più risorse allo stesso tempo e non implica che tali rappresentazioni siano equivalenti).

Al contrario, un "validatore debole" (weak validator) è metadati di rappresentazione che potrebbero non cambiare per ogni modifica ai dati di rappresentazione. Questa debolezza potrebbe essere dovuta a limitazioni nel modo in cui viene calcolato il valore, come la risoluzione dell'orologio, l'incapacità di garantire l'unicità per tutte le possibili rappresentazioni della risorsa, o il desiderio del proprietario della risorsa di raggruppare le rappresentazioni secondo un insieme di equivalenza autodeterminato piuttosto che sequenze uniche di dati. Un server di origine DOVREBBE modificare un tag di entità debole ogni volta che considera le rappresentazioni precedenti inaccettabili come sostituto della rappresentazione corrente. In altre parole, un tag di entità debole dovrebbe cambiare ogni volta che il server di origine vuole che le cache invalidino le vecchie risposte.

I validatori forti sono utilizzabili per tutte le richieste condizionali, inclusa la validazione della cache, gli intervalli di contenuto parziale e l'evitamento dell'"aggiornamento perso". I validatori deboli sono utilizzabili solo quando il client non richiede un'uguaglianza esatta con i dati di rappresentazione precedentemente ottenuti, ad esempio quando si convalida una voce di cache o si limita un attraversamento web alle modifiche recenti.

2.2. Last-Modified (Ultima modifica)

Il campo di intestazione Last-Modified in una risposta fornisce un timestamp che indica la data e l'ora in cui il server di origine ritiene che la rappresentazione selezionata sia stata modificata per l'ultima volta, come determinato alla conclusione della gestione della richiesta.

Last-Modified = HTTP-date

Esempio di utilizzo:

Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT

2.2.1. Generation (Generazione)

Un server di origine DOVREBBE inviare Last-Modified per qualsiasi rappresentazione selezionata per la quale una data di ultima modifica può essere determinata in modo ragionevole e coerente, poiché il suo utilizzo nelle richieste condizionali e nella valutazione della freschezza della cache ([RFC7234]) si traduce in una riduzione sostanziale del traffico HTTP su Internet e può essere un fattore significativo nel miglioramento della scalabilità e dell'affidabilità del servizio.

Un server di origine DOVREBBE ottenere il valore Last-Modified della rappresentazione il più vicino possibile al momento in cui genera il valore del campo Date per la sua risposta. Ciò consente a un destinatario di effettuare una valutazione accurata del tempo di modifica della rappresentazione, specialmente se la rappresentazione cambia vicino al momento in cui viene generata la risposta.

Un server di origine con un orologio NON DEVE inviare una data Last-Modified successiva al tempo di origine del messaggio del server (Date). Se il tempo dell'ultima modifica è derivato da metadati specifici dell'implementazione che valutano un momento nel futuro, secondo l'orologio del server di origine, allora il server di origine DEVE sostituire quel valore con la data di origine del messaggio. Ciò impedisce che una data di modifica futura abbia un impatto negativo sulla validazione della cache.

2.2.2. Comparison (Confronto)

Un tempo Last-Modified, quando utilizzato come validatore in una richiesta, è implicitamente debole a meno che non sia possibile dedurre che sia forte, utilizzando regole specifiche definite nella specifica.

2.3. ETag

Il campo di intestazione ETag in una risposta fornisce il tag di entità corrente per la rappresentazione selezionata, come determinato alla conclusione della gestione della richiesta. Un tag di entità è un validatore opaco per differenziare tra più rappresentazioni della stessa risorsa, indipendentemente dal fatto che tali rappresentazioni multiple siano dovute a cambiamenti di stato della risorsa nel tempo, negoziazione del contenuto che risulta in più rappresentazioni valide contemporaneamente, o entrambi.

ETag = entity-tag

entity-tag = [ weak ] opaque-tag
weak = %x57.2F ; "W/", sensibile alle maiuscole
opaque-tag = DQUOTE *etagc DQUOTE
etagc = %x21 / %x23-7E / obs-text

Esempi:

ETag: "xyzzy"
ETag: W/"xyzzy"
ETag: ""

Un tag di entità può essere un validatore debole o forte, con forte come impostazione predefinita. Se un server di origine fornisce un tag di entità per una rappresentazione e la generazione di quel tag di entità non soddisfa tutte le caratteristiche di un validatore forte (Sezione 2.1), allora il server di origine DEVE contrassegnare il tag di entità come debole prefissando il suo valore opaco con W/ (sensibile alle maiuscole).

2.3.1. Generation (Generazione)

Il principio alla base dei tag di entità è che solo l'autore del servizio conosce l'implementazione di una risorsa abbastanza bene da selezionare il meccanismo di validazione più accurato ed efficiente per quella risorsa, e che qualsiasi tale meccanismo può essere mappato a una semplice sequenza di ottetti per un facile confronto. Poiché il valore è opaco, non è necessario che il client sia consapevole di come viene costruito ogni tag di entità.

Un server di origine DOVREBBE inviare un ETag per qualsiasi rappresentazione selezionata per la quale il rilevamento delle modifiche può essere determinato in modo ragionevole e coerente, poiché l'utilizzo del tag di entità nelle richieste condizionali e nella valutazione della freschezza della cache ([RFC7234]) può comportare una riduzione sostanziale del traffico di rete HTTP e può essere un fattore significativo nel miglioramento della scalabilità e dell'affidabilità del servizio.

2.3.2. Comparison (Confronto)

Esistono due funzioni di confronto dei tag di entità, a seconda che il contesto di confronto consenta o meno l'uso di validatori deboli:

• Confronto forte (Strong comparison): due tag di entità sono equivalenti se entrambi non sono deboli e i loro tag opachi corrispondono carattere per carattere.
• Confronto debole (Weak comparison): due tag di entità sono equivalenti se i loro tag opachi corrispondono carattere per carattere, indipendentemente dal fatto che uno o entrambi siano contrassegnati come "deboli".

L'esempio seguente mostra i risultati per un insieme di coppie di tag di entità:

ETag 1	ETag 2	Confronto forte	Confronto debole
W/"1"	W/"1"	nessuna corrispondenza	corrispondenza
W/"1"	W/"2"	nessuna corrispondenza	nessuna corrispondenza
W/"1"	"1"	nessuna corrispondenza	corrispondenza
"1"	"1"	corrispondenza	corrispondenza

2.4. When to Use Entity-Tags and Last-Modified Dates (Quando utilizzare i tag di entità e le date di ultima modifica)

Nelle risposte 200 (OK) a GET o HEAD, un server di origine:

• DOVREBBE inviare un validatore tag di entità a meno che non sia fattibile generarne uno.
• PUÒ inviare un tag di entità debole invece di un tag di entità forte, se considerazioni sulle prestazioni supportano l'uso di tag di entità deboli, o se è impossibile inviare un tag di entità forte.
• DOVREBBE inviare un valore Last-Modified se è fattibile inviarne uno.

In altre parole, il comportamento preferito per un server di origine è inviare sia un tag di entità forte che un valore Last-Modified nelle risposte riuscite a una richiesta di recupero.

Un client:

• DEVE inviare quel tag di entità in qualsiasi richiesta di validazione della cache (utilizzando If-Match o If-None-Match) se un tag di entità è stato fornito dal server di origine.
• DOVREBBE inviare il valore Last-Modified nelle richieste di validazione della cache non-sottointervallo (utilizzando If-Modified-Since) se solo un valore Last-Modified è stato fornito dal server di origine.
• DOVREBBE inviare entrambi i validatori nelle richieste di validazione della cache se sia un tag di entità che un valore Last-Modified sono stati forniti dal server di origine. Ciò consente sia alle cache HTTP/1.0 che HTTP/1.1 di rispondere in modo appropriato.