Partager via

Comment empêcher la mise en cache dans Internet Explorer

  • Article

Avertissement

L’application de bureau Internet Explorer 11, mise hors service et dont le support a pris fin, a été désactivée définitivement via une mise à jour Microsoft Edge sur certaines versions de Windows 10. Pour plus d’informations, consultez le forum aux questions sur la mise hors service de l’application de bureau Internet Explorer 11.

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

Version du produit d’origine : Internet Explorer
Numéro de 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 au début extrême 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 Expires

Il est vivement recommandé que tous les serveurs Web utilisent un schéma pour l’expiration de toutes les pages Web. Il est déconseillé pour un serveur web de ne pas fournir d’informations d’expiration via l’en-tête de réponse HTTP Expire pour chaque ressource retournée aux clients demandeurs. La plupart des navigateurs et proxys intermédiaires respectent aujourd’hui ces informations d’expiration et l’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 lorsqu’un fichier particulier sur le serveur doit être mis à jour par le client. Lorsque des 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 quotidiennes sur Internet qui est mise à jour tous les jours à 5 H. Le serveur web de cette page d’actualités doit retourner un en-tête Expire avec une valeur de 5 A.M. le lendemain. Une fois cette opération terminée, le navigateur n’a pas besoin de contacter à nouveau 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 de changer 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 les mises à jour de cette page via une demande conditionnelle If-Modified-Since. Toutefois, la page reste dans le cache de 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 AVANT 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 hors du cache ne sont pas accessibles tant que le navigateur ne peut pas recontacter 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 d’Expires : -1 est préférable.

Pragma : En-tête No-Cache

Malheureusement, les serveurs HTTP 1.0 hérités ne peuvent pas utiliser l’en-tête Cache-Control. Pour des raisons 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 uniquement dans le contexte d’une requête, et non dans une réponse. Elle est destinée aux serveurs proxy qui peuvent empêcher certaines demandes 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 permettent une forme HTTP-EQUIV spéciale de la balise META qui spécifie des en-têtes HTTP particuliers à partir du document HTML. Voici un court exemple de page HTML qui utilise 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’elle est utilisée sur une connexion sécurisée. Une balise Pragma : no-cache META est traitée de façon identique à Expire : -1 si elle est utilisée dans une page non sécurisée. La page sera mise en cache, mais marquée comme ayant expiré immédiatement.

Les balises META HTTP-EQUIV de contrôle du cache 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.

Note

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 existe 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 des options dans la configuration du serveur pour ajouter cet en-tête automatiquement. 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 IIS.
  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 no-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 de cet article et que vous rencontrez toujours des problèmes de mise en cache et d’Internet Explorer, passez en revue cette liste de contrôle 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é deux fois que votre serveur web a activé HTTP 1.1 et retourne des réponses HTTP 1.1 à Internet Explorer ? Les en-têtes Cache-Control ne sont pas valides dans les réponses HTTP 1.0.
  • Si vous utilisez CGI/ISAPI/Servlets côté serveur, suivez-vous la spécification HTTP 1.1 exactement, en particulier sur l’arrêt CRLF des en-têtes HTTP ? Dans l’intérêt des performances, Internet Explorer n’est généralement pas pardonnant de réponses qui ne respectent pas la spécification HTTP 1.1. Il entraîne généralement des en-têtes ou des rapports ignorés d’erreurs de serveur inattendues.
  • Les en-têtes HTTP sont-ils correctement orthographiés ?

Voir aussi