caching - recargar - forzar cache html

¿Cómo evito que Opera almacene en caché una página? (4)

Estoy intentando que Opera vuelva a solicitar una página cada vez, en lugar de solo publicarla desde el caché. Estoy enviando los encabezados de respuesta ''Cache-control: no-cache'' y ''Pragma: no-cache'' pero parece que Opera está ignorando estos encabezados. Funciona bien en otros navegadores: Chrome, IE, Firefox.

¿Cómo evito que Opera almacene en caché las páginas? Lo que quiero poder hacer es hacer que Opera vuelva a solicitar una página cuando el usuario haga clic en el botón Atrás en el navegador.

Como usuario, detestaba absolutamente las páginas que ralentizaban mi navegación histórica forzando las recargas cuando uso el botón Atrás. (Si el navegador que utiliza a diario presta atención a las diversas directivas de caché y les permite afectar la navegación de la historia de la manera que desee como desarrollador, probablemente note que algunos sitios se ralentizan ...)

Si tiene un caso de uso muy fuerte para hacer esto, diría que su arquitectura podría ser "incorrecta" en algún sentido, por ejemplo, si está cambiando entre diferentes "vistas" de actualización constante de datos y, por lo tanto, desea aplicarlos. cargar cuando los usuarios regresen, tal vez sea mejor usar las técnicas Ajaxy para cargar los datos constantemente cambiantes en la página actual.

La implementación de Opera es deliberada: el "almacenamiento en caché" se considera conceptualmente diferente de la "navegación histórica"; el primero se trata más de almacenar cosas en el disco y entre sesiones; el segundo está volviendo a una página temporalmente oculta que acaba de visitar, en el estado lo dejaste

Sin embargo, si realmente lo necesita, existe una laguna en esta política que permite el comportamiento que desea. Enviar " Cache-control: must-revalidate " obligará a Opera a volver a cargar cada página en la navegación, pero solo si está enviando la página a través de https. (Esta es una función solicitada por y destinada a bancos paranoicos, se ralentiza demasiados sitios normales si se aplica en http).

Encontrado esto mientras buscabas solución. No hay alegría, por lo que escribió algunos javascript para resolver el problema que puede ser de utilidad para otros.

En <HEAD> encima de cualquier otro javascript:

<script> if( typeof(opera) != ''undefined'' ) { // only do for Opera if (window.name == ''previously_loaded'') { // will be "" before page is loaded alert(''Reloading Page from Server''); // for testing window.name = ''''; // prevent multiple reload window.location.reload(true); } } </script>

Ahora cambie el nombre de la ventana para que Opera lo detecte en la carga posterior de la caché:

window.name = ''previously_loaded'';

Inserta esta línea en uno de tus bloques js que no se ejecutará durante la "carga de la ventana", lo que ocasionará una recarga infinita. Para mí no hubo necesidad de actualizar la página a menos que alguien haya salido de un enlace, así que simplemente lo agregué a mi función onclick / onunload.

Demostraciones de antes y después aquí con algunas notas más. Tengo la intención de agregarlo a mi blog. Solo tengo algunas versiones anteriores de Opera, por lo que agradecería algunos intentos de la demo antes de que me salga huevo en la cara.

Editar: Acabo de darme cuenta de que si un sitio visitado más tarde cambia el nombre de la ventana (es persistente), la recarga de la pestaña trasera no ocurrirá. Simplemente modifique la declaración anterior a:

if (window.name != "") {

La demostración funcionó bien cuando se abre en varias pestañas; pero recuerdo vagamente que los nombres de las ventanas deben ser únicos; así que he alterado la demostración para generar un nombre único.

window.name = new Date().getTime();

Parece que tu problema está relacionado con esta respuesta . Después de probar tu encabezado y los encabezados sugeridos, solo pude reproducir tu comportamiento esperado en Internet Explorer.

SIMPLE SERVIDOR CONTROL DE CACHÉ SIN CABEZAS O GUIONES FRONTEND

Zero Dependency, Universal Language Edition

Puede obligar a volver a almacenar en caché globalmente sin usar un encabezado al agregar una suma de comprobación md5 o sha1 a su nombre de archivo.

De esta forma, guardará en caché si se trata de una coincidencia exacta y, de lo contrario, lo tratará como un nuevo recurso.

Funciona en todos los navegadores
Valida como HTML estricto (originalmente no, pero esto ha sido actualizado. No probado para XHTML, pero probablemente no sea válido para eso)
No requiere encabezados adicionales
Mantiene las preocupaciones frontend y las preocupaciones de backend bien desacopladas.
No requiere controles de cordura del lado del cliente o validación de la fuente.
Cualquier cosa que pueda imprimir html puede hacer esto de manera consistente, incluido el contenido estático
Si no es estático, es fácil extender el control del tiempo de ejecución a los usuarios finales (con autenticación, si se desea) que permite que los indicadores de página simples determinen la fuente minimizada, embellecida o depurada que se devuelve.
Completamente encapsula el control de la caché del cliente en el mecanismo de publicación de contenido, lo que hace que las cosas sean súper fáciles de mantener.
Como beneficio secundario, introduce el almacenamiento en caché versionado del lado del cliente de forma automática aplazando las sumas de comprobación que el navegador ha almacenado en caché, lo que puede ser útil si tiene versiones alternativas y necesita probar un paquete de lanzamiento para determinar sus versiones de dependencia mínimamente estable o algo así.
No tiene que jugar con su navegador para que el almacenamiento en caché no vuelva a interferir con su proceso de desarrollo.
Este enfoque también se puede usar para imágenes con versión, video, audio, pdfs, etc. Prácticamente cualquier recurso que se sirve como datos estáticos funcionará de manera similar, se almacenará en caché en la primera solicitud del contenido y persistirá automáticamente sin consideración adicional si el archivo no cambia.

Este es un marcado válido de RFC. Observe que el script y las etiquetas de enlace tienen una cadena get:

?checksum=ba411cafee2f0f702572369da0b765e2

<!doctype html> <html lang="en"> <head> <meta charset="utf-8"> <title>Client Cache Control Example</title> <meta name="description" content="You''re only going to cache this when the content changes, and always when the content changes."> <meta name="author" content="https://.com/users/1288121/mopsyd">  <link rel="stylesheet" href="css/styles.css?checksum=ba411cafee2f0f702572369da0b765e2">  <script src="js/scripts.js?checksum=ba411cafee2f0f702572369da0b765e2"></script> </head> <body> </body> </html>

La cadena GET ?checksum=ba411cafee2f0f702572369da0b765e2 hace referencia a un hash MD5 o SHA1 del tamaño de archivo del recurso. Se puede obtener a través de una línea de comando, constructo de lenguaje o hashándolo del valor del encabezado Content-Length: . A continuación, construye su atributo href o src agregándolo como una cadena GET al nombre del archivo.

Este navegador interpretará estos como distintos y caché por separado.

El servidor ignorará el parámetro GET si es un recurso estático, pero si se sirve dinámicamente, entonces el parámetro GET estará disponible para el lenguaje de interpretación.

Esto significa que cada vez que ese hash cambia en los enlaces, el navegador guardará en caché esa versión específica de manera independiente una vez , y luego la conservará para siempre, o Expires: pasa, lo que ocurra primero.

Dado que la suma de comprobación es un reflejo directo del tamaño del archivo, puede configurar Expires: para siempre y no hace mucha diferencia. Todavía verá sus cambios inmediatamente tan pronto como ese archivo cambie, incluso un solo byte.

Genera tu fuente css o js con las utilidades que normalmente haces.
Ejecute una suma de comprobación md5 o sha1 en el tamaño del archivo en tiempo de ejecución si está sirviendo dinámicamente, y en tiempo de compilación si está generando contenido estático (como documentos ApiGen, por ejemplo) .
Sirva el archivo normal con el hash como una cadena GET styles.css al nombre del archivo (por ejemplo: styles.css convierte en styles.css?checksum=ba411cafee2f0f702572369da0b765e2 )
Cualquier cambio en el archivo fuerza un recache, lo que significa que ve el valor real reflejado inmediatamente.
Opcional, pero rad: un beneficio adicional de este enfoque es que puede configurar fácilmente un indicador dev GET, que hará que TODOS los frontend se resuelvan como fuentes dev optimizadas con cualquiera de sus propias funciones de depuración habilitadas, o lo usen para interpretar el control de versiones. banderas. Puede hacer una verificación redundante para asegurarse de que ese indicador solo se transmite desde una dirección IP de desarrollo conocida, autenticación de proxy, etc., por parte del servidor y de lo contrario no se respeta si lo necesita de forma segura. Normalmente divido la fuente de mi frontend siempre que sea posible, similar a esto:
- Esto es lo que está haciendo en vivo en este momento (producción minimizada, en caché, por defecto ?checksum=ba411cafee2f0f702572369da0b765e2 ).
- Esto es lo que debería estar haciendo en vivo en este momento, lo suficientemente embelesado para que lo lea (producción ?debug_pretty_source=true , nunca en la caché ?debug_pretty_source=true ).
- Esto es lo que uso para descubrir qué no está haciendo lo que debería en vivo si existe en los dos anteriores (pretificado con depuración habilitada, nunca en caché , ACL / ?debug_dev_enable=true autorizado ?debug_dev_enable=true o similar ).

Puede aplicar el mismo principio a las versiones del paquete utilizando números de versión en lugar de sumas de verificación, siempre que sus versiones no cambien. Las sumas de comprobación son menos legibles pero más fáciles de automatizar y mantenerse sincronizadas con los cambios exactos, pero los sufijos de versión también son útiles para probar la estabilidad del paquete, siempre que el número de versión refleje un recurso inmutable.