El cache-control El encabezado es el mecanismo principal para que un servidor HTTP le indique a un proxy de almacenamiento en caché la "frescura" de una respuesta. (es decir, cómo/si es tiempo de almacenar la respuesta en el caché)
En algunas situaciones, las directivas cache-control son insuficientes. Un debate del grupo de trabajo HTTP está archivado here, que describe una página que solo cambia con el idioma. Esto es no el caso de uso correcto para el encabezado vary, pero el contexto es valioso para nuestra discusión. (Aunque creo que la cabecera Vary resolvería el problema en ese caso, no hay una mejor manera.) A partir de esa página:
Vary es estrictamente para aquellos casos en los que no hay esperanza o excesivamente complicado para un proxy para replicar lo que haría el servidor.
Un ejemplo artificioso:
Su servidor HTTP tiene una página de aterrizaje de gran tamaño. Tienes dos páginas ligeramente diferentes con la misma URL, dependiendo de si el usuario ha estado allí antes. Usted distingue entre las solicitudes y el "conteo de visitas" de un usuario basado en Cookies.Pero, dado que la página de destino de su servidor es tan grande, desea que los proxies intermediarios guarden en caché la respuesta si es posible.
Los encabezados URL, Last-Modified y Cache-Control son insuficientes para proporcionar esta información a un proxy de almacenamiento en caché, pero si agrega Vary: Cookie, el motor de caché agregará el encabezado Cookie a sus decisiones de almacenamiento en caché.
Finalmente, para tráfico pequeño, sitios web dinámicos: siempre he encontrado que el simple Cache-Control: no-cache, no-store y el Pragma: no-cache son suficientes.
Editar - para responder con mayor precisión a su pregunta: el encabezado de solicitud HTTP 'Aceptar' define los tipos de contenido que un cliente puede procesar. Si tiene dos copias del mismo contenido en la misma URL, que difieren solo en Content-Type, entonces podría ser apropiado usar Vary: Accept.
Actualización 11 12 de septiembre:
Estoy incluyendo un par de enlaces que han aparecido en los comentarios ya que este comentario fue originalmente publicado. Ambos son recursos excelentes para ejemplos del mundo real (y problemas) con Vary: Accept; Si estás leyendo esta respuesta, debes leer esos enlaces también.
El primero, del destacado EricLaw, sobre el comportamiento de Internet Explorer con el encabezado Vary y algunos de los desafíos que presenta a los desarrolladores: Vary Header Prevents Caching in IE. En resumen, IE (pre IE9) no almacena en caché ningún contenido que use el encabezado Vary porque el caché de solicitudes no incluye los encabezados de solicitud HTTP. EricLaw (Eric Lawrence en el mundo real) es un administrador de programa en el equipo de IE.
El segundo es de Eran Medan, y es una discusión en curso sobre el comportamiento inesperado relacionado con Vary en Chrome: Backing doesn't handle Vary header correctly. Está relacionado con el comportamiento de IE, excepto que los desarrolladores de Chrome adoptaron un enfoque diferente, aunque no parece haber sido una elección deliberada.
Francamente - no se moleste . Dejando de lado las fallas en la implementación en ese sitio, la única vez que obtendrás beneficios de servir con un tipo de contenido XML es cuando haces cosas que no se pueden hacer en texto/html, y si todo lo que estás haciendo está desconectando el Doctype y xmlns, entonces no vas a hacer esas cosas. Quédate con el texto/html. Para el caso, también podría apegarse a HTML 4.01. – Quentin
Sí, entiendo esto y creo que los "problemas" como este surgen con demasiada frecuencia en el desarrollo web. ¡Gracias a "debería" en las especificaciones/RFC! – AlexV
Probablemente deberías leer esto: http://blogs.msdn.com/ieinternals/archive/2009/06/17/Vary-Header-Prevents-Caching-in-IE.aspx antes de considerar usar VARY. – EricLaw