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

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"?

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

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 .

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.

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/

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.

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.

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.

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.

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.

Para empeorar aún más las cosas, en algunas situaciones, no se puede usar sin caché, pero sin almacenamiento sí:

http://faindu.wordpress.com/2008/04/18/ie7-ssl-xml-flex-error-2032-stream-error/

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í .