Pourquoi les deux no-cache et no-store doivent être utilisés dans la réponse HTTP?

Question

Je me suis dit que pour empêcher l'utilisateur-informations de fuite, seulement "no-cache" en réponse n'est pas assez. "no-store" est également nécessaire.

Cache-Control: no-cache, no-store

Après la lecture de ce spec http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.htmlje ne suis toujours pas très bien pourquoi.

Ma compréhension est que c'est juste pour l'intermédiaire du serveur de cache. Même si "no-cache" est en réponse, intermédiaire serveur de cache peut encore sauver le contenu de stockage non volatile. L'intermédiaire du serveur de cache permettra de déterminer si le contenu sauvegardé pour la suite de la demande. Toutefois, en cas de "no-store" est dans la réponse, le cache intermédiaire sever est pas censé stocker le contenu. Donc, c'est plus sûr.

Est-il une autre raison nous avons besoin des deux "no-cache" et "no-store"?

Answer 1

Je dois préciser que "no-cache" ne signifie pas ne pas mettre en cache. En fait, il signifie "revalider avec le serveur" avant d'utiliser un quelconque réponse en cache, vous pouvez avoir, sur chaque demande.

must-revalidate, d'autre part, ne doit relavidate lorsque la ressource est considéré comme périmé.

Si le serveur dit que la ressource est toujours valide ensuite le cache peut répondre à sa représentation, allégeant ainsi la nécessité pour le serveur de renvoyer la totalité de la ressource.

pas de magasin est effectivement la pleine ne pas mettre en cache la directive et est destiné à empêcher le stockage de la représentation dans toute forme de cache que ce soit.

Answer 2

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

Le W3C unis d' no-cache:

Si la directive no-cache n'est pas spécifiez un nom de zone, puis un cache Ne DOIT PAS utiliser la réponse pour satisfaire un demande ultérieure, sans succès revalidation avec le serveur d'origine.

Dans mon application, si vous avez visité une page avec l' no-cache - tête, puis déconnecté, puis a frappé dans votre navigateur IE6 serait encore récupérer la page de la cache (sans nouvelle/la validation de la demande au serveur). En ajoutant à l' no-store - tête de l'arrêté de le faire. Mais si vous prenez le W3C à leur parole, il n'y a vraiment aucun moyen de contrôler ce comportement:

L'histoire de tampons PEUT stocker de telles réponses dans le cadre de leur fonctionnement normal.

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

Answer 3

aucun magasin ne devrait pas être nécessaire dans les situations normales, et peuvent entraver la convivialité si les navigateurs suivent la spécification comme à l'écrit. Il est conçu pour une utilisation où la réponse HTTP contient des informations sensibles qu'il ne faut jamais écrit sur un disque de cache à tous, même si cela casse des choses comme: "afficher la source" ou le bouton retour. no-cache et must-revalidate sont les deux instructions, vous voudrez probablement utiliser.

• Normalement, même si un agent utilisateur du navigateur détermine qu'une réponse est en cache, il peut tout de même de le stocker dans le cache disque pour des raisons internes à l'agent utilisateur. Il peut encore être utilisé pour des fonctions comme "afficher la source", "arrière", page "info", et ainsi de suite, où l'utilisateur n'a pas demandé une nouvelle demande de la ressource.

• L'utilisation de no-store empêcher que cela se produise, mais il peut avoir un impact sur la capacité du navigateur à donner "afficher la source", "arrière", page "info" et ainsi de suite sans faire une nouvelle demande pour le serveur, ce qui est indésirable. En d'autres termes, l'utilisateur peut essayer de l'affichage de la source et si le navigateur ne l'ai pas gardé en mémoire, soit ils vont être dit, ce n'est pas possible, ou qu'il va provoquer une nouvelle requête au serveur. Par conséquent, aucun magasin ne doit être utilisé lorsque le entravé l'expérience utilisateur de ces fonctionnalités ne fonctionne pas correctement ou s'est vite compensé par l'importance de veiller à ce contenu n'est pas stocké dans le cache.

Ma compréhension est que c'est juste pour l'intermédiaire du serveur de cache. Même si "no-cache" est en réponse, intermédiaire serveur de cache peut encore sauver le contenu de stockage non volatile.

Ceci est incorrect. Intermédiaire des serveurs de cache qui suivent la spécification HTTP 1.1 obéir à la "no-cache" et must-revalidate (ou proxy-revalidate) de l'instruction, de s'assurer que le contenu n'est pas mis en cache. À l'aide de ces deux instructions permettra de s'assurer que la réponse n'est pas mis en cache par l'intermédiaire de cache, et que toutes les demandes sont envoyées vers le serveur d'origine

Si l'intermédiaire du serveur de cache ne prend pas en charge le HTTP 1.1, puis vous aurez besoin d'utiliser le Pragma: no-cache et espérer pour le mieux. Notez que si il ne prend pas en charge HTTP 1.1, puis no-store est sans importance de toute façon.

Answer 4

À partir de la spécification HTTP 1.1:

pas de magasin:

Le but de la no-store directive est pour éviter la libération involontaire ou de la rétention d'informations sensibles (par exemple, sur des bandes de sauvegarde). Le no-store directive s'applique à l'intégralité du message, et PEUVENT être envoyées soit à une réponse ou une demande. Si elle est envoyée dans une demande, un cache ne DOIT PAS stocker une partie de cette demande ou de toute réponse. Si elle est envoyée dans une réponse, un cache ne DOIT PAS stocker une partie de cette réponse ou la demande qu'il a suscité. La présente directive s'applique à la fois non - partagées et des caches partagés. "Ne DOIT PAS stocker" dans ce contexte signifie que le cache ne DOIT PAS intentionnellement de stocker les informations dans un stockage non-volatile, et DOIT faire un meilleur effort de tenter de supprimer les informations de stockage volatile, aussi rapidement que possible après le transfert. Même lorsque cette directive est associée à une réponse, les utilisateurs peuvent stocker explicitement une telle réponse en dehors du système de mise en cache (par exemple, avec un "Enregistrer sous" boîte de dialogue). L'histoire de tampons PEUT stocker de telles réponses dans le cadre de leur fonctionnement normal. Le but de cette directive est de rencontrer les besoins de certains utilisateurs et le service des auteurs qui sont préoccupés par les rejets accidentels d'informations via les imprévus de l'accès à des données en cache des structures. Alors que l'utilisation de cette directive pourrait améliorer la vie privée dans certains cas, nous tenons à préciser qu'il N'est en aucune façon fiable ou suffisamment de mécanisme pour assurer la confidentialité. En particulier, malveillants ou compromis caches pourriez ne pas reconnaître ou d'obéir à la présente directive, et de réseaux de communication pourraient être vulnérables à l'écoute.

Answer 5

Si vous souhaitez empêcher toute mise en cache (par exemple, forcer un rechargement lorsque vous utilisez le bouton Précédent), vous avez besoin des éléments suivants:

• no-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/