Cache du navigateur de contrôle, contenu dynamique

Question

Problème: Je ne peux pas sembler obtenir FireFox pour mettre en cache les images envoyées par un serveur dynamique

Configuration:. statique serveur Apache avec proxy inverse à un serveur dynamique (mod_perl2) au back-end

Voici l'URL de requête pour le serveur. Il est envoyé au serveur dynamique, où le cookie est utilisé pour valider l'accès à l'image

Demande en-têtes

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

Le serveur dynamique des flux de l'image sur le serveur, et fournit la réponse suivante:

Réponse en-têtes

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

Jusqu'à présent, si bon (me pense). Cependant, reload de la page , l'image ne figure pas mises en cache, et une demande est à nouveau envoyé:

Demande en-têtes

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

Il ne semble pas que la demande devrait se produire que le navigateur doit avoir mis en cache l'image. Comme il est, une réponse 200 est reçue, identique à la première, et l'image semble être à nouveau tiré par les cheveux (bien que le navigateur ne semble être en utilisant les images mises en cache).

Le problème semble être laissé entrevoir par le Cache-Control: max-age = 0 dans l'en-tête de demande de rechargement, au-dessus

.

Quelqu'un sait pourquoi cela se passe? Peut-être est l'en-tête Via dans la réponse qui est à l'origine du problème?

Answer 1

Ma réponse précédente n'a été que partiellement correcte.

Le problème est la façon dont les poignées FireFox 3 rechargent événements. Apparemment, il demande presque toujours le contenu du nouveau serveur d'origine. Ainsi, l'en-tête de demande de Cache-Control: max-age=0.

Firefox fait utiliser des images mises en cache pour rendre une page sur reload, mais il fait encore toutes les demandes de les mettre à jour « en arrière-plan ». Il les remplacer alors qu'ils entrent en jeu.

Par conséquent, la page rend rapide, YSlow rapports contenu mis en cache. Mais le serveur est toujours obtenir clouée.

La résolution est d'interroger les en-têtes entrants dans le script de serveur dynamique et déterminer si un « If-Modified-Since » en-tête est fourni. Si tel est le cas, et il est déterminé que le contenu n'a pas changé, une réponse HTTP_NOT_MODIFIED (304) est renvoyée.

Ce n'est pas optimale - je préfère Firefox pas fait les demandes du tout - mais il réduit le temps de chargement de la page en deux, et réduit considérablement la bande passante. Compte tenu de la façon dont Firefox fonctionne sur reload, cela semble la meilleure solution.

Autres commentaires : point de Jim Ferran sur la navigation loin de la page et le retour a le mérite - le cache est toujours utilisé, et aucune demande ne sortant (+1 à Jim). En outre, le contenu est ajouté dynamiquement (par exemple AJAX appelle après la charge initiale) semblent utiliser le cache ainsi.

Espérons que cela aide quelqu'un à côté de moi:)

Answer 2

La demande initiale a

Cache-Control: no-cache

qui indique toutes les caches HTTP intermédiaires (y compris Firefox) de que vous ne souhaitez pas utiliser une réponse en cache, vous voulez obtenir la réponse du serveur Web d'origine lui-même.

La réponse dit:

Cache-Control: public, max-age=31536000

qui indique à chacun que en ce qui concerne le serveur d'origine, la réponse peut être mises en cache. Le serveur semble être configuré pour permettre à l'image PNG être mis en cache: HTTP 1.1 (section 14.21) dit:

  

Note: si une réponse comprend un   champ Cache-Control avec le max-age   directive (voir section 14.9.3), que   directive remplace le champ Expires.

Votre deuxième demande dit:

Cache-Control: max-age=0

qui indique toutes les caches HTTP intermédiaires que vous ne prendra aucune réponse mise en cache plus de 0 secondes.

Une chose à surveiller: si vous appuyez sur le bouton Recharger dans Firefox, vous demandez de recharger à partir du serveur Web d'origine. Pour tester la mise en cache de l'image, naviguer loin de la page et le dos, ou l'ouvrir dans un nouvel onglet. Je ne sais pas pourquoi vous avez vu sans cache la première fois et max-age = 0, la seconde si.

BTW, j'aime le plug-in Firebug pour Firefox. Vous pouvez jeter un oeil à les en-têtes de requête et de réponse avec elle et toutes sortes d'autres bonnes choses.

Answer 3

On dirait résolu:

• Suppression de la procuration par tête
• Ajout d'un en-tête Last-Modified
• Ajout d'une date arrive à expiration extrême avenir

Firebug montre encore 200 réponses du serveur d'origine, cependant, YSlow reconnaît les images en cache. Selon YSlow, la taille totale de téléchargement d'image à l'état frais est supérieur à 500K; avec le cache apprêté, il montre la taille de téléchargement 0K.

Voici l'en-tête de réponse du serveur d'origine qui fait l'affaire:

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

En raison de la façon dont je demande les images, il ne devrait vraiment pas d'importance si ces dates sont statiques; mon application connait la dernière fois mod avant de demander l'image et ce à l'ajoute URL de la demande du côté client pour créer une URL unique pour chaque version d'image, par exemple http://myserver.com/img/125.jpg?20091122 (l'info provient d'une alimentation AJAX JSON). Je pourrais, par exemple, faire la dernière date de modification 1 janvier 2000 et la date Expire dans le courant de l'année 2050.

Si YSlow est correct - les tests et la performance implique qu'il est -. Alors Firebug devrait vraiment signaler ces cache local frappe au lieu d'une réponse 200