Control de caché del navegador, contenido dinámico

Question

Problema: Parece que no puedo hacer que FireFox almacene en caché las imágenes enviadas desde un servidor dinámico

Configuración: Servidor Apache estático con proxy inverso a un servidor dinámico (mod_perl2) en el backend.

Aquí está la URL de solicitud para el servidor.Se envía al servidor dinámico, donde se utiliza la cookie para validar el acceso a la imagen:

Encabezados de solicitud

Host:  <OBSCURED>
User-Agent:  Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.15) Gecko/2009102815 Ubuntu/9.04 (jaunty) Firefox/3.0.15
Accept:  image/png,image/*;q=0.8,*/*;q=0.5
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset:  ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive:  300
Connection:  keep-alive
Referer: <OBSCURED>
Cookie:  pz_cred=4KCNr0RM15%2FJCOt%2BEa6%2BL62z%2Fxvbp2xNQHY5pJw5d6Q
Pragma:  no-cache
Cache-Control: no-cache

El servidor dinámico transmite la imagen de regreso al servidor y proporciona la siguiente respuesta:

Encabezados de respuesta

Date:  Tue, 24 Nov 2009 04:28:07 GMT
Server:  Apache/2.2.11 (Ubuntu) mod_apreq2-20051231/2.6.0 mod_perl/2.0.4 Perl/v5.10.0
Cache-Control: public, max-age=31536000
Content-Length:  25496
Content-Type:  image/jpeg
Via: 1.1 127.0.1.1:8081
Keep-Alive:  timeout=15, max=75
Connection:  Keep-Alive

Hasta ahora todo bien (pienso yo).Sin embargo, al recargar la pagina, la imagen no aparece almacenada en caché y se vuelve a enviar una solicitud:

Encabezados de solicitud

Host: <OBSCURED>
User-Agent:  Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.15) Gecko/2009102815 Ubuntu/9.04 (jaunty) Firefox/3.0.15
Accept:  image/png,image/*;q=0.8,*/*;q=0.5
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset:  ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive:  300
Connection:  keep-alive
Referer: <OBSCURED>
Cookie:  pz_cred=4KCNr0RM15%2FJCOt%2BEa6%2BL62z%2Fxvbp2xNQHY5pJw5d6Q
Cache-Control: max-age=0

No parece que la solicitud deba realizarse ya que el navegador debería haber almacenado en caché la imagen.Tal como están las cosas, se recibe una respuesta 200, igual que la primera, y la imagen parece volver a recuperarse (aunque el navegador parece estar usando las imágenes almacenadas en caché).

El problema parece ser insinuado por Cache-Control:max-age=0 en el encabezado de solicitud de recarga, arriba.

¿Alguien sabe por qué ocurre esto?Quizás sea el A través de encabezado en la respuesta que está causando el problema?

Answer 1

Mi respuesta anterior fue sólo parcialmente correcta.

El problema es la forma en que Firefox 3 mangos recarga eventos. Al parecer, casi siempre solicita contenido nuevo desde el servidor de origen. Así, el encabezado de la solicitud Cache-Control: max-age=0.

Firefox lo hace Usar caché imágenes para representar una página de recarga, pero entonces todavía hace que todas las peticiones de modificación de ellos "en el fondo". A continuación, en lugar de ellos, ya que entran en juego.

Por lo tanto, la página muestra el contenido rápido, informes YSlow almacenan en caché. Pero el servidor todavía se está clavado.

La resolución es interrogar las cabeceras de entrada en el script del servidor dinámico y determinar si 'Modified-Since Si-' cabecera se proporciona una. Si este es el caso, y se determina el contenido no ha cambiado, un HTTP_NOT_MODIFIED se devuelve (304) de respuesta.

Esto no es óptimo - prefiero Firefox no hago las solicitudes en todos - pero reduce el tiempo de carga de la página por la mitad, y reduce considerablemente el ancho de banda. Dada la forma en que Firefox funciona en recarga, esto parece la mejor solución.

Otros comentarios : punto de Jim Ferran acerca navegar fuera de la página y volver tiene mérito - el caché se utiliza siempre, y no hay peticiones son de salida (1 a Jim). También, el contenido que se añade dinámicamente (por ejemplo AJAX llamadas después de la carga inicial) parecen utilizar la memoria caché también.

Espero que esto ayude a alguien fuera de mí)

Answer 2

La solicitud original tiene

Cache-Control: no-cache

que indica a todos los cachés HTTP intermedios (incluyendo Firefox) que usted no desea utilizar una respuesta en caché, que desea obtener la respuesta por parte del propio servidor Web de origen.

La respuesta dice:

Cache-Control: public, max-age=31536000

, que le dice a todos que, en lo que se refiere al servidor de origen, la respuesta puede se almacena en caché. El servidor parece estar configurado para permitir que la imagen PNG para ser almacenado en caché: HTTP 1.1 (sección 14.21) dice:

  

Nota: si la respuesta incluye una   campo Cache-Control con el máximo de edad   Directiva (véase la sección 14.9.3), que   anula la directiva Expira campo.

Su segunda petición dice:

Cache-Control: max-age=0

que indica a todos los cachés del HTTP intermedia que no tomará ninguna respuesta en caché mayor que 0 segundos.

Una cosa a tener en cuenta: si se pulsa el botón Volver a cargar en Firefox, que está pidiendo para recargar desde el servidor Web de origen. Para probar el almacenamiento en caché de la imagen, navegar fuera de la página y volver, o abrirlo en una nueva pestaña. No sé por qué usted vio no-cache primera vez y max-age = 0 el segundo embargo.

Por cierto, me gusta el FireBug plug-in para Firefox. Puede echar un vistazo a las cabeceras de petición y respuesta con él y todo tipo de otras cosas buenas.

Answer 3

se parece a lo resolvieron:

• Se ha quitado el proxy a través de cabecera
• Se ha añadido una cabecera Last-Modified
• añadido un futuro lejano expira la fecha

Firebug todavía muestra 200 respuestas desde el servidor de origen, sin embargo, YSlow reconoce las imágenes como en caché. De acuerdo con YSlow, tamaño de la imagen total de descarga para los frescos es mayor que 500 K; con la caché de cebado, se muestra 0K tamaño de la descarga.

Esta es la cabecera de respuesta desde el servidor de origen, que hace el truco:

Date: Tue, 24 Nov 2009 08:54:24 GMT
Server: Apache/2.2.11 (Ubuntu) mod_apreq2-20051231/2.6.0 mod_perl/2.0.4 Perl/v5.10.0
Last-Modified: Sun, 22 Nov 2009 07:28:25 GMT
Expires: Tue, 30 Nov 2010 19:00:25 GMT
Content-Length: 10883
Content-Type: image/jpeg
Keep-Alive: timeout=15, max=89
Connection: Keep-Alive

Debido a la forma en que estoy solicitando las imágenes, lo que realmente no debería importar si estas fechas son estáticas; mi aplicación conoce la última vez mod antes de solicitar la imagen y añade esto a la URL de la solicitud en el lado del cliente para crear una URL única para cada versión de la imagen, por ejemplo, http://myserver.com/img/125.jpg?20091122 (la info proviene de una alimentación AJAX JSON). Podría, por ejemplo, hacer que la última fecha de modificación 01 Ene 2000 y la fecha de Expira en algún momento del año 2050.

Si YSlow es correcta - y pruebas de rendimiento implica que es -. FireBug entonces realmente debe reportar estos aciertos de caché local en lugar de una respuesta 200