Comportamiento del almacenamiento en caché en los principales navegadores

Question

Comportamiento del almacenamiento en caché en los principales navegadores

#1 de tylerl (7 votos)

2

Antes de que formule la pregunta, esta es una pregunta difícil de enmarcar, así que doy la bienvenida a las ediciones para mejorar la claridad.

¿Cómo deciden los principales navegadores cómo almacenar en caché las respuestas, especialmente si dichas respuestas se recuperan a través de AJAX, y no tienen un control de caché explícito u otros encabezados relacionados con el caché?

Las aplicaciones que estoy probando son bastante similares, ya que usan un MVC de JavaScript para representar la página, responder a las acciones de los usuarios y realizar solicitudes XHR. Todas las respuestas están en JSON, excepto la página principal. Ambas aplicaciones están sobre HTTPS. La aplicación 1 tiene el conjunto de encabezados HSTS, La aplicación 2 no la tiene.

Ninguna de estas aplicaciones establece los encabezados de Cache-Control explícitamente. Sin embargo, Aplicación 1 no no almacena información, mientras que Aplicación 2 hace información de caché. La única distinción importante entre los dos es que las URL de Aplicación 1 están en el formato <URL>/#/some/action/performed , mientras que las URL de Aplicación 2 son más simples, es decir, <URL>/someaction . Mi argumento principal fue que el navegador no almacena en caché las respuestas que se devuelven a ninguna URL que contenga # en ellas, porque en lo que respecta al navegador, es la misma página. Sin embargo, no estoy convencido con este argumento, simplemente porque al final del día, son todas las solicitudes de XHR que se están realizando, así que ¿por qué el comportamiento diferente entre aplicaciones?

web-application hsts caching

pregunta Karthik Rangarajan 10.01.2014 - 03:44

fuente

1 respuesta

Lea otras preguntas en las etiquetas web-application hsts caching

Certificado digital “Firma y huella digital” Logro de PFS con criptografía de clave pública

score 7 · Accepted Answer

En primer lugar; oficialmente, todo después de # no forma parte de la URL con respecto a las solicitudes y respuestas. No se envía al servidor y se ignora al recuperar y configurar cachés. Aparece en la barra de URL, pero no forma parte de la ubicación especificada del recurso.

Con respecto a la pregunta de cómo los navegadores determinan si almacenar o no las páginas; La respuesta es, depende". IE es un tanto notorio para el almacenamiento en caché de XHR, incluso cuando el encabezado de control de caché dice explícitamente no , por lo que jQuery's existe un mecanismo de evitación de caché ajax . La solución que utiliza es agregar una variable GET con un simple contador monótonamente creciente. Esto hace que cada solicitud sea una nueva URL, porque /foo.php?x=123 es una URL diferente de /foo.php?x=456 y, por lo tanto, una falta de caché garantizada.

Tenga en cuenta que, en contraste, /foo.php#x=123 seguido de /foo.php#x=456 es un HIT de caché potencial, porque el recurso en cuestión es solo /foo.php y #x=123 se elimina antes de la recuperación.

En cuanto a lo que es el estándar, creo que si no se especifica el caché o la edad, entonces el comportamiento del caché no está definido: el autor del navegador es libre de decidir por sí mismo qué es lo correcto. Los diferentes navegadores probablemente se comportarán de manera diferente. Y los navegadores son (bueno, un navegador en particular) famosos por basar decisiones de comportamiento importantes en factores aparentemente aleatorios. Entonces, en ese caso, tomar una decisión de caché basada en el fragmento de URL es posible a pesar de ser absurdo.

Entonces, si estás usando uno de esos navegadores que hace que tus compañeros con una mentalidad más técnica se ríen de ti, entonces espera experimentar un comportamiento injustificadamente extraño. No intentes explicarlo, solo te enojarás.

Por otra parte, si usted es el desarrollador de la aplicación, (A) establezca explícitamente una política de caché en sus encabezados de respuesta y (B) si está tratando con IE, entonces use los parámetros GET que destruyen la caché.