expires - incomplete or no cache control and pragma http header set apache
¿Cuál es la diferencia entre Cache-Control: max-age=0 y no-cache? (9)
Aquí hay un pequeño árbol de decisiones que espero aclare la diferencia.
El encabezado Cache-Control: max-age=0 implica que el contenido se considera obsoleto (y debe ser recuperado) de inmediato, lo que en efecto es lo mismo que Cache-Control: no-cache .
En mis pruebas recientes con IE8 y Firefox 3.5, parece que ambas son compatibles con RFC. Sin embargo, difieren en su "amistad" con el servidor de origen. IE8 trata no-cache respuestas no-cache con la misma semántica que max-age=0,must-revalidate . Firefox 3.5, sin embargo, parece tratar la no-cache como equivalente a la no-store , lo que apesta para el rendimiento y el uso del ancho de banda.
Squid Cache, de forma predeterminada, parece que nunca almacena nada con un encabezado no-cache , al igual que Firefox.
Mi consejo sería establecer public,max-age=0 para los recursos no confidenciales que desea que se verifiquen en cada solicitud, pero aún así permita los beneficios de rendimiento y ancho de banda del almacenamiento en caché. Para los elementos por usuario con la misma consideración, use private,max-age=0 .
Evitaría el uso de no-cache completo, ya que parece que ha sido bastardizado por algunos navegadores y cachés populares al equivalente funcional de no-store .
Además, no emular Akamai y Limelight. Si bien esencialmente ejecutan matrices de almacenamiento en caché masivo como su negocio principal, y deberían ser expertos, en realidad tienen un gran interés en hacer que se descarguen más datos de sus redes. Google podría no ser una buena opción para la emulación, tampoco. Parece que usan max-age=0 o no-cache al azar dependiendo del recurso.
La diferencia es que no-cache (no-store en Firefox) evita cualquier tipo de almacenamiento en caché. Esto puede ser útil para evitar que las páginas con contenido seguro se escriban en el disco y para las páginas que siempre deben actualizarse, incluso si se vuelven a visitar con el botón Atrás.
max-age = 0 indica que una entrada de caché está obsoleta y requiere una nueva validación, pero no impide el almacenamiento en caché. A menudo, los navegadores solo validan los recursos una vez por sesión, por lo que es posible que el contenido no se actualice hasta que se visite el sitio en una nueva sesión.
Por lo general, los navegadores no eliminarán las entradas de caché caducadas, a menos que estén reclamando el espacio para el contenido más reciente cuando la caché del navegador esté llena. Al utilizar no-store, no-cache permite que una entrada de caché se elimine explícitamente.
La vieja pregunta ahora, pero si alguien más se encuentra con esto a través de una búsqueda como lo hice, parece que IE9 utilizará esto para configurar el comportamiento de los recursos cuando se usan los botones de avance y retroceso. Cuando se usa max-age = 0 , el navegador usará la última versión cuando vea un recurso en una pulsación de avance / retroceso. Si se utiliza no-cache , el recurso se volverá a obtener.
Se pueden ver más detalles sobre el almacenamiento en caché de IE9 en esta publicación de blog de almacenamiento en caché de msdn .
No soy un experto en caché, pero Mark Nottingham lo es. Aquí están sus documentos de almacenamiento en caché . También tiene excelentes enlaces en la sección de Referencias.
Según mi lectura de esos documentos, parece que max-age=0 podría permitir que la memoria caché envíe una respuesta en caché a las solicitudes que llegaron al "mismo tiempo", donde "mismo tiempo" significa lo suficientemente cerca como para que se vean simultáneas al caché, pero no-cache no lo haría.
Por cierto, vale la pena señalar que algunos dispositivos móviles, en particular los productos de Apple como iPhone / iPad, ignoran por completo los encabezados como no-cache, no-store, Expires: 0, o cualquier otra cosa que intente forzarlos a no reutilizarse. páginas de formularios.
Esto nos ha causado un sinfín de dolores de cabeza cuando intentamos resolver el problema del iPad de un usuario, quedarnos dormidos en una página a la que han llegado a través de un proceso de formulario, por ejemplo, el paso 2 de 3, y luego el dispositivo ignora por completo la tienda / Las directivas de caché, y por lo que puedo decir, simplemente toman lo que es una instantánea virtual de la página desde su último estado, es decir, ignorando lo que se le dijo explícitamente y, no solo eso, tomando una página que no debería almacenarse. y almacenarlo sin volverlo a comprobar, lo que conduce a todo tipo de problemas extraños de sesión, entre otras cosas.
Solo estoy agregando esto en caso de que alguien venga y no pueda entender por qué están obteniendo errores de sesión con particularmente iphones e ipads, que parecen ser los peores delincuentes en esta área.
He realizado pruebas de depuración bastante extensas con este problema, y esta es mi conclusión: los dispositivos ignoran estas directivas por completo.
Incluso en el uso regular, he encontrado que algunos móviles tampoco pueden verificar las nuevas versiones a través de, Expires: 0 y luego verificar las últimas fechas modificadas para determinar si debería obtener una nueva.
Simplemente no sucede, por lo que me vi obligado a agregar cadenas de consulta a los archivos css / js que necesitaba para forzar las actualizaciones, lo que engaña a los estúpidos dispositivos móviles para que piensen que es un archivo que no tiene, como: mi .css? v = 1, luego v = 2 para una actualización css / js. Esto funciona en gran medida.
Los navegadores de usuarios también, por cierto, si se dejan a sus valores predeterminados, a partir de 2016, como descubro continuamente (hacemos MUCHOS cambios y actualizaciones a nuestro sitio) tampoco pueden verificar las últimas fechas modificadas en dichos archivos, pero la consulta método de cadena corrige ese problema. Esto es algo que he notado con clientes y personas de oficina que tienden a usar los valores predeterminados básicos de los usuarios en sus navegadores, y no tienen conocimiento de los problemas de almacenamiento en caché con css / js, etc., casi siempre fallan en obtener el nuevo css / js en el cambio, lo que significa que los valores predeterminados para sus navegadores, en su mayoría MSIE / Firefox, no están haciendo lo que se les dice que hagan, ignoran los cambios e ignoran las fechas de las últimas modificaciones y no validan, incluso con Expires: 0 establecido explícitamente.
Este fue un buen hilo con mucha buena información técnica, pero también es importante tener en cuenta lo malo que es el soporte para este tipo de dispositivos, particularmente en dispositivos móviles. Cada pocos meses tengo que agregar más capas de protección contra su falla para seguir los comandos de encabezado que reciben, o para interpretar adecuadamente esos comandos.
Tuve la misma pregunta y encontré información en mis búsquedas (su pregunta surgió como uno de los resultados). Esto es lo que determiné ...
Hay dos lados para el encabezado Cache-Control . Un lado es donde puede ser enviado por el servidor web (también conocido como "servidor de origen"). El otro lado es donde puede ser enviado por el navegador (también conocido como "agente de usuario").
Cuando es enviado por el servidor de origen
Creo que max-age=0 simplemente le dice a los cachés (y a los agentes de usuario) que la respuesta es obsoleta desde el primer momento y, por lo tanto, DEBERÍAN revalidar la respuesta (por ejemplo, con el encabezado If-Not-Modified ) antes de usar una copia en caché, mientras que , no-cache les dice que DEBEN volver a validarse antes de usar una copia en caché. A partir de 14.9.1 lo que es cacheable :
no-caché
... un caché NO DEBE usar la respuesta para satisfacer una solicitud posterior sin una revalidación exitosa con el servidor de origen. Esto permite que un servidor de origen evite el almacenamiento en caché incluso por los cachés que se han configurado para devolver respuestas obsoletas a las solicitudes de los clientes.
En otras palabras, los cachés a veces pueden optar por usar una respuesta obsoleta (aunque creo que luego tienen que agregar un encabezado de Warning ), pero el no-cache dice que no se les permite usar una respuesta obsoleta sin importar qué. Tal vez querría que el comportamiento DEBERÍAN -revertirse cuando se generan estadísticas de béisbol en una página, pero que desee que el comportamiento DEBE- revalide cuando haya generado la respuesta a una compra de comercio electrónico.
Aunque su comentario es correcto cuando dice que no-cache no debe impedir el almacenamiento, en realidad podría ser otra diferencia cuando se usa no-cache . Encontré una página, Desmitificación de las directivas de control de caché , que dice (no puedo responder por su corrección):
En la práctica, IE y Firefox han empezado a tratar la directiva de no almacenar en caché como si ordenara al navegador que ni siquiera almacenara en caché la página. Comenzamos a observar este comportamiento hace aproximadamente un año. Sospechamos que este cambio fue provocado por el uso generalizado (e incorrecto) de esta directiva para evitar el almacenamiento en caché.
...
Observe que en los últimos tiempos, "cache-control: no-cache" también comenzó a comportarse como la directiva "no-store".
Como nota aparte, me parece que Cache-Control: max-age=0, must-revalidate debería significar básicamente lo mismo que Cache-Control: no-cache . Entonces, tal vez esa es una forma de obtener el comportamiento de no-cache MUST , mientras se evita la migración aparente de no-cache para hacer lo mismo que no-store (es decir, sin caché).
Cuando es enviado por el agente de usuario
Creo que la respuesta de shahkalpesh se aplica al lado del agente de usuario. También puede consultar 13.2.6 Desambiguación de respuestas múltiples .
Si un agente de usuario envía una solicitud con Cache-Control: max-age=0 (también conocida como "revalidación de extremo a extremo"), cada caché en el camino volverá a validar su entrada de caché (por ejemplo, con la If-Not-Modified ) hasta el servidor de origen. Si la respuesta es 304 (no modificada), se puede usar la entidad en caché.
Por otro lado, el envío de una solicitud con Cache-Control: no-cache (también conocido como "recarga de extremo a extremo") no se revalida y el servidor NO DEBE usar una copia en caché cuando responde.
edad máxima = 0
Esto es equivalente a hacer clic en Actualizar , lo que significa, dame la última copia a menos que ya tenga la última copia.
no-caché
Se trata de mantener presionada la tecla Mayús mientras hace clic en Actualizar, lo que significa que, simplemente, vuelva a hacer todo sin importar qué.
max-age When an intermediate cache is forced, by means of a max-age=0 directive, to revalidate its own cache entry, and the client has supplied its own validator in the request, the supplied validator might differ from the validator currently stored with the cache entry. In this case, the cache MAY use either validator in making its own request without affecting semantic transparency. However, the choice of validator might affect performance. The best approach is for the intermediate cache to use its own validator when making its request. If the server replies with 304 (Not Modified), then the cache can return its now validated copy to the client with a 200 (OK) response. If the server replies with a new entity and cache validator, however, the intermediate cache can compare the returned validator with the one provided in the client''s request, using the strong comparison function. If the client''s validator is equal to the origin server''s, then the intermediate cache simply returns 304 (Not Modified). Otherwise, it returns the new entity with a 200 (OK) response. If a request includes the no-cache directive, it SHOULD NOT include min-fresh, max-stale, or max-age.
cortesía: http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.4
No aceptes esto como respuesta. Tendré que leerlo para comprender su verdadero uso :)