web-dev-qa-db-fra.com

Pourquoi FireFox ne cache-t-il pas mon fichier JavaScript?

J'ai essayé de comprendre pourquoi Firefox ne mettait pas mon fichier JavaScript en cache. Je n'ai pas ce problème avec Chrome ou IE.

Voici à quoi ressemble l'en-tête de réponse de mon serveur:

http://localhost:5012/bundles/scripts/jquery?v=FVs3ACwOLIVInrAl5sdzR2jrCDmVOWFbZMY6g6Q0ulE1
Cache-Control   public, max-age=2592000
Content-Encoding    gzip
Content-Length  42173
Content-Type    text/javascript; charset=utf-8
Date    Fri, 23 May 2014 14:33:28 GMT
Expires Sat, 23 May 2015 14:33:22 GMT
Last-Modified   Fri, 23 May 2014 14:33:22 GMT
Server  Microsoft-IIS/7.5
Vary    Accept-Encoding
X-AspNet-Version    4.0.30319
X-Powered-By    ASP.NET
fod_vary_store  User-Agent

Notez s'il vous plaît:

  1. Il n'y a pas d'extension de fichier. J'utilise MS ASP.NET Optimization Framework pour regrouper et minifier mes scripts.
  2. Mon Firefox est 29.0.1. J'ai "Remember History" activé.

Ma question est une copie d'une autre question que j'ai trouvée ici: Pourquoi Firefox ne met-il pas en cache mes images et CSS (sans réponse acceptée). Cela signifiait que les anciennes versions de FireFox ne mettaient pas en cache les ressources avec des chaînes de requête. Cependant, certains utilisateurs ont répondu que le problème avait été résolu dans les versions les plus récentes.

cacheiisfirefox
6
Roman Mik

Il n'est pas recommandé de mettre en cache des ressources avec une chaîne de requête. Une chaîne de requête représente généralement une ressource dynamique. Toutefois, IE et Chrome mettent en cache les en-têtes Cache-Control et Expires. Firefox devrait mettre en cache, cependant, cela pourrait être dû à une validation faible, c'est-à-dire à l'absence d'utilisation d'Etag. L'utilisation d'Etag force la validation du mécanisme de contrôle du cache pour Firefox. Firefox essaie de suivre la section RFC 261613.3.2 . Si le fichier n'a pas changé sur le serveur, vous devriez voir une réponse de 304 non modifié.

13.9 Effets secondaires de GET et HEAD

À moins que le serveur d'origine n'interdit explicitement la mise en cache de leurs réponses, l'application des méthodes GET et HEAD à des ressources NE DEVRAIT PAS avoir d'effets secondaires pouvant conduire à un comportement erroné si ces réponses sont extraites d'un cache. Ils PEUVENT toujours avoir des effets secondaires, mais un cache n'est pas nécessaire pour prendre en compte de tels effets dans ses décisions de mise en cache. Les caches sont toujours censés observer les restrictions explicites d'un serveur Origin sur la mise en cache.

Nous notons une exception à cette règle: étant donné que certaines applications utilisent traditionnellement les méthodes GET et HEAD avec des URL de requête (celles contenant un "?" Dans la partie rel_path) pour effectuer des opérations ayant des effets secondaires importants, les caches NE DOIVENT PAS traiter les réponses à de tels URI sauf si le serveur fournit un délai d'expiration explicite. Cela signifie spécifiquement que les réponses des serveurs HTTP/1.0 pour de tels URI NE DEVRAIENT PAS être extraites d'un cache. Voir la section 9.1.1 pour des informations connexes.

Vous devez donc supposer que la chaîne de requête ne doit pas mettre en cache le contenu dynamique qui inclut le langage HTML. Ce n'est cependant pas le cas pour IE et Chrome qui prêtent attention aux en-têtes Cache-Control et Expires pour l'URI demandé.

Cela dit, cela dépend vraiment de la mise en œuvre du client et du serveur.

Dans Firefox lors du rechargement à l'aide de la touche F5 et de l'examen des outils de développement, vous devriez voir 403 Non modifié pour les attaques de cache lors de l'utilisation de l'en-tête de balise électronique.

Essayez donc d'activer le support ETag dans IIS.

Références:
http://www.mobify.com/blog/beginners-guide-to-http-cache-headers/

7
HypeByte