Recarga de página completa en Publicar/Redirigir/Obtener ignorar el control de caché

Tengo una página que carga muchas imágenes, css y javascript. Agregué un futuro encabezado Expires y establecí Cache-Control en público en estas dependencias externas, por lo que deben almacenarse en caché. Pero cada vez que hago un Post/Redirect/Get Chrome, intento cargar estos de nuevo. Este comportamiento es muy similar a volver a cargar la página. He agregado ETags y manejo el encabezado If-None-Match que ayuda un poco, pero aún genera demasiadas solicitudes inútiles.Recarga de página completa en Publicar/Redirigir/Obtener ignorar el control de caché

¿Cómo le digo a Chrome y Safari que obtengan los archivos del caché?

chrome NOK 
safari NOK 
firefox OK 
ie  OK

Véase también Full page reload on Post/Redirect/Get ignoring cache control en el foro de soporte de Google.

Aclaración:

no quiero que el navegador para solicitar image1.png dos veces. Debería estar en caché.

200 GET page1.html 
200 GET image1.png (Cache-Control: public, Expires and ETag) 
302 POST action.asp (form submitted from page1.html, redirects) 
200 GET page2.html 
304 GET image1.png (If-None-Match)

Ejemplo:

He creado un ejemplo simple para ilustrar el problema.

http://crydust.be/lab/prg/

encabezados:

las cabeceras que envío con la imagen son:

HTTP/1.1 200 OK 
Date: Fri, 18 Jun 2010 11:30:22 GMT 
Server: Apache 
Cache-Control: public, max-age=86400 
Expires: Sat, 19 Jun 2010 11:30:24 GMT 
Etag: "123" 
Content-Length: 866 
Content-Type: image/png

que debería hacer más en caché durante 24 horas. No hay variación: * ni nada de eso.

Actualización: Este comportamiento ahora también está presente en Safari Mobile en iOS 4. Una regresión horible en la velocidad de carga de página.

Actualización: Hay un informe de error acerca de este problema en el buglilla de webkit. Bug 38690 - Submitting a POST that leads to a server redirect causes all cached items to redownload

Actualización: El problema persiste en iOS 4.0.1

Actualización: El problema persiste en IOS 4,1

Actualización: El problema persiste en IOS 4.2

Actualización: el problema persiste en iOS 4.2.1 y en Chrome desde la versión 6 hasta 9.

Actualización: Hay un informe de error sobre este tema en el proyecto Chromium.(Puede destacar que de mostrar preocupación) Issue 68621: Post/Redirect/Get ignoring cache instructions

Actualización: el problema persiste en Chrome desde la versión 6 hasta 10. Ahora es un error 9 meses de edad.

Actualización: El problema está solucionado el 2011-03-21 19:33:07 PST. Esto se refleja en el comportamiento de cromo 12 (canario).

Fuente

2010-06-09 Kristof Neirynck

Es un problema de webkit, en lugar de un problema específico con Chrome. –

@Dan, lo sé, pero espero que los chicos de Google corrija esto en uno de sus muchos lanzamientos. Hay un parche disponible, pero aún no está incluido en Chrome. –

Pensé que el parche causó una regresión, ¿por qué no fue aceptado? –

Cuando actualiza F5/Chrome, Safari o IE8, todos los recursos GET se solicitan nuevamente, incluso si se almacenaron en caché.

Si mira la solicitud/respuesta con las herramientas de desarrollo o Fiddler verá que el servidor responde con un estado HTTP 304 y sin contenido. Esto le dice al navegador que no necesitan volver a descargarlo y que pueden seguir usando el caché.

En las herramientas de desarrollo de Chrome, los archivos de la pestaña de recursos actualizados de esa manera tendrán un tiempo de latencia, pero un tiempo de descarga de 0ms.

Si vuelve a cargar la página dejándola y volviendo, verá que estos archivos en caché no se recuperan nuevamente y el servidor no está marcado.

Este comportamiento de F5/refresh for GET recurso estático es correcto; FX e IE6 lo están haciendo mal. También ayuda con el confuso comando CTRL + F5 que la mayoría de los usuarios desconocen.

No se puede almacenar en caché POST o páginas que devuelven una redirección HTTP temporal:

cambios de puestos de datos y siempre debe impulsar antes de ser enviado de nuevo, y sus resultados nunca se almacena en caché.

Los redireccionamientos se manejan a un nivel bajo en el material HTTP: almacenamiento en caché inferior. Realmente le dice al navegador que obtenga el recurso de otra parte y, si bien puede almacenar en caché, no ha cacheado el redireccionamiento y debe volver a verificarlo.

Debería poder guardar en caché un redireccionamiento permanente 301, pero un 302 o 303 redireccionamientos temporales no deberían almacenarse en caché according to the HTTP spec.

Fuente

2010-06-09 12:08:34 Keith

El usuario no presionó F5. El navegador se comporta como si se hubiera presionado F5 después de una publicación/redireccionamiento/obtención. No quiero guardar en caché la redirección, solo las imágenes estáticas. –

@Kristof Neirynck - Ahh, ¿entonces la publicación devuelve un redireccionamiento y la página muestra todo el contenido estático con 304s, pero si enlazas directamente a él, obtienes el contenido estático guardado en la memoria caché localmente? Eso parece un error. Compruebe los encabezados de respuesta en el contenido estático, algunos de ellos (como Variar: *) causan problemas con el almacenamiento en caché del cliente en algunos navegadores. Puede encontrar una solución alternativa allí. – Keith

F5 vuelve a cargar todos los recursos de la página en algunos navegadores, por lo que ignoran los encabezados de la caché y solicitan nuevamente todos los recursos.

Si desea "poner en caché" páginas POST debe convertir esas páginas en recursos estáticos, es decir, generar un archivo .html de .php por ejemplo y luego servir el .html como un recurso estático.

Esto sólo es válido si el contenido de la página no cambia

Fuente

2010-10-22 21:32:39 Ron

No presiono F5. Estoy haciendo una redirección de publicaciones. –

La solución: cache-control: no-store

(También puede que quiera usar el código de estado 307 en lugar de 302, que preservará el método.)

La solución se encontró después de muchos días de frustración en un comentario en this open WebKit bug:

CachedRawResource ahora mantiene la cadena de redirección y tiene una lógica trivial para verificar la corrección, pero no está completa (solo comprueba cacheControlContainsNoStore()).Y, por supuesto, otros tipos de recursos no tienen nada.

Fuente

2015-07-21 22:08:57 bbrown

Recarga de página completa en Publicar/Redirigir/Obtener ignorar el control de caché

Respuesta

Cuestiones relacionadas