Per due richieste successive, a quale delle seguenti due intestazioni viene assegnato un peso maggiore dai browser, se uno di questi cambia: ETag o Ultima modifica?Che cosa ha la precedenza: l'intestazione ETag o Last-Modified HTTP?
Non è più come un'espressione "OR". In pseudo codice:
if ETagFromServer != ETagOnClient || LastModifiedFromServer != LastModifiedOnClient
GetFromServer
else
GetFromCache
Secondo RFC 2616 sezione 13.3.4, un client HTTP 1.1 deve utilizzare l'ETag in eventuali richieste di cache-condizionale, e se sia un ETag e Last Modified sono presenti, è DOVREBBE utilizzare entrambi. L'intestazione ETag è considerata un valido validatore (vedere la sezione 13.3.3), a meno che non sia dichiarato esplicitamente debole dal server, mentre l'intestazione Last Modified è considerata debole a meno che esista almeno una differenza minima tra esso e l'intestazione Data. Si noti, tuttavia, che il server non è tenuto a inviare entrambi (ma DOVREBBE, se possibile).
Si noti che il client non controlla le intestazioni per vedere se sono state modificate; li usa solo ciecamente nella successiva richiesta condizionale; spetta al server valutare se inviare il contenuto richiesto o una risposta 304 non modificata. Se il server ne invia uno solo, il client utilizzerà quello solo (sebbene solo i validatori validi siano utili per una richiesta di intervallo). Naturalmente, è anche a discrezione delle cache intermedie (a meno che non sia stato impedito il caching tramite le direttive Cache Control) e il Server su come agiranno sulle intestazioni; la RFC afferma che NON DEVONO restituire un 304 non modificato se i validatori sono inconsistenti, ma poiché i valori dell'intestazione sono generati dal server, ha abbastanza margine di manovra.
In pratica, ho notato che Chrome, FireFox e IE 7+ inviano entrambe le intestazioni, se disponibili. Ho anche testato il comportamento durante l'invio di intestazioni modificate, che avevo già sospettato dalle informazioni nella RFC. I quattro client che ho provato hanno inviato solo richieste condizionali se le pagine sono state aggiornate o se era la prima volta che la pagina era stata richiesta dal processo corrente.
Ottima risposta, Thomas. Grazie per aver fornito le specifiche ufficiali e discusso delle attuali implementazioni del browser. – dthrasher
Citazione dalla sezione 14.26, ** il server NON DEVE eseguire il metodo richiesto, a meno che non sia richiesto perché la data di modifica della risorsa non corrisponde a quella fornita in un campo di intestazione If-Modified-Since nella richiesta. ** Look come If-Modified-Since ha la precedenza. – Vicary
=! è l'operatore di confronto corretto. Il client è tenuto a mantenere la stringa letterale ricevuta dal server, poiché le conversioni possono creare piccole differenze. Non puoi supporre che "più nuovo sia migliore".
Perché? Considerare il caso in cui l'operatore del server ripristina una versione errata di una risorsa. La versione ripristinata è più vecchia, ma corretta.
Il client deve utilizzare la versione attualmente offerta dal server; può usare una versione cache solo se è la stessa. Quindi il server deve controllare l'uguaglianza, non "più nuovo".
Penso che l'ultimo timestamp modificato debba essere confrontato in modo diverso, come in: se ETagFromServer! = ETagOnClient || LastModifiedFromServer> LastModifiedOnClient – RoyM
È un'istruzione AND perché l'ETag può essere debole, nel qual caso potresti avere un'entità semanticamente equivalente e poi ricorrere all'ultima intestazione modificata. Considera una situazione in cui un'immagine può essere ricodificata e vogliamo dire che l'originale e la re-encoding sono gli stessi nonostante il fatto che non siano identici al byte. In questo caso vogliamo usare l'ultima modifica come fallback ed è per questo che ENTRAMBI devono essere coerenti – ParoX