(Debole) ETags e Last-Modified

Question

Per quanto ne so le specifiche, l'ETag, che è stato introdotto in RFC 2616 (HTTP/1.1) è un successore (di sorta) per l'ultima intestazione modificata, che è Propongo di dare al software-architetto più controllo sul processo di riconvalida della cache.

Se sono presenti entrambe le intestazioni di convalida della cache (If-None-Match e If-Modified-Since), in base a RFC 2616, il client (ovvero il browser) deve utilizzare ETag durante il controllo, se una risorsa ha cambiato. Secondo la sezione 14.26 di RFC 2616, il server NON DEVE rispondere con un 304 Not Modified, se l'ETag presentato in un'intestazione di If-None-Match è stato modificato, e il server deve ignorare un'ulteriore If-Modified-Since-Header , se presente. Se l'ETag presentato corrisponde, NON DEVE eseguire la richiesta, a meno che la data nell'intestazione Last-Modified non lo dica. (Se l'ETag presentato corrisponde, il server deve rispondere con un 304 Not Modified in caso di GET o HEAD-richiesta ...)

Questa sezione lascia spazio ad alcune speculazioni:

• Una forte ETag dovrebbe cambiare "ogni volta", la risorsa cambia. Quindi, dover rispondere con qualcos'altro come 304 Non modificato per una richiesta con un ETag invariato e un If-Modified-Since-Header, che la dose non corrisponde è un po 'una contraddizione, perché il forte ETag dice che la risorsa era non modificato. (Anche se, questo non è che fatale, in quanto il server può inviare di nuovo la stessa risorsa invariato.)
• ...

... o.k. Mentre stavo scrivendo questo, la domanda si stava riducendo a questa risposta:

La (piccola) contraddizione di cui sopra, è stata fatta a causa di deboli ETag. Una risorsa contrassegnata con un ETag debole potrebbe essere cambiata, sebbene l'ETag non lo sia. Quindi, nel caso di un ETag debole, sarebbe sbagliato rispondere a 304 non modificato quando l'ETag non è cambiato, ma la data presentata in If-Modified-Since non corrisponde, giusto?

Answer 1

La differenza tra un ETag normale (forte) e un ETag debole è che un ETag forte corrispondente garantisce che il file sia identico byte per byte, mentre un ETag debole corrispondente indica che il contenuto è semanticamente uguale. Quindi, se il contenuto del file cambia, anche l'ETag debole dovrebbe cambiare.

Nello scenario si presenti, il file sul server può essere più recente rispetto alla copia memorizzata nella cache nel client - ma dato che l'ETag corrisponde, è semanticamente equivalente alla copia cache quindi sarebbe accettabile per restituire un 304 risposta.