Question

Il est courant de demander aux navigateurs de mettre en cache des ressources (JavaScript, CSS, images, etc.) jusqu'à ce qu'une nouvelle version soit disponible, puis de s'assurer que le navigateur récupère et met en cache la nouvelle version.

Une solution consiste à incorporer un numéro de version dans le nom du fichier de la ressource, mais placer les ressources à gérer de cette manière dans un répertoire contenant un numéro de révision fera-t-il la même chose? L'URL complète du fichier est-elle utilisée comme clé dans la mémoire cache du navigateur ou s'agit-il uniquement du nom du fichier et de certaines méta-données?

Si mon code ne remplace plus l'extraction de /r20/exemple.js par /r21/exemple.js , puis-je être sûr que la révision 20 de l'exemple . js a été mis en cache, mais la révision 21 a maintenant été récupérée et est maintenant mise en cache?

Était-ce utile?

La solution

Oui, toute modification dans une partie de l'URL (à l'exception des modifications de protocoles HTTP et HTTPS) est interprétée par le navigateur (et par les mandataires intermédiaires) comme une ressource différente. entité séparée dans le cache du navigateur.

Mise à jour:

L'affirmation dans cet article de ThinkVitamin dans Opera et Safari / Webkit Les navigateurs ne mettent pas les URL en cache avec? query = strings est false .

Ajouter un paramètre de numéro de version à une URL est un moyen parfaitement acceptable de contourner le cache.

Ce qui a peut-être dérouté l'auteur de l'article de ThinkVitamin est le fait qu'appuyer sur Entrée dans la barre d'adresse dans Safari et Opera entraîne un comportement différent des URL contenant une chaîne de requête.

Cependant, ( et c'est la partie la plus importante! ), Opera et Safari se comportent exactement comme IE et Firefox en ce qui concerne la mise en cache des images, des stylesheets et des scripts incorporés / liés. dans les pages Web, qu'ils aient "? " caractères dans leurs URL. (Ceci peut être vérifié avec un simple test sur un serveur Apache normal.)

(J'aurais commenté la réponse actuellement acceptée si j'avais la réputation de le faire.: -)

Autres conseils

La clé de cache du navigateur est une combinaison de la méthode de requête et de l'URI de la ressource. L'URI est composé du schéma, de l'autorité, du chemin, de la requête et du fragment.

Extrait pertinent de la spécification HTTP 1.1 :

  

La clé de cache principale est constituée de la méthode de requête et de l'URI cible.      Cependant, étant donné que les caches HTTP d'usage courant sont généralement limités      pour mettre en cache les réponses à GET, beaucoup de caches déclinent simplement d’autres méthodes      et n'utilisez que l'URI comme clé de cache principale.

Extrait pertinent de la spécification d'URI :

  

La syntaxe générique d’URI consiste en une séquence hiérarchique de      composants appelés schéma, autorité, chemin, requête et      fragment.

URI         = scheme ":" hier-part [ "?" query ] [ "#" fragment ]

hier-part   = "//" authority path-abempty
              / path-absolute
              / path-rootless
              / path-empty

Je suis sûr à 99,99999% que c'est l'URL complète utilisée pour mettre en cache les ressources dans un navigateur. Votre schéma d'URL devrait donc fonctionner correctement.

Le minimum que vous devez identifier un objet HTTP est défini par le chemin d'accès complet, y compris les paramètres de chaîne de requête. Certains navigateurs ne peuvent pas mettre en cache des objets avec une chaîne de requête, mais cela n'a rien à voir avec la clé du cache.

Il est également important de se rappeler que le chemin n'est plus suffisant. L'en-tête Vary: de la réponse HTTP alerte le navigateur (ou le serveur proxy, etc.) de tout AUTRE que l'URL à utiliser pour déterminer la clé de cache, telle que les cookies, les valeurs de codage, etc.

.

A votre question de base, oui, la modification de l'URL du fichier .js est suffisante. À la question plus vaste de savoir ce qui détermine la clé de cache, il s’agit de l’URL plus les restrictions Vary: en-tête.

Oui. Un chemin différent est le même du point de vue des caches.

Bien sûr, il doit utiliser tout le chemin "/r20/exemple.js" ou "/r21/exemple.js" peut être une image complètement différente pour commencer. Ce que vous suggérez est un moyen viable de gérer le contrôle de version.

Dans la plupart des navigateurs, l'URL complète est utilisée. Dans certains navigateurs, si vous avez une requête dans l'URL, le document ne sera jamais mis en cache.

URL complète. J'ai constaté un comportement étrange dans quelques anciens navigateurs, où la sensibilité à la casse est entrée en jeu.

En plus des réponses existantes, je souhaite simplement ajouter que cela pourrait ne pas s'appliquer si vous utilisez ServiceWorkers ou, par exemple, offline-plugin. Vous pouvez ensuite utiliser différentes règles de cache, en fonction de la configuration des servicesWorkers.

dépend. il est censé être l'URL complète, mais certains navigateurs (Opera, Safari 2 ) applique une stratégie de cache différente pour les URL avec différents paramètres.

Le mieux est de changer le nom du fichier .

Il existe une solution très intelligente ici (utilise PHP, Apache)

http://verens.com/archives/ 2008/04/09 / javascript-cache-problem-resolved /

Notes de stratégie: & # 8220; Selon la lettre de la spécification de mise en cache HTTP, les agents utilisateurs ne doivent jamais mettre en cache les URL contenant des chaînes de requête. Alors qu'Internet Explorer et Firefox l'ignorent, Opera et Safari ne le font pas pour que tous les agents utilisateurs puissent mettre en cache vos ressources, nous devons conserver les chaînes de requête hors de leurs URL. & # 8221;

http://www.thinkvitamin.com/features/webapps/serving -javascript-fast

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top