En-têtes pour empêcher les demandes 304 / If-modified-since / HEAD

Quels en-têtes dois-je envoyer pour arrêter définitivement toutes les demandes au serveur après la mise en cache du contenu?

Nous avons un serveur à latence très élevée (Sigh, VMWare) donc même l'envoi d'une HEADrequête au serveur prend + 40 ms.

Actuellement, ce sont les en-têtes envoyés / reçus;

Première demande

Le client envoie;

GET http://dugong:8080/Rvi24mYJkxFRGNzq73PPvgWGh1j/IMG_2071.jpg HTTP/1.1
Host: dugong:8080
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:9.0) Gecko/20100101 Firefox/9.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
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
Pragma: no-cache, no-cache, no-cache
Cache-Control: no-cache, no-cache, no-cache

Le serveur répond;

HTTP/1.1 200 OK
Server: nginx/1.0.11
Date: Wed, 01 Feb 2012 14:51:51 GMT
Content-Type: text/plain
Vary: Accept-Encoding
Last-Modified: Tue, 31 Jan 2012 10:45:11 GMT
Content-Length: 14
Expires: Thu, 31 Jan 2013 14:51:51 GMT
Cache-Control: max-age=31536000

Donc , il envoie un Cache-Controlet Expiresjeu d' en- tête à 365 jours dans l'avenir. Malheureusement, lors du deuxième rafraîchissement, il demande à nouveau l'objet avec un en- If-Modified-Sincetête.

Seconde demande

GET http://dugong:8080/Rvi24mYJkxFRGNzq73PPvgWGh1j/IMG_2071.jpg HTTP/1.1
Host: dugong:8080
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:9.0) Gecko/20100101 Firefox/9.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
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
If-Modified-Since: Tue, 31 Jan 2012 10:45:11 GMT
Cache-Control: max-age=0

Réponse;

HTTP/1.1 304 Not Modified
Server: nginx/1.0.11
Date: Wed, 01 Feb 2012 14:58:00 GMT
Vary: Accept-Encoding
Expires: Thu, 31 Jan 2013 14:58:00 GMT
Cache-Control: max-age=31536000

Malheureusement, en raison d'un stupide logiciel de proxy obsolète, nous ne pouvons pas utiliser Keep-Aliveou placer d'autres serveurs / proxys devant l'application. Nous ne pouvons pas non plus améliorer les performances du serveur et réduire la latence du réseau. J'ai essayé de comprendre quels en-têtes nous pouvons envoyer pour se débarrasser des 301 demandes. J'ai essayé d'utiliser ETags mais cela ne fait aucune différence, il envoie toujours un en- If-modified-sincetête. J'ai également essayé de supprimer l'en- Last-Modifiedtête, mais cela provoque simplement une demande GET standard sans mise en cache (vérifié les journaux, le serveur reçoit toujours des demandes).

Les clients sont un mélange de Firefox (principalement), IE 7, 8 et (certains) 9, Chrome et Safari, mais ce comportement semble apparaître dans tous les navigateurs testés.

TL; DR;

Terrible network, quels en-têtes dois-je envoyer pour dire aux clients de ne jamais envoyer de If-modified-sincedemandes au serveur pour valider leur cache et de conserver le contenu en cache jusqu'à ce que l'en- Expirestête soit rencontré?

Il me manque probablement quelque chose d'évident, mais tout ce que j'essaie semble donner les mêmes résultats.

_{Nous avons un serveur NGINX assis devant notre serveur d'applications afin que je puisse ajouter / supprimer les en-têtes à ma guise. Notre proxy ne prend pas en charge Keep-Alive et le leur n'est aucun moyen d'améliorer les performances du réseau attrayant. En raison de la mauvaise conception du logiciel, l'application Web charge +100 ressources à chaque chargement de page (ouais, le logiciel d'entreprise est nul) avec une latence de ~ 40-50 ms par objet.}

Vous ne pouvez pas vraiment contrôler les en-têtes que les agents utilisateurs décident de vous envoyer. Si le fichier en question se trouve dans le cache du navigateur et qu'il décide qu'il doit rechercher une nouvelle version, il le fera. Selon cet article , ce sont les situations que les navigateurs demanderont en utilisant If-Modified-Since:

• L'entrée en cache n'a pas de date d'expiration et le contenu est accédé pour la première fois dans une session de navigateur
• L'entrée en cache a une date d'expiration mais elle a expiré
• L'utilisateur a demandé une mise à jour de la page en cliquant sur le bouton Actualiser ou en appuyant sur F5

Donc, si vous rechargez la page pour tester votre mise en cache, cela ne fonctionnera pas car le navigateur demandera à nouveau les images. Essayez de cliquer sur un lien, puis sur un autre lien vers la première page. Si vos utilisateurs rechargent régulièrement des pages, vous devrez peut-être repenser la structure de votre site / application pour éviter cela.

Une chose qui peut aider est d'ajouter "public" à l'en-tête de contrôle du cache, c'est-à-dire Cache-Control: public, max-age=31536000. J'ai également appris récemment qu'une date d'expiration de plus d'un an n'est pas valide. Étant donné que votre date d'expiration est exactement d'un an, une réduction de quelques jours ou semaines pourrait garantir que le fichier reste dans les caches du navigateur et n'est pas supprimé.

Ce que vous voulez, c'est le immutablemot - clé dans votre Cache-Controlligne. Exemple pour php:

header('Cache-Control: public, max-age=80000, immutable');

Source: https://code.facebook.com/posts/557147474482256/this-browser-tweak-saved-60-of-requests-to-facebook/

J'ai eu le même problème, et les demandes frappent définitivement le serveur pour qu'il réponde avec le 304statut - j'envoie le 304 via du C # et c'est sûr qu'il frappe le serveur ..

J'avais seulement Cache-Control: privatemis. Non max-ageet non ExpiresIl a fonctionné comme prévu; frapper le serveur avec le If-Modified-Sinceoù je teste la valeur par rapport à ce que j'attends et livrer 304avec un corps de réponse vide - sinon 200& remplir le corps de la réponse.

La définition de l'en- Expirestête a eu les résultats souhaités, 200 - (from cache)sur le client et aucune requête HTTP n'a atteint le serveur.

Mais .. J'ai trouvé que le réglage BOTH max-age= & Expirespeut empêcher les navigateurs d'envoyer des en- If-Modified-Sincetêtes ET de ne pas mettre en cache du tout si les valeurs ne correspondent pas .

Quelque chose à savoir si vous avez des problèmes de mise en cache et utilisé les différents en-têtes en combinaison.

Un peu hors sujet mais peut-être utile. Une autre amélioration pour vos demandes de contenu mis en cache est de mettre en cache dans sessionStorage afin que vous n'ayez pas besoin de demander au serveur de valider le cache et de recevoir un 304. Regardez par exemple google, ouvrez la console et écrivez sessionStorage. Vous verrez qu'ils mettent en cache CSS ou DOM avec sessionStorage. ofc, vous ne pouvez pas utiliser cela dans les anciens navigateurs IE.

Parcourez votre code source et assurez-vous qu'il n'y a pas de META REFRESH pour passer à une autre page. Utilisez plutôt quelque chose comme sendRedirect. Dans ma configuration, META REFRESH produit 304 sous IE, mais pas Chrome. sendRedirect ne produit cela sur aucun navigateur.

<meta http-equiv="refresh" content="0;URL='nextpage'" />    

contre

<% response.sendRedirect("nextpage") %>