3. Precondition Header Fields (Campi di intestazione delle precondizioni)

Questa sezione definisce la sintassi e la semantica dei campi di intestazione HTTP/1.1 per l'applicazione di precondizioni alle richieste. La Sezione 5 definisce quando le precondizioni vengono applicate. La Sezione 6 definisce l'ordine di valutazione quando è presente più di una precondizione.

3.1. If-Match

Il campo di intestazione If-Match rende il metodo di richiesta condizionale al fatto che il server di origine destinatario abbia almeno una rappresentazione corrente della risorsa di destinazione, quando il valore del campo è "*", o abbia una rappresentazione corrente della risorsa di destinazione che ha un tag di entità corrispondente a un membro dell'elenco di tag di entità forniti nel valore del campo.

Un server di origine DEVE utilizzare la funzione di confronto forte quando confronta i tag di entità per If-Match (Sezione 2.3.2), poiché il client intende che questa precondizione impedisca l'applicazione del metodo se ci sono stati cambiamenti nei dati di rappresentazione.

If-Match = "*" / 1#entity-tag

Esempi:

If-Match: "xyzzy"
If-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
If-Match: *

If-Match è più spesso utilizzato con metodi che modificano lo stato (ad esempio POST, PUT, DELETE) per prevenire sovrascritture accidentali quando più agenti utente potrebbero agire in parallelo sulla stessa risorsa (cioè per prevenire il problema dell'"aggiornamento perso"). Può anche essere utilizzato con metodi sicuri per interrompere una richiesta se la rappresentazione selezionata non corrisponde a una già memorizzata (o parzialmente memorizzata) da una richiesta precedente.

Un server di origine che riceve un campo di intestazione If-Match DEVE valutare la condizione prima di eseguire il metodo (Sezione 5). Se il valore del campo è "*", la condizione è false se il server di origine non ha una rappresentazione corrente per la risorsa di destinazione. Se il valore del campo è un elenco di tag di entità, la condizione è false se nessuno dei tag elencati corrisponde al tag di entità della rappresentazione selezionata.

Un server di origine NON DEVE eseguire il metodo richiesto se una condizione If-Match ricevuta viene valutata come false; invece, il server di origine DEVE rispondere con a) il codice di stato 412 (Precondition Failed) o b) uno dei codici di stato 2xx (Successful) se il server di origine ha verificato che viene richiesto un cambiamento di stato e lo stato finale è già riflesso nello stato corrente della risorsa di destinazione.

Il campo di intestazione If-Match può essere ignorato da cache e intermediari perché non è applicabile a una risposta memorizzata.

3.2. If-None-Match

Il campo di intestazione If-None-Match rende il metodo di richiesta condizionale al fatto che una cache o server di origine destinatario non abbia alcuna rappresentazione corrente della risorsa di destinazione, quando il valore del campo è "*", o abbia una rappresentazione selezionata con un tag di entità che non corrisponde a nessuno di quelli elencati nel valore del campo.

Un destinatario DEVE utilizzare la funzione di confronto debole quando confronta i tag di entità per If-None-Match (Sezione 2.3.2), poiché i tag di entità deboli possono essere utilizzati per la validazione della cache anche se ci sono stati cambiamenti nei dati di rappresentazione.

If-None-Match = "*" / 1#entity-tag

Esempi:

If-None-Match: "xyzzy"
If-None-Match: W/"xyzzy"
If-None-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
If-None-Match: W/"xyzzy", W/"r2d2xxxx", W/"c3piozzzz"
If-None-Match: *

If-None-Match è principalmente utilizzato nelle richieste GET condizionali per abilitare aggiornamenti efficienti delle informazioni in cache con un minimo di overhead transazionale. Quando un client desidera aggiornare una o più risposte memorizzate che hanno tag di entità, il client DOVREBBE generare un campo di intestazione If-None-Match contenente un elenco di quei tag di entità quando effettua una richiesta GET; ciò consente ai server destinatari di inviare una risposta 304 (Not Modified) per indicare quando una di quelle risposte memorizzate corrisponde alla rappresentazione selezionata.

If-None-Match può anche essere utilizzato con un valore di "*" per impedire a un metodo di richiesta non sicuro (ad esempio PUT) di modificare inavvertitamente una rappresentazione esistente della risorsa di destinazione quando il client ritiene che la risorsa non abbia una rappresentazione corrente.

Un server di origine che riceve un campo di intestazione If-None-Match DEVE valutare la condizione prima di eseguire il metodo (Sezione 5). Se il valore del campo è "*", la condizione è false se il server di origine ha una rappresentazione corrente per la risorsa di destinazione. Se il valore del campo è un elenco di tag di entità, la condizione è false se uno dei tag elencati corrisponde al tag di entità della rappresentazione selezionata.

Un server di origine NON DEVE eseguire il metodo richiesto se la condizione viene valutata come false; invece, il server di origine DEVE rispondere con a) il codice di stato 304 (Not Modified) se il metodo di richiesta è GET o HEAD o b) il codice di stato 412 (Precondition Failed) per tutti gli altri metodi di richiesta.

3.3. If-Modified-Since

Il campo di intestazione If-Modified-Since rende un metodo di richiesta GET o HEAD condizionale al fatto che la data di modifica della rappresentazione selezionata sia più recente della data fornita nel valore del campo. Il trasferimento dei dati della rappresentazione selezionata viene evitato se quei dati non sono cambiati.

If-Modified-Since = HTTP-date

Esempio del campo:

If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT

Un destinatario DEVE ignorare If-Modified-Since se la richiesta contiene un campo di intestazione If-None-Match; la condizione in If-None-Match è considerata una sostituzione più accurata della condizione in If-Modified-Since, e le due sono combinate solo per interoperare con intermediari più vecchi che potrebbero non implementare If-None-Match.

Un destinatario DEVE ignorare il campo di intestazione If-Modified-Since se il valore del campo ricevuto non è una HTTP-date valida, o se il metodo di richiesta non è né GET né HEAD.

If-Modified-Since è tipicamente utilizzato per due scopi distinti: 1) per consentire aggiornamenti efficienti di una rappresentazione in cache che non ha un tag di entità e 2) per limitare l'ambito di un attraversamento web alle risorse che sono cambiate di recente.

Un server di origine che riceve un campo di intestazione If-Modified-Since DOVREBBE valutare la condizione prima di eseguire il metodo (Sezione 5). Il server di origine NON DOVREBBE eseguire il metodo richiesto se la data dell'ultima modifica della rappresentazione selezionata è anteriore o uguale alla data fornita nel valore del campo; invece, il server di origine DOVREBBE generare una risposta 304 (Not Modified), includendo solo quei metadati che sono utili per identificare o aggiornare una risposta precedentemente memorizzata in cache.

3.4. If-Unmodified-Since

Il campo di intestazione If-Unmodified-Since rende il metodo di richiesta condizionale al fatto che la data dell'ultima modifica della rappresentazione selezionata sia anteriore o uguale alla data fornita nel valore del campo. Questo campo realizza lo stesso scopo di If-Match per i casi in cui l'agente utente non ha un tag di entità per la rappresentazione.

If-Unmodified-Since = HTTP-date

Esempio del campo:

If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT

Un destinatario DEVE ignorare If-Unmodified-Since se la richiesta contiene un campo di intestazione If-Match; la condizione in If-Match è considerata una sostituzione più accurata della condizione in If-Unmodified-Since, e le due sono combinate solo per interoperare con intermediari più vecchi che potrebbero non implementare If-Match.

Un destinatario DEVE ignorare il campo di intestazione If-Unmodified-Since se il valore del campo ricevuto non è una HTTP-date valida.

If-Unmodified-Since è più spesso utilizzato con metodi che modificano lo stato (ad esempio POST, PUT, DELETE) per prevenire sovrascritture accidentali quando più agenti utente potrebbero agire in parallelo su una risorsa che non fornisce tag di entità con le sue rappresentazioni (cioè per prevenire il problema dell'"aggiornamento perso").

Un server di origine che riceve un campo di intestazione If-Unmodified-Since DEVE valutare la condizione prima di eseguire il metodo (Sezione 5). Il server di origine NON DEVE eseguire il metodo richiesto se la data dell'ultima modifica della rappresentazione selezionata è più recente della data fornita nel valore del campo; invece il server di origine DEVE rispondere con a) il codice di stato 412 (Precondition Failed) o b) uno dei codici di stato 2xx (Successful) se il server di origine ha verificato che viene richiesto un cambiamento di stato e lo stato finale è già riflesso nello stato corrente della risorsa di destinazione.

Il campo di intestazione If-Unmodified-Since può essere ignorato da cache e intermediari perché non è applicabile a una risposta memorizzata.

3.5. If-Range

Il campo di intestazione If-Range fornisce un meccanismo di richiesta condizionale speciale che è simile ai campi di intestazione If-Match e If-Unmodified-Since ma che istruisce il destinatario a ignorare il campo di intestazione Range se il validatore non corrisponde, risultando nel trasferimento della nuova rappresentazione selezionata invece di una risposta 412 (Precondition Failed). If-Range è definito nella Sezione 3.2 di [RFC7233].