Pourquoi utiliser à la fois no-cache et no-store dans la réponse HTTP?

On me dit d'éviter les fuites d'informations sur l'utilisateur, seul le "no-cache" en réponse ne suffit pas. "no-store" est également nécessaire.

Cache-Control: no-cache, no-store

Après avoir lu cette spécification http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html , je ne sais toujours pas pourquoi.

Ma compréhension actuelle est que c'est juste pour le serveur de cache intermédiaire. Même si "no-cache" est en réponse, le serveur de cache intermédiaire peut toujours enregistrer le contenu dans un stockage non volatile. Le serveur de cache intermédiaire décidera d'utiliser ou non le contenu enregistré pour la demande suivante. Cependant, si "no-store" est dans la réponse, le serveur de cache intermédiaire n'est pas censé stocker le contenu. Donc, c'est plus sûr.

Y a-t-il une autre raison pour laquelle nous avons besoin à la fois de "no-cache" et de "no-store"?

Je dois préciser que no-cachecela ne signifie pas ne pas mettre en cache . En fait, cela signifie «revalider avec le serveur» avant d'utiliser toute réponse mise en cache que vous pourriez avoir, à chaque demande.

must-revalidate, d'autre part, n'a besoin de revalider que lorsque la ressource est considérée comme périmée.

Si le serveur dit que la ressource est toujours valide, le cache peut répondre avec sa représentation, ce qui évite au serveur de renvoyer la ressource entière.

no-storeest effectivement la directive full do not cache et vise à empêcher le stockage de la représentation sous quelque forme de cache que ce soit.

Je dis quoi que ce soit, mais notez ceci dans la spécification HTTP RFC 2616:

Les tampons d'historique PEUVENT stocker ces réponses dans le cadre de leur fonctionnement normal

Mais ceci est omis de la nouvelle spécification HTTP RFC 7234 dans une tentative potentielle de rendre no-storeplus fort, voir:

http://tools.ietf.org/html/rfc7234#section-5.2.1.5

Dans certaines circonstances, IE6 mettra toujours en cache les fichiers même lorsqu'ils Cache-Control: no-cachese trouvent dans les en-têtes de réponse.

Le W3C déclareno-cache :

Si la directive no-cache ne spécifie pas de nom de champ, alors une antémémoire NE DOIT PAS utiliser la réponse pour satisfaire une demande ultérieure sans revalidation réussie avec le serveur d'origine.

Dans mon application, si vous visitez une page avec l'en- no-cachetête , que vous vous déconnectez puis que vous revenez dans votre navigateur, IE6 récupère toujours la page du cache (sans nouvelle demande / validation au serveur). L'ajout de l'en- no-storetête l'a empêché de le faire. Mais si vous prenez le W3C au mot, il n'y a en fait aucun moyen de contrôler ce comportement:

Les tampons d'historique PEUVENT stocker ces réponses dans le cadre de leur fonctionnement normal.

Les différences générales entre l'historique du navigateur et la mise en cache HTTP normale sont décrites dans une sous-section spécifique de la spécification .

À partir de la spécification HTTP 1.1 :

pas de magasin :

Le but du no-storedirective est d'empêcher la publication ou la rétention par inadvertance d'informations sensibles (par exemple, sur des bandes de sauvegarde). La directive no-store s'applique à tout le message et PEUT être envoyée soit dans une réponse, soit dans une demande. Si elle est envoyée dans une demande, une antémémoire NE DOIT PAS stocker aucune partie de cette demande ni aucune réponse à celle-ci. Si elle est envoyée dans une réponse, une antémémoire NE DOIT PAS stocker aucune partie de cette réponse ou de la demande qui l'a suscitée. Cette directive s'applique aux caches non partagés et partagés. "NE DOIT PAS stocker" dans ce contexte signifie que l'antémémoire NE DOIT PAS stocker intentionnellement les informations dans une mémoire non volatile, et DOIT faire un effort pour supprimer les informations de la mémoire volatile aussi rapidement que possible après leur transmission. Même lorsque cette directive est associée à une réponse, les utilisateurs peuvent explicitement stocker une telle réponse en dehors du système de mise en cache (par exemple, avec une boîte de dialogue "Enregistrer sous"). Les tampons d'historique PEUVENT stocker ces réponses dans le cadre de leur fonctionnement normal. Le but de cette directive est de répondre aux exigences déclarées de certains utilisateurs et auteurs de services qui s'inquiètent de la diffusion accidentelle d'informations via des accès imprévus aux structures de données de cache. Bien que l'utilisation de cette directive puisse améliorer la confidentialité dans certains cas, nous avertissons qu'elle ne constitue en aucun cas un mécanisme fiable ou suffisant pour garantir la confidentialité. En particulier, les caches malveillants ou compromis peuvent ne pas reconnaître ou obéir à cette directive, et les réseaux de communication peuvent être vulnérables aux écoutes clandestines. Les tampons d'historique PEUVENT stocker ces réponses dans le cadre de leur fonctionnement normal. Le but de cette directive est de répondre aux exigences déclarées de certains utilisateurs et auteurs de services qui s'inquiètent de la diffusion accidentelle d'informations via des accès imprévus aux structures de données de cache. Bien que l'utilisation de cette directive puisse améliorer la confidentialité dans certains cas, nous avertissons qu'elle ne constitue en aucun cas un mécanisme fiable ou suffisant pour garantir la confidentialité. En particulier, les caches malveillants ou compromis peuvent ne pas reconnaître ou obéir à cette directive, et les réseaux de communication peuvent être vulnérables aux écoutes clandestines. Les tampons d'historique PEUVENT stocker ces réponses dans le cadre de leur fonctionnement normal. Le but de cette directive est de répondre aux exigences déclarées de certains utilisateurs et auteurs de services qui s'inquiètent de la diffusion accidentelle d'informations via des accès imprévus aux structures de données de cache. Bien que l'utilisation de cette directive puisse améliorer la confidentialité dans certains cas, nous avertissons que ce n'est en aucun cas un mécanisme fiable ou suffisant pour garantir la confidentialité. En particulier, les caches malveillants ou compromis peuvent ne pas reconnaître ou obéir à cette directive, et les réseaux de communication peuvent être vulnérables aux écoutes clandestines. Bien que l'utilisation de cette directive puisse améliorer la confidentialité dans certains cas, nous avertissons que ce n'est en aucun cas un mécanisme fiable ou suffisant pour garantir la confidentialité. En particulier, les caches malveillants ou compromis peuvent ne pas reconnaître ou obéir à cette directive, et les réseaux de communication peuvent être vulnérables aux écoutes clandestines. Bien que l'utilisation de cette directive puisse améliorer la confidentialité dans certains cas, nous avertissons que ce n'est en aucun cas un mécanisme fiable ou suffisant pour garantir la confidentialité. En particulier, les caches malveillants ou compromis peuvent ne pas reconnaître ou obéir à cette directive, et les réseaux de communication peuvent être vulnérables aux écoutes clandestines.

Si vous souhaitez empêcher toute mise en cache (par exemple, forcer un rechargement lorsque vous utilisez le bouton de retour), vous avez besoin de:

• pas de cache pour IE

• no-store pour Firefox

Voici mes informations à ce sujet ici:

http://blog.httpwatch.com/2008/10/15/two-important-differences-between-firefox-and-ie-caching/

no-storene devrait pas être nécessaire dans des situations normales et peut nuire à la fois à la vitesse et à la convivialité. Il est destiné à être utilisé lorsque la réponse HTTP contient des informations si sensibles qu'elles ne doivent jamais être écrites dans un cache disque, quels que soient les effets négatifs que cela crée pour l'utilisateur.

Comment ça fonctionne:

• Normalement, même si un agent utilisateur tel qu'un navigateur détermine qu'une réponse ne doit pas être mise en cache, il peut toujours la stocker dans le cache disque pour des raisons internes à l'agent utilisateur. Cette version peut être utilisée pour des fonctionnalités telles que "Afficher la source", "Retour", "Informations sur la page", etc., où l'utilisateur n'a pas nécessairement demandé à nouveau la page, mais le navigateur ne la considère pas comme une nouvelle vue de page et il serait logique de servir la même version que celle que l'utilisateur consulte actuellement.

• L'utilisation no-storeempêchera cette réponse d'être stockée, mais cela peut avoir un impact sur la capacité du navigateur à donner «afficher la source», «retour», «informations de page» et ainsi de suite sans faire une nouvelle demande distincte pour le serveur, ce qui n'est pas souhaitable. En d'autres termes, l'utilisateur peut essayer de visualiser la source et si le navigateur ne l'a pas gardée en mémoire, on lui dira que ce n'est pas possible, ou cela entraînera une nouvelle demande au serveur. Par conséquent, no-storene doit être utilisé que lorsque l'expérience utilisateur entravée de ces fonctionnalités ne fonctionnant pas correctement ou rapidement est compensée par l'importance de s'assurer que le contenu n'est pas stocké dans le cache.

Ma compréhension actuelle est que c'est juste pour le serveur de cache intermédiaire. Même si "no-cache" est en réponse, le serveur de cache intermédiaire peut toujours enregistrer le contenu dans un stockage non volatile.

Ceci est une erreur. Les serveurs de cache intermédiaires compatibles avec HTTP 1.1 obéiront aux instructions no-cacheet must-revalidate, garantissant que le contenu n'est pas mis en cache. L'utilisation de ces instructions garantira que la réponse n'est pas mise en cache par un cache intermédiaire et que toutes les demandes ultérieures sont renvoyées au serveur d'origine.

Si le serveur de cache intermédiaire ne prend pas en charge HTTP 1.1, vous devrez utiliser Pragma: no-cacheet espérer le meilleur. Notez que s'il ne prend pas en charge HTTP 1.1, il no-storen'est de toute façon pas pertinent.

Si un système de mise en cache implémente correctement le no-store, vous n'aurez pas besoin du no-cache. Mais pas tous. De plus, certains navigateurs implémentent le no-cache comme s'il s'agissait d'un no-store. Ainsi, bien que cela ne soit pas strictement obligatoire, il est probablement plus sûr d'inclure les deux.

Notez qu'Internet Explorer de la version 5 à 8 générera une erreur lors de la tentative de téléchargement d'un fichier servi via https et l'envoi du serveur Cache-Control: no-cacheou les en- Pragma: no-cachetêtes.

Voir http://support.microsoft.com/kb/812935/en-us

L'utilisation de Cache-Control: no-storeet Pragma: privatesemble être la chose la plus proche qui fonctionne toujours.

Pour Chrome, le no-cache est utilisé pour recharger la page lors d'une nouvelle visite, mais il la met toujours en cache si vous revenez dans l'historique (bouton retour). Pour recharger également la page pour l'historique, utilisez no-store. IE doit être revalidé pour fonctionner en toutes occasions.

Donc, juste pour être sûr d'éviter tous les bugs et mauvaises interprétations que j'utilise toujours

Cache-Control: no-store, no-cache, must-revalidate

si je veux m'assurer qu'il se recharge.

À l'origine, nous avons utilisé le no-cache il y a de nombreuses années et avons rencontré des problèmes de contenu obsolète avec certains navigateurs ... Je ne me souviens malheureusement pas des détails.

Depuis, nous nous sommes décidés à utiliser JUSTE le no-store. Je n'ai jamais regardé en arrière ou eu un seul problème avec le contenu périmé par aucun navigateur ou intermédiaire depuis.

Cet espace est certainement dominé par la réalité des implémentations par rapport à ce qui a été écrit dans diverses RFC. De nombreux mandataires en particulier ont tendance à penser qu'ils réussissent mieux à «améliorer les performances» en remplaçant la politique qu'ils sont censés suivre par la leur.

Juste pour aggraver les choses, dans certaines situations, le no-cache ne peut pas être utilisé, mais le no-store peut:

http://faindu.wordpress.com/2008/04/18/ie7-ssl-xml-flex-error-2032-stream-error/

OWASP discute de ceci:

Quelle est la différence entre les directives de contrôle de cache: no-cache et no-store?

La directive no-cache dans une réponse indique que la réponse ne doit pas être utilisée pour servir une demande ultérieure, c'est-à-dire que le cache ne doit pas afficher une réponse qui a cette directive définie dans l'en-tête mais doit laisser le serveur servir la demande. La directive no-cache peut inclure certains noms de champ; auquel cas la réponse peut être affichée à partir du cache, à l'exception des noms de champ spécifiés qui doivent être servis depuis le serveur. La directive no-store s'applique à l'ensemble du message et indique que le cache ne doit stocker aucune partie de la réponse ni aucune demande l'ayant demandé.

Suis-je totalement en sécurité avec ces directives?

Non. Mais en général, utilisez à la fois Cache-Control: no-cache, no-store et Pragma: no-cache, en plus de Expires: 0 (ou une date GMT suffisamment antidatée telle que l'époque UNIX). Les types de contenu non HTML tels que pdf, documents Word, feuilles de calcul Excel, etc. sont souvent mis en cache même lorsque les directives de contrôle de cache ci-dessus sont définies (bien que cela varie selon la version et l'utilisation supplémentaire de must-revalidate, pre-check = 0, post-check = 0, max-age = 0 et s-maxage = 0 en pratique peuvent parfois entraîner au moins la suppression de fichiers lors de la fermeture du navigateur dans certains cas en raison de bizarreries du navigateur et d'implémentations HTTP). De plus, la fonction «Autocomplete» permet à un navigateur de mettre en cache tout ce que l'utilisateur tape dans un champ de saisie d'un formulaire. Pour vérifier cela, la balise de formulaire ou les balises d'entrée individuelles doivent inclure l'attribut 'Autocomplete = "Off"'. cependant,

Source ici .