Résultats inattendus de la mise en cache de L'AJAX dans IE8

Comme marr75 , GET 's sont mis en cache.

il y a plusieurs façons de combattre cela. Outre la modification de l'en-tête de réponse, vous pouvez également ajouter une variable de chaîne de requête générée au hasard à la fin de L'URL visée. De cette façon, IE pensera que c'est une URL différente chaque fois qu'il est demandé.

il y a plusieurs façons de faire cela (comme utiliser Math.random() , une variation sur la date, etc).

Voici une façon de le faire:

var oDate = new Date();
var sURL = "/game/getpuzzleinfo?randomSeed=" + oDate.getMilliseconds();
$.get(sURL, null, function(data, status) {
    // your work
});

Obtient sont toujours mis en cache. Une stratégie qui peut fonctionner est d'éditer l'en-tête de réponse et de dire au client de ne pas mettre les informations en cache ou d'expirer le cache très bientôt.

si vous appelez la page ashx, vous pouvez désactiver la mise en cache sur le serveur avec le code suivant:

context.Response.Cache.SetCacheability(HttpCacheability.NoCache);
context.Response.Cache.SetRevalidation(HttpCacheRevalidation.AllCaches); 

c'est ce que je fais pour les appels ajax:

var url = "/mypage.aspx";
// my other vars i want to add go here
url = url + "&sid=" + Math.random();
// make ajax call

ça marche plutôt bien pour moi.

NickFitz donne une bonne réponse, mais vous aurez besoin de désactiver la mise en cache dans IE9 ainsi. Afin de cibler seulement IE8 et IE9 vous pourriez faire ceci;

<!--[if lte IE 9]>
<script>
    $.ajaxSetup({
        cache: false
    });
</script>
<![endif]-->

les réponses ici sont très utiles pour ceux qui utilisent jQuery ou pour une raison quelconque utilisent directement l'objet xmlHttpRequest...

si vous utilisez le service proxy généré automatiquement, ce n'est pas aussi simple à résoudre.

L'astuce consiste à utiliser Sys.Net.WebRequestManager.add_invokingRequest méthode dans le gestionnaire d'événement de changement de l'url de la requête:

networkRequestEventArgs._webRequest._url = networkRequestEventArgs._webRequest._url + '&nocache=' + new Date().getMilliseconds(); 

j'ai blogué à ce sujet: http://yoavniran.wordpress.com/2010/04/27/ie-caching-ajax-results-how-to-fix /

vient D'écrire un blog sur cette question exacte en utilisant seulement ExtJS ( http://thecodeabode.blogspot.com/2010/10/cache-busting-ajax-requests-in-ie.html )

le problème était que j'utilisais un format de réécriture d'url spécifique Je ne pouvais pas utiliser les params de chaîne de requête conventionnels (?param=value), j'ai donc écrit le paramètre cache busting comme une variable postée à la place..... J'aurais pensé que l'utilisation de variables de poteau est un peu plus sûr qui obtiennent, simplement parce qu'un beaucoup de MVC cadres utilisent le modèle

protocole://serveur/controller/action/param1/param2

et ainsi le mappage du nom de la variable à la valeur est perdu, et les params sont simplement empilés... ainsi, lors de l'utilisation D'un paramètre GET cache buster

i.e. protocole://host / controller/action / param1/param2 / no_cache122300201

no_cache122300201 peut être confondu avec un paramètre $param3 qui pourrait avoir une valeur par défaut

c'est à dire

public function action ($param1, $ param2, $ param3 = " valeur par défaut") { //..// }

aucune chance que cela se produise avec des Busters de cache posté

si vous utilisez Asp.net MVC, il suffit d'ajouter cette ligne en plus de l'action du contrôleur

     [OutputCache(NoStore=true, Duration = 0, VaryByParam = "None")]
        public ActionResult getSomething()

{
}

IE est dans son droit de faire cette mise en cache; pour s'assurer que l'article n'est pas mis en cache, les en-têtes doivent être définis en conséquence.

si vous utilisez ASP.NET MVC, vous pouvez écrire un ActionFilter ; dans OnResultExecuted , cochez filterContext.HttpContext.Request.IsAjaxRequest() . Si c'est le cas, définissez l'en-tête d'expiration de la réponse: filterContext.HttpContext.Response.Expires = -1;

selon http://www.dashbay.com/2011/05/internet-explorer-caches-ajax / :

quelques personnes préfère utiliser L'en - tête Cache - Control: no-cache au lieu d'expiration. Voici la différence:

Cache-Control:no-cache absolument PAS de mise en cache

Expires: -1-le navigateur" habituellement " contacte le Serveur Web pour les mises à jour de cette page via un Si-Modified-since demande. Néanmoins, la page reste dans le cache disque et est utilisé dans les situations appropriées sans contacter la télécommande Serveur Web, comme lorsque le dos et Les boutons avant sont utilisés pour accéder à l'historique de navigation ou lorsque le navigateur est en mode hors connexion.