Pourquoi les deux no-cache et pas de magasin doit être utilisé dans la réponse HTTP?
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.html, je 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 de toute autre raison, nous avons besoin des deux "no-cache" et "no-store"?
no-cache
ne signifie pas ce que vous pensez que cela fonctionne. En fait, il signifie "s'il vous plaît revalidate".
Vous devez vous connecter pour publier un commentaire.
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, n'a pas besoin de revalider 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.
no-store
est effectivement la pleine ne pas mettre en cache directive et est destiné à empêcher le stockage de la représentation dans toute forme de cache que ce soit.Je dis que ce soit, mais il faut noter cela dans la RFC 2616 spécification HTTP:
Mais ce n'est omis de la plus récente à la RFC 7234 spécification HTTP potentiellement une tentative de faire
no-store
plus fort, voir:http://tools.ietf.org/html/rfc7234#section-5.2.1.5
Cache-Control: no-store
assez?no-store
et décritno-cache
comme si il ne fait pas de mise en cache à tous.... Je suis confus!Dans certaines circonstances, IE6 aura toujours des fichiers de cache, même lorsque
Cache-Control: no-cache
est dans les en-têtes de réponse.La W3C états de
no-cache
:Dans ma demande, si vous avez visité une page avec le
no-cache
en-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). L'ajout dans leno-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: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.
no-store
ainsi. Sinon Chrome spectacle mis en cache/tampon de données lors de l'utilisation de la touche retour.no-cache
en-tête. Le W3C devis immédiatement ci-dessous montre que ce n'est pas le cas; au contraire, lano-cache
en-tête signifie simplement que la réponse doit être validé avant d'être réutilisées pour servir les demandes ultérieures.De la HTTP 1.1:
no-cache
etmax-age=0
dire que le l'élément doit être considéré comme périmé. Cela signifie que l'on doit être validé avant d'être servi. Cela signifie qu'un cache pourrait stocker le fichier, puis exécuter une requête conditionnelle à laquelle le serveur peut répondre304 NOT MODIFIED
. C'est évidemment un grand avantage, car le corps de la réponse n'a pas besoin d'être généré et envoyé. Afin de profiter de ce nombre (la majorité?) caches va magasinno-cache
réponses.Si vous voulez empêcher la mise en cache (par exemple, forcer un rechargement lors de l'utilisation du bouton retour) vous avez besoin de:
no-cache pour IE
no-store pour Firefox
Il y a mes informations à ce sujet ici:
http://blog.httpwatch.com/2008/10/15/two-important-differences-between-firefox-and-ie-caching/
no-store
ne devrait pas être nécessaire dans les situations normales, et peut nuire à la fois la vitesse et la facilité d'utilisation. 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, indépendamment des effets négatifs qui crée pour l'utilisateur.Comment cela fonctionne:
Normalement, même si un agent utilisateur du navigateur détermine qu'une réponse ne devrait pas être mis en cache, il peut tout de même de le stocker dans le cache disque pour des raisons internes à l'agent utilisateur. Cette version peut être utilisée pour des fonctions comme "afficher la source", "arrière", page "info", et ainsi de suite, où l'utilisateur n'a pas forcément demandé à nouveau la page, mais le navigateur ne prend pas en compte d'un nouvel affichage de la page et il serait judicieux de servir la même version que l'utilisateur est en train de consulter.
À l'aide de
no-store
empêchera que la réponse est stockée, mais cela peut avoir un impact sur le navigateur de la capacité à donner de l' "afficher la source", "arrière", page "info" et ainsi de suite sans faire une nouvelle demande distincte 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,no-store
doit être utilisée uniquement 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.C'est incorrect. Intermédiaire des serveurs de cache compatible avec HTTP 1.1 obéir à la
no-cache
etmust-revalidate
instructions, s'assurer que le contenu n'est pas mis en cache. À l'aide de ces instructions 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
Pragma: no-cache
et espérer pour le mieux. Notez que si il ne prend pas en charge HTTP 1.1 puisno-store
est sans importance de toute façon.no-cache
maintient rigide de la fraîcheur sans pour autant sacrifier tous les avantages de la mise en cache, ce qui signifie que le cache est stocké et utilisé à nouveau si le serveur répond avec "304 not Modified".Si un système de cache correctement implémente no-store, alors vous n'avez pas besoin de no-cache. Mais pas toutes. En outre, certains navigateurs no-cache comme il a été no-store. Donc, tout n'est pas strictement nécessaire, il est probablement plus sûr de les inclure à la fois.
Pour chrome, no-cache est utilisé pour recharger la page sur une re-visite, mais il reste encore des caches si vous allez en arrière dans l'histoire (bouton retour). Pour recharger la page pour l'histoire-dos, utilisez no-store. IE a besoin de must-revalidate de travailler dans toutes les occasions.
Donc, juste pour être sûr d'éviter tous les bugs et les erreurs d'interprétation, j'ai toujours utiliser
si je veux faire en sorte de le recharger.
Notez qu'Internet Explorer à partir de la version 5 à 8 lèvera une erreur lorsque j'essaie de télécharger un fichier servi via https et le serveur d'envoi
Cache-Control: no-cache
ouPragma: no-cache
en-têtes.Voir http://support.microsoft.com/kb/812935/en-us
L'utilisation de
Cache-Control: no-store
etPragma: private
semble être la chose la plus proche qui fonctionne toujours.Cache-Control: no-store, no-cache, must-revalidate
dans l'ordre exact pour le faire fonctionner. Toutefois, cela ne fonctionne pas dans notre scénario, mais ce que @bassim suggéré ci-dessus n'. Merci!À l'origine, nous avons utilisé le no-cache de nombreuses années et n'a, à des problèmes de contenu périmé, avec certains navigateurs... Ne me souviens pas des détails malheureusement.
Nous a depuis réglé sur l'utilisation de la no-store. N'ont jamais regardé en arrière ou ont eu un seul problème avec le contenu périmé, par n'importe quel navigateur ou intermédiaires depuis.
Cet espace est certainement dominé par la réalité des implémentations vs ce qui se passe pour avoir été écrit dans les différentes Rfc. Beaucoup de procurations, en particulier, ont tendance à penser qu'ils font un meilleur travail de la "amélioration des performances" en remplaçant la politique qu'ils sont censés être à la suite de leur propre.
no-store
.Juste pour rendre les choses encore pire, dans certaines situations, no-cache ne peut pas être utilisé, mais n'-magasin:
http://faindu.wordpress.com/2008/04/18/ie7-ssl-xml-flex-error-2032-stream-error/
OWASP parle de ceci:
Source ici.