Conoscete qualche uso pratico di If-Unmodified-Since in the wild? Da description, sembra che questa intestazione avesse lo scopo di aiutare a evitare le scritture sporche. Ad esempio, aggiorna questa risorsa solo se non è stata modificata dall'ultima modifica tempo disponibile con il client. A differenza di If-Modified-Since, non sembra essere d'aiuto con il caching. Mi sto perdendo qualcosa?Qual è l'uso di If-Unmodified-Since HTTP Header?
Puoi usarlo per es. per un range request.
esempio: il client richiede la risorsa http://examp.le/foo?id=3 e la lunghezza del contenuto è 4096 ma il client richiede solo i primi 1024 byte. Può quindi (in un secondo momento) richiedere i restanti 3072 byte ma ciò non ha senso se la risorsa è cambiata nel frattempo.
modifica: Inoltre, potrebbe non essere necessario modificare/aggiornare i dati se la risorsa è stata modificata nel frattempo. Per esempio. si richiede un record del cliente e si modifica qualcosa. Se qualcun altro ha modificato il record nel frattempo, ciò potrebbe portare a incongruenze. Pertanto, invia gli aggiornamenti con un'intestazione if-non-modificata-poiché (-I-recuperati-i-dati) e il server web dovrà/rifiuterà gli aggiornamenti se il record è già stato modificato - il client può quindi richiedere i dati "in conflitto".
edit2: poiché è stato richiesto "qualsiasi utilizzo pratico di If-Unmodified-Since in the wild": vedere http://msdn.microsoft.com/en-us/library/dd179371.aspx#Subheading1.
Supponiamo che tu abbia prima requested the Blob properties. Ora sai per es. il tipo di contenuto e la lunghezza del contenuto (forse è necessario per questo tipo di allocazione). Qualcuno/qualcosa potrebbe cambiare il blob prima di inviare la seconda richiesta, Get Blob. Se si invia il valore Last-Modified come valore dell'intestazione If-Unmodified-Since, il server risponderà con il codice di errore appropriato se il blob è cambiato.
Supponiamo che tu stia sviluppando un'applicazione che mostra il tempo locale per un determinato luogo. Se il server aggiorna solo le informazioni meteo "x" volte al giorno, il browser può fare attenzione a non effettuare una richiesta http entro quel periodo di tempo (anche se c'è un aggiornamento).
È utile quando si riprendono download di grandi dimensioni.
È utile per più richieste, condotte su un periodo di tempo, ma relative a una singola risorsa invariata.
Esempi:
richieste di intervallo. La risposta alla prima richiesta di intervallo (o forse un HEAD preliminare) include l'intestazione Last-Modified. Le richieste successive sono intese solo per la stessa versione di quella risorsa. Se la risorsa cambia tra il momento in cui abbiamo iniziato la sequenza di richieste di intervallo e un po 'di tempo nel mezzo della sequenza, vogliamo ricominciare da capo.
Controllo di concorrenza ottimistico. Per prima cosa introduciamo GET una risorsa, apportiamo alcune modifiche sul lato client e desideriamo di PUT la risorsa aggiornata. Ma vogliamo solo PUT la risorsa aggiornata fintanto che nessun altro lo ha aggiornato nel frattempo. Non vogliamo sovrascrivere le modifiche di nessuno. Se si scopre che qualcuno ha cambiato la risorsa nel frattempo, vogliamo di nuovo GET, provare a riapplicare le modifiche nel client (una specie di tipo git rebase) e provare a PUT la risorsa modificata di nuovo.
Il mio primo pensiero era solo "controllo della concorrenza". Buona presa sulle richieste di portata! – rix0rrr
È più adatto per il controllo della concorrenza. Non so perché questa risposta abbia un voto così alto, ma l'intestazione Range è più adatta per le richieste di intervallo. per esempio. Intervallo: byte = 1024- – sotn
@sotn L'OP ha chiesto "l'uso pratico di If-Unmodified-Since in the wild", quindi non ho fornito un concetto come risposta ma 2.5 esempi di controllo della concorrenza. Ma forse hai ragione; aggiungerà un altro piccolo paragrafo. – VolkerK