Il cache-control header è il meccanismo principale per un server HTTP per dire a un proxy di caching la "freschezza" di una risposta. (vale a dire, se è lungo per memorizzare la risposta nella cache)
In alcune situazioni, le direttive cache-control non sono sufficienti. Una discussione dal gruppo di lavoro HTTP è archiviata here, che descrive una pagina che cambia solo con la lingua. Questo è non il caso d'uso corretto per l'intestazione vari, ma il contesto è prezioso per la nostra discussione. (Anche se credo che il Vary intestazione risolverebbe il problema in questo caso, c'è un modo migliore.) Da quella pagina:
Vary è strettamente per quei casi in cui non c'è speranza o eccessivamente complicato per un proxy per replicare ciò che il server farebbe.
Un esempio inventato:
Il server HTTP ha una pagina di destinazione di grandi dimensioni. Hai due pagine leggermente diverse con lo stesso URL, a seconda che l'utente sia già stato lì. Distingui tra le richieste e il "conteggio delle visite" di un utente in base ai cookie.Ma, poiché la pagina di destinazione del server è così grande, si desidera che i proxy intermedi memorizzino la risposta nella cache, se possibile.
Le intestazioni URL, Last-Modified e Cache-Control non sono sufficienti per fornire questo dettaglio a un proxy di memorizzazione nella cache, ma se si aggiunge Vary: Cookie, il motore della cache aggiungerà l'intestazione del cookie alle sue decisioni di memorizzazione nella cache.
Infine, per il traffico di piccole dimensioni, siti Web dinamici: ho sempre trovato sufficiente il semplice Cache-Control: no-cache, no-store e Pragma: no-cache.
Modifica - per rispondere in modo più preciso alla domanda: l'intestazione della richiesta HTTP "Accetta" definisce i tipi di contenuto che un client può elaborare. Se hai due copie dello stesso contenuto sullo stesso URL, differendo solo in Content-Type, allora potrebbe essere appropriato usare Vary: Accept.
Aggiornamento 11 Settembre 12:
sto tra cui un paio di link che sono apparse nei commenti dal momento che questo commento è stato originariamente pubblicato. Sono entrambe risorse eccellenti per esempi (e problemi) reali con Vary: Accept; Se stai leggendo questa risposta, devi leggere anche questi link.
Il primo, dall'eccezionale EricLaw, sul comportamento di Internet Explorer con l'intestazione Vary e alcune delle sfide che presenta agli sviluppatori: Vary Header Prevents Caching in IE. In breve, IE (pre IE9) non memorizza nella cache alcun contenuto che utilizza l'intestazione Vary poiché la cache della richiesta non include le intestazioni di richiesta HTTP. EricLaw (Eric Lawrence nel mondo reale) è un Program Manager del team di IE.
Il secondo è di Eran Medan, ed è una discussione in corso sul comportamento imprevisto relativo a Varia in Chrome: Backing doesn't handle Vary header correctly. È legato al comportamento di IE, tranne che gli sviluppatori di Chrome hanno adottato un approccio diverso, anche se non sembra essere stata una scelta deliberata.
Francamente - non si preoccupano . Lasciando da parte i difetti nell'implementazione su quel sito, l'unica volta in cui si ottengono benefici dal servire con un tipo di contenuto XML è quando si fanno cose che non possono essere fatte in text/html - e se tutto ciò che si sta facendo sta cambiando Doctype e xmlns, quindi non farai queste cose. Attenersi a text/html. Del resto, potresti anche limitarti a HTML 4.01. – Quentin
Sì, lo capisco e penso che "problemi" come questo sorgano troppo spesso nello sviluppo del Web. Grazie a "dovrebbe" nelle specifiche/RFC! – AlexV
Probabilmente dovresti leggere questo: http://blogs.msdn.com/ieinternals/archive/2009/06/17/Vary-Header-Prevents-Caching-in-IE.aspx prima di prendere in considerazione l'utilizzo di VARY. – EricLaw