¿Por qué se deben usar tanto sin caché como sin almacenamiento en la respuesta HTTP?

120

Me han dicho que evite la filtración de información del usuario, solo "sin caché" como respuesta no es suficiente. "sin tienda" también es necesario.

Cache-Control: no-cache, no-store

Después de leer esta especificación http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html , todavía no estoy muy seguro de por qué.

Mi entendimiento actual es que es solo para el servidor de caché intermedio. Incluso si la respuesta es "sin caché", el servidor de caché intermedio aún puede guardar el contenido en un almacenamiento no volátil. El servidor de caché intermedio decidirá si utiliza el contenido guardado para la siguiente solicitud. Sin embargo, si la respuesta es "sin almacenamiento", se supone que el servidor de caché intermedio no debe almacenar el contenido. Entonces, es más seguro.

¿Hay alguna otra razón por la que necesitemos "sin caché" y "sin almacenamiento"?

Morgan Cheng
fuente
3
no-cacheno significa lo que crees que hace. En realidad, significa "por favor, vuelva a validar".
Erwan Legrand

Respuestas:

77

Debo aclarar que eso no-cacheno significa no guardar en caché . De hecho, significa "revalidar con el servidor" antes de usar cualquier respuesta almacenada en caché que pueda tener, en cada solicitud.

must-revalidate, por otro lado, solo necesita revalidar cuando el recurso se considera obsoleto.

Si el servidor dice que el recurso sigue siendo válido, la caché puede responder con su representación, aliviando así la necesidad de que el servidor vuelva a enviar el recurso completo.

no-storees efectivamente la directiva full not cache y está destinada a evitar el almacenamiento de la representación en cualquier forma de caché.

Digo lo que sea, pero tenga en cuenta esto en la especificación HTTP RFC 2616:

Los búferes de historial PUEDEN almacenar tales respuestas como parte de su operación normal

Pero esto se omite de la especificación HTTP RFC 7234 más reciente en un intento potencial de no-storefortalecerla, consulte:

http://tools.ietf.org/html/rfc7234#section-5.2.1.5

Luke Puplett
fuente
18
Todavía no respondo a la pregunta: ¿por qué deben usarse tanto sin caché como sin almacenamiento en la respuesta HTTP? ¿No es Cache-Control: no-storesuficiente?
Franklin Yu
¿Existen diferencias entre los navegadores? Porque este artículo de Microsoft docs.microsoft.com/en-us/iis/configuration/system.webServer/… ni siquiera menciona no-storey describe no-cachecomo si no tuviera caché en absoluto ... ¡Estoy confundido!
Roel
La respuesta de Alconja es la respuesta a la pregunta, en concreto. Cuando respondí, lo hice solo para aclarar una miconcepción muy común. ¡Vota la otra respuesta!
Luke Puplett
48

Bajo ciertas circunstancias, IE6 aún almacenará archivos en caché incluso cuando Cache-Control: no-cacheesté en los encabezados de respuesta.

El W3C estableceno-cache :

Si la directiva no-cache no especifica un nombre de campo, entonces un cache NO DEBE usar la respuesta para satisfacer una solicitud posterior sin una revalidación exitosa con el servidor de origen.

En mi aplicación, si visitaba una página con el no-cacheencabezado, luego se desconectaba y luego volvía a presionar en su navegador, IE6 aún tomaría la página del caché (sin una nueva solicitud / validación al servidor). Agregar el no-storeencabezado lo detuvo. Pero si toma la palabra del W3C, en realidad no hay forma de controlar este comportamiento:

Los búferes de historial PUEDEN almacenar tales respuestas como parte de su operación normal.

Las diferencias generales entre el historial del navegador y el almacenamiento en caché HTTP normal se describen en una subsección específica de la especificación .

Alconja
fuente
7
cuando regresa a su navegador, IE6 no toma la página del caché. Toma la página del búfer del historial.
Pacerier
1
En Chrome 34 (2014), también es necesario configurarlo no-store. De lo contrario, Chrome mostrará datos almacenados en caché / búfer al usar el botón Atrás.
caw
4
-1 porque la primera oración implica erróneamente que es incorrecto que un navegador almacene en caché una respuesta que tiene un no-cacheencabezado. La cita del W3C inmediatamente a continuación deja en claro que este no es el caso; más bien, el no-cacheencabezado solo significa que la respuesta debe ser revalidada antes de ser reutilizada para atender solicitudes posteriores.
Mark Amery
1
La redacción de la especificación se ha mejorado de RFC1616 a la versión actual de la especificación ( tools.ietf.org/html/rfc7230 familia de RFC). una familia porque son 6 RFC. Están obsoletos 2616.
Arcin B
16

De la especificación HTTP 1.1 :

sin tienda :

El propósito de la no tiendaLa directiva es prevenir la liberación o retención involuntaria de información confidencial (por ejemplo, en cintas de respaldo). La directiva de no almacenar se aplica a todo el mensaje y PUEDE enviarse en una respuesta o en una solicitud. Si se envía en una solicitud, un caché NO DEBE almacenar ninguna parte de esta solicitud ni de ninguna respuesta a ella. Si se envía en una respuesta, un caché NO DEBE almacenar ninguna parte de esta respuesta o de la solicitud que la provocó. Esta directiva se aplica a los cachés compartidos y no compartidos. "NO DEBE almacenar" en este contexto significa que la caché NO DEBE almacenar intencionalmente la información en un almacenamiento no volátil y DEBE hacer el mejor esfuerzo posible para eliminar la información del almacenamiento volátil lo antes posible después de reenviarla. Incluso cuando esta directiva se asocia con una respuesta, los usuarios pueden almacenar explícitamente dicha respuesta fuera del sistema de almacenamiento en caché (por ejemplo, con un cuadro de diálogo "Guardar como"). Los búferes de historial PUEDEN almacenar tales respuestas como parte de su operación normal. El propósito de esta directiva es cumplir con los requisitos establecidos de ciertos usuarios y autores de servicios que están preocupados por la liberación accidental de información a través de accesos no anticipados a las estructuras de datos de la caché. Si bien el uso de esta directiva puede mejorar la privacidad en algunos casos, advertimos que NO es de ninguna manera un mecanismo confiable o suficiente para garantizar la privacidad. En particular, los cachés maliciosos o comprometidos pueden no reconocer u obedecer esta directiva, y las redes de comunicaciones pueden ser vulnerables a las escuchas. Los búferes de historial PUEDEN almacenar tales respuestas como parte de su operación normal. El propósito de esta directiva es cumplir con los requisitos establecidos de ciertos usuarios y autores de servicios que están preocupados por la liberación accidental de información a través de accesos no anticipados a las estructuras de datos de la caché. Si bien el uso de esta directiva puede mejorar la privacidad en algunos casos, advertimos que NO es de ninguna manera un mecanismo confiable o suficiente para garantizar la privacidad. En particular, los cachés maliciosos o comprometidos pueden no reconocer u obedecer esta directiva, y las redes de comunicaciones pueden ser vulnerables a las escuchas. Los búferes de historial PUEDEN almacenar tales respuestas como parte de su operación normal. El propósito de esta directiva es cumplir con los requisitos establecidos de ciertos usuarios y autores de servicios que están preocupados por la liberación accidental de información a través de accesos no anticipados a las estructuras de datos de la caché. Si bien el uso de esta directiva puede mejorar la privacidad en algunos casos, advertimos que NO es de ninguna manera un mecanismo confiable o suficiente para garantizar la privacidad. En particular, los cachés maliciosos o comprometidos pueden no reconocer u obedecer esta directiva, y las redes de comunicaciones pueden ser vulnerables a las escuchas. Si bien el uso de esta directiva puede mejorar la privacidad en algunos casos, advertimos que NO es de ninguna manera un mecanismo confiable o suficiente para garantizar la privacidad. En particular, los cachés maliciosos o comprometidos pueden no reconocer u obedecer esta directiva, y las redes de comunicaciones pueden ser vulnerables a las escuchas. Si bien el uso de esta directiva puede mejorar la privacidad en algunos casos, advertimos que NO es de ninguna manera un mecanismo confiable o suficiente para garantizar la privacidad. En particular, los cachés maliciosos o comprometidos pueden no reconocer u obedecer esta directiva, y las redes de comunicaciones pueden ser vulnerables a las escuchas.

barra invertida17
fuente
1
Si ya no está almacenando en caché la solicitud, ¿no evitaría eso el almacenamiento de la respuesta en medios no volátiles?
Lèse majesté
4
@ Lèsemajesté La mayoría de las veces no. no-cachey max-age=0decir que el artículo debe considerarse obsoleto. Esto significa que debe ser revalidado antes de ser notificado. Esto significa que una caché podría almacenar el archivo y luego realizar una solicitud condicional a la que el servidor podría responder 304 NOT MODIFIED. Obviamente, esto es una gran ventaja, ya que no es necesario generar y enviar el cuerpo de la respuesta. Entonces, para aprovechar esta cantidad (¿la mayoría?) De los cachés, se almacenarán las no-cacherespuestas.
Kevin Cox
14

Si desea evitar todo el almacenamiento en caché (por ejemplo, forzar una recarga cuando se usa el botón Atrás), necesita:

  • sin caché para IE

  • sin tienda para Firefox

Aquí está mi información sobre esto:

http://blog.httpwatch.com/2008/10/15/two-important-differences-between-firefox-and-ie-caching/

HttpWatchSupport
fuente
6
¿Por qué la falta de tienda no sería suficiente para Internet Explorer? Su publicación de blog no explica.
Simon Lieschke
1
¿De qué versión de IE estás hablando?
Pacerier
1
@Pacerier, probablemente cualquier versión de IE que fuera la más nueva en el momento en que escribió el comentario. Según Wikipedia, este era IE7. Para FF parece 3. No mucha gente todavía lo usa.
Trysis
11

no-storeno debería ser necesario en situaciones normales y puede dañar tanto la velocidad como la usabilidad. Está diseñado para su uso donde la respuesta HTTP contiene información tan sensible que nunca debería escribirse en una caché de disco, independientemente de los efectos negativos que crea para el usuario.

Cómo funciona:

  • Normalmente, incluso si un agente de usuario, como un navegador, determina que una respuesta no debe almacenarse en caché, aún puede almacenarla en el caché del disco por razones internas del agente de usuario. Esta versión se puede utilizar para funciones como "ver fuente", "volver", "información de la página", etc., donde el usuario no necesariamente ha solicitado la página nuevamente, pero el navegador no la considera una nueva vista de página. y tendría sentido ofrecer la misma versión que el usuario está viendo actualmente.

  • El uso no-storeevitará que se almacene esa respuesta, pero esto puede afectar la capacidad del navegador para dar "ver fuente", "volver", "información de página", etc. sin realizar una nueva solicitud separada para el servidor, lo cual no es deseable. En otras palabras, el usuario puede intentar ver la fuente y, si el navegador no la guardó en la memoria, se le dirá que esto no es posible o provocará una nueva solicitud al servidor. Por lo tanto, no-storesolo debe usarse cuando la experiencia del usuario impedida de estas funciones que no funcionan correctamente o rápidamente se ve superada por la importancia de garantizar que el contenido no se almacene en la caché.

Mi entendimiento actual es que es solo para el servidor de caché intermedio. Incluso si la respuesta es "sin caché", el servidor de caché intermedio aún puede guardar el contenido en un almacenamiento no volátil.

Esto es incorrecto. Los servidores de caché intermedios compatibles con HTTP 1.1 obedecerán las instrucciones no-cachey must-revalidate, asegurando que el contenido no se almacene en caché. El uso de estas instrucciones asegurará que la respuesta no sea almacenada en caché por ningún caché intermedio y que todas las solicitudes posteriores se envíen de vuelta al servidor de origen.

Si el servidor de caché intermedio no es compatible con HTTP 1.1, deberá utilizar Pragma: no-cachey esperar lo mejor. Tenga en cuenta que si no es compatible con HTTP 1.1, de no-storetodos modos es irrelevante.

thomasrutter
fuente
3
¿Estoy malinterpretando algo porque mnot.net/cache_docs/#CACHE-CONTROL te contradice? Dice que no-cachemantiene una frescura rígida sin sacrificar todos los beneficios del almacenamiento en caché, lo que significa que el caché se almacena y se usa nuevamente si el servidor responde con 304 Not Modified.
Pacerier
-1: sin caché no significa que el contenido no se pueda almacenar en caché. En 14.9.1 What Is Cachable, la especificación dice: "Si la directiva no-cache no especifica un nombre de campo, entonces un caché NO DEBE usar la respuesta para satisfacer una solicitud posterior sin una revalidación exitosa con el servidor de origen". ( w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9. ) Como explica Chris Shiflett, "no impide que un sistema de almacenamiento en caché mantenga una copia en caché. Simplemente requiere que el sistema de almacenamiento en caché vuelva a validar su caché antes a devolverlo al cliente ". (HTTP Developer's Handbook, p 91)
james.garriss
No creo que lo que escribí en esta respuesta contraiga ninguno de esos dos comentarios; simplemente no hablé sobre cómo los navegadores revalidan (por ejemplo, usando If-Modified-Since / If-None-Match) porque no lo vi como pertinente. Ni siquiera intenté cubrir para qué sirve la ausencia de caché, así que tengo dificultades para entender cómo se relaciona el comentario de @ james.garriss con mi respuesta.
thomasrutter
7

Si un sistema de almacenamiento en caché implementa correctamente la ausencia de almacenamiento, entonces no necesitaría la ausencia de caché. Pero no todos lo hacen. Además, algunos navegadores implementan sin caché como si no hubiera tienda. Por lo tanto, aunque no es estrictamente necesario, probablemente sea más seguro incluir ambos.

james.garriss
fuente
Pero no todos lo hacen. ”Necesitamos un ejemplo concreto para convencer a mi colega.
Franklin Yu
Ese comentario se hizo hace 6 años. Deberá examinar el comportamiento actual de los servidores de almacenamiento en caché para ver qué están haciendo.
james.garriss
6

Tenga en cuenta que Internet Explorer desde la versión 5 hasta la 8 arrojará un error al intentar descargar un archivo servido a través de https y el servidor que envía Cache-Control: no-cacheo Pragma: no-cacheencabezados.

Ver http://support.microsoft.com/kb/812935/en-us

El uso de Cache-Control: no-storey Pragma: privateparece ser lo más parecido que todavía funciona.

Bassim
fuente
2
Como se sugiere en una respuesta SO relacionada , puede configurar Cache-Control: no-store, no-cache, must-revalidateen ese orden exacto para que funcione. Sin embargo, eso no funcionó en nuestro escenario, pero lo que @bassim sugirió anteriormente sí. ¡Gracias!
Eirik H
6

Para Chrome, no se usa caché para recargar la página en una nueva visita, pero aún la almacena en caché si regresa al historial (botón de retroceso). Para volver a cargar la página para el historial también, use no-store. IE necesita ser revalidado para funcionar en todas las ocasiones.

Así que para asegurarme de evitar todos los errores y malas interpretaciones que siempre uso

Cache-Control: no-store, no-cache, must-revalidate

si quiero asegurarme de que se vuelva a cargar.

woens
fuente
2

Originalmente usamos sin caché hace muchos años y tuvimos algunos problemas con el contenido obsoleto con ciertos navegadores ... Desafortunadamente, no recuerdo los detalles.

Desde entonces, nos habíamos decidido SÓLO por el uso de no-tienda. Desde entonces, nunca miré hacia atrás ni tuve un solo problema con contenido obsoleto por parte de ningún navegador o intermediarios.

Este espacio está ciertamente dominado por la realidad de las implementaciones frente a lo que se ha escrito en varios RFC. Muchos representantes en particular tienden a pensar que hacen un mejor trabajo al "mejorar el desempeño" reemplazando la política que se supone que deben seguir por la suya propia.

Einstein
fuente
Creo que es Firefox quien solía preferir el no-store.
bvdb
-1

OWASP analiza esto:

¿Cuál es la diferencia entre las directivas de control de caché: sin caché y sin almacenamiento?

La directiva no-cache en una respuesta indica que la respuesta no debe usarse para atender una solicitud posterior, es decir, la caché no debe mostrar una respuesta que tenga esta directiva establecida en el encabezado, pero debe permitir que el servidor atienda la solicitud. La directiva no-cache puede incluir algunos nombres de campo; en cuyo caso la respuesta se puede mostrar desde la caché, excepto para los nombres de campo especificados que deben ser servidos desde el servidor. La directiva de no almacenar se aplica a todo el mensaje e indica que la caché no debe almacenar ninguna parte de la respuesta o cualquier solicitud que la solicite.

¿Estoy totalmente seguro con estas directivas?

No. Pero en general, use Cache-Control: no-cache, no-store y Pragma: no-cache, además de Expires: 0 (o una fecha GMT suficientemente retroactiva como la época UNIX). Los tipos de contenido que no son HTML como pdf, documentos de Word, hojas de cálculo de Excel, etc., a menudo se almacenan en caché incluso cuando se establecen las directivas de control de caché anteriores (aunque esto varía según la versión y el uso adicional de must-revalidate, pre-check = 0, post-check = 0, max-age = 0 y s-maxage = 0 en la práctica a veces pueden resultar en al menos la eliminación de archivos al cerrar el navegador en algunos casos debido a peculiaridades del navegador e implementaciones HTTP). Además, la función 'Autocompletar' permite que un navegador almacene en caché lo que el usuario escriba en un campo de entrada de un formulario. Para comprobar esto, la etiqueta de formulario o las etiquetas de entrada individuales deben incluir el atributo 'Autocomplete = "Off"'. Sin embargo,

Fuente aquí .

Jan Żankowski
fuente
Esto es incorrecto. no-cachedice que no puede usarlo sin validarlo con el servidor. Si su copia en caché aún es buena, el servidor responderá con un 304 y luego usará su copia en caché. Le ahorra una descarga de red potencialmente grande. no-storepor otro lado, dice que no está permitido almacenar en caché los datos en absoluto.
Gárgola