Comment empêcher la mise en cache dans Internet Explorer

Avertissement

L’application de bureau Internet Explorer 11 mise hors service et non prise en charge a été désactivée définitivement via une mise à jour de Microsoft Edge sur certaines versions de Windows 10. Pour plus d’informations, consultez FAQ sur la mise hors service des applications de bureau Internet Explorer 11.

Cet article décrit l’utilisation des en-têtes HTTP pour contrôler la mise en cache des pages Web dans Internet Explorer.

Version d’origine du produit : Internet Explorer
Numéro de la base de connaissances d’origine : 234067

Résumé

Vous pouvez utiliser Microsoft Internet Information Server (IIS) pour marquer facilement des pages hautement volatiles ou sensibles à l’aide du script suivant à l’extrême début des pages ASP (Active Server Pages) spécifiques :

<% Response.CacheControl = "no-cache" %>
<% Response.AddHeader "Pragma", "no-cache" %>
<% Response.Expires = -1 %>

Expiration et en-tête Expire

Il est vivement recommandé que tous les serveurs Web utilisent un schéma pour l’expiration de toutes les pages Web. Il est mal pratique pour un serveur Web de ne pas fournir d’informations d’expiration via l’en-tête de réponse HTTP Expires pour chaque ressource retournée aux clients demandeurs. La plupart des navigateurs et des proxys intermédiaires respectent aujourd’hui ces informations d’expiration et les utilisent pour augmenter l’efficacité des communications sur le réseau.

Utilisez toujours l’en-tête Expires pour spécifier le délai le plus raisonnable où un fichier particulier sur le serveur doit être mis à jour par le client. Lorsque les pages sont régulièrement mises à jour, la prochaine période de mise à jour est la réponse la plus efficace. Prenons, par exemple, une page d’actualités quotidienne sur Internet qui est mise à jour tous les jours à 5 heures du matin. Le serveur web de cette page d’actualités doit retourner un en-tête Expires avec une valeur pour 5 heures du matin le lendemain. Une fois l’opération terminée, le navigateur n’a pas besoin de recontacter le serveur web tant que la page n’a pas changé.

Les pages qui ne sont pas censées changer doivent être marquées avec une date d’expiration d’environ un an.

Dans de nombreux cas, les serveurs Web ont une ou plusieurs pages volatiles sur un serveur qui contiennent des informations susceptibles d’être modifiées immédiatement. Ces pages doivent être marquées par le serveur avec la valeur « -1 » pour l’en-tête Expire. Sur les demandes ultérieures de l’utilisateur, Internet Explorer contacte généralement le serveur web pour obtenir des mises à jour de cette page via une requête conditionnelle If-Modified-Since. Toutefois, la page reste dans le cache du disque (fichiers Internet temporaires). Et la page est utilisée dans les situations appropriées sans contacter le serveur web distant, par exemple :

  • lorsque les boutons PRÉCÉDENT et SUIVANT sont utilisés pour accéder à l’historique de navigation.
  • lorsque le navigateur est en mode hors connexion.

En-tête Cache-Control

Toutefois, certaines pages sont si volatiles ou sensibles qu’elles ne nécessitent aucune mise en cache de disque. À cette fin, Internet Explorer prend en charge l’en-tête HTTP 1.1 Cache-Control. Cet en-tête empêche toute mise en cache d’une ressource Web particulière lorsque la valeur sans cache est spécifiée par un serveur HTTP 1.1.

Les pages qui sont conservées en dehors du cache ne sont pas accessibles tant que le navigateur n’a pas été en mesure de contacter le serveur Web. Par conséquent, les serveurs doivent utiliser l’en-tête Cache-Control avec parcimonie. Dans la plupart des cas, l’utilisation de Expire : -1 est préférable.

L’en-tête Pragma : No-Cache

Malheureusement, les serveurs HTTP 1.0 hérités ne peuvent pas utiliser l’en-tête Cache-Control. À des fins de compatibilité descendante avec les serveurs HTTP 1.0, Internet Explorer prend en charge une utilisation spéciale de l’en-tête HTTP Pragma: no-cache. Si le client communique avec le serveur via une connexion sécurisée (https://) et que le serveur retourne un en-tête Pragma: no-cache avec la réponse, Internet Explorer ne met pas en cache la réponse.

Toutefois, l’en-tête Pragma: no-cache n’était pas à cet effet. Selon les spécifications HTTP 1.0 et 1.1, cet en-tête est défini dans le contexte d’une requête uniquement, et non dans une réponse. Il est destiné aux serveurs proxy qui peuvent empêcher certaines requêtes importantes d’atteindre le serveur Web de destination. Pour les applications futures, l’en-tête Cache-Control est le moyen approprié pour contrôler la mise en cache.

Balises META HTTP-EQUIV

Les pages HTML autorisent un formulaire HTTP-EQUIV spécial de la balise META qui spécifie des en-têtes HTTP particuliers à partir du document HTML. Voici un bref exemple de page HTML qui utilise à la fois Pragma : no-cache et Expire : -1 :

<HTML>
    <HEAD>
        <META HTTP-EQUIV="Pragma" CONTENT="no-cache">
        <META HTTP-EQUIV="Expires" CONTENT="-1">
    </HEAD>
<BODY>
</BODY>
</HTML>

Pragma : aucun cache empêche la mise en cache uniquement lorsqu’il est utilisé via une connexion sécurisée. Une balise META Pragma: no-cache est traitée de la même façon que Expire: -1 si elle est utilisée dans une page non sécurisée. La page est mise en cache, mais marquée comme ayant expiré immédiatement.

Cache-Control balises META HTTP-EQUIV sont ignorées et n’ont aucun effet dans Internet Explorer versions 4 ou 5. Pour utiliser Cache-Control, cet en-tête doit être spécifié à l’aide d’en-têtes HTTP, comme décrit dans la section Cache-Control ci-dessus.

Remarque

L’utilisation d’en-têtes HTTP standard est préférable aux balises META. Les balises META doivent généralement apparaître en haut de la section HTML HEAD. Et il y a au moins un problème connu avec la balise Pragma HTTP-EQUIV META.

Options de serveur pour la mise en cache

Lorsque l’en-tête Cache-Control doit être utilisé sur des pages non ASP, il peut être nécessaire d’utiliser les options de la configuration du serveur pour ajouter automatiquement cet en-tête. Pour le processus d’ajout d’en-têtes HTTP aux réponses du serveur pour un répertoire particulier, reportez-vous au document de votre serveur. Par exemple, dans IIS 4, procédez comme suit :

  1. Démarrez le Gestionnaire des services Internet.
  2. Dans l’arborescence ordinateur et services, ouvrez le serveur web par défaut ou le serveur web en question. Recherchez le répertoire contenant le contenu qui a besoin de l’en-tête Cache-Control.
  3. Ouvrez la boîte de dialogue Propriétés de ce répertoire.
  4. Sélectionnez l’onglet En-têtes HTTP .
  5. Sélectionnez le bouton Ajouter dans le groupe En-têtes HTTP personnalisés, puis ajoutez Cache-Control pour le nom de l’en-tête et aucun cache pour la valeur d’en-tête.

Il n’est pas judicieux d’utiliser cet en-tête globalement sur l’ensemble du serveur Web. Limitez son utilisation uniquement au contenu qui ne doit absolument pas être mis en cache sur le client.

Liste de contrôle des problèmes

Si vous avez appliqué les techniques décrites dans cet article et que vous rencontrez toujours des problèmes avec la mise en cache et Internet Explorer, consultez cette liste de vérification pratique étape par étape avant de contacter Microsoft pour obtenir de l’aide technique :

  • Utilisez-vous l’en-tête Cache-Control avec la propriété ASP Response.CacheControl ou via un en-tête HTTP retourné ? C’est la seule façon d’empêcher réellement la mise en cache dans Internet Explorer.
  • Utilisez-vous Internet Explorer 4.01 Service Pack 2 ou version ultérieure ? Il n’existe aucun moyen d’empêcher complètement la mise en cache dans les versions antérieures du navigateur.
  • Avez-vous vérifié que le protocole HTTP 1.1 est activé sur votre serveur web et qu’il retourne des réponses HTTP 1.1 à Internet Explorer ? Cache-Control en-têtes ne sont pas valides dans les réponses HTTP 1.0.
  • Si vous utilisez CGI/ISAPI/Servlets côté serveur, suivez-vous exactement la spécification HTTP 1.1, en particulier en ce qui concerne l’arrêt CRLF des en-têtes HTTP ? Dans l’intérêt des performances, Internet Explorer est généralement impitoyable en ce qui concerne les réponses qui enfreignent la spécification HTTP 1.1. Il en résulte généralement des en-têtes ignorés ou des rapports d’erreurs de serveur inattendues.
  • Les en-têtes HTTP sont-ils correctement orthographiés ?

Voir aussi