Nieoczekiwane buforowanie AJAX skutkuje w IE8

Mam poważny problem z wynikami buforowania Internet Explorera z żądania JQuery Ajax.

Mam nagłówek na mojej stronie internetowej, który jest aktualizowany za każdym razem, gdy użytkownik przechodzi do nowej strony. Robię to po załadowaniu strony

$.get("/game/getpuzzleinfo", null, function(data, status) {
    var content = "<h1>Wikipedia Maze</h1>";
    content += "<p class='endtopic'>Looking for <span><a title='Opens the topic you are looking for in a separate tab or window' href='" + data.EndTopicUrl + "' target='_blank'>" + data.EndTopic + "<a/></span></p>";
    content += "<p class='step'>Step <span>" + data.StepCount + "</span></p>";
    content += "<p class='level'>Level <span>" + data.PuzzleLevel.toString() + "</span></p>";
    content += "<p class='startover'><a href='/game/start/" + data.PuzzleId.toString() + "'>Start Over</a></p>";

    $("#wikiheader").append(content);

}, "json");

Po prostu wstrzykuje informacje nagłówka na stronę. Możesz to sprawdzić, wchodząc na www.wikipediamaze.com, a następnie logując się i rozpoczynając nową łamigłówkę.

W każdej testowanej przeze mnie przeglądarce (Google Chrome, Firefox, Safari, Internet Explorer) działa świetnie poza IE. Wszystko zostaje dobrze wstrzyknięte w IE za pierwszym razem, ale potem już nigdy nie wykonuje wywołania /game/getpuzzleinfo. To tak, jakby zapisał wyniki w pamięci podręcznej lub coś takiego.

Jeśli zmienię połączenie na $.post("/game/getpuzzleinfo", ...IE, odbierze je dobrze. Ale potem Firefox przestaje działać.

Czy ktoś może rzucić trochę światła na to, dlaczego IE buforuje moje $.getwywołania Ajax?

AKTUALIZACJA

Zgodnie z poniższą sugestią zmieniłem moje żądanie Ajax na to, co rozwiązało mój problem:

$.ajax({
    type: "GET",
    url: "/game/getpuzzleinfo",
    dataType: "json",
    cache: false,
    success: function(data) { ... }
});

IE jest znany z agresywnego buforowania odpowiedzi Ajax. Ponieważ używasz jQuery, możesz ustawić opcję globalną:

$.ajaxSetup({
    cache: false
});

co spowoduje, że jQuery doda losową wartość do ciągu zapytania żądania, uniemożliwiając w ten sposób IE buforowanie odpowiedzi.

Zauważ, że jeśli masz inne wywołania Ajax w miejscu, w którym chcesz buforować, spowoduje to również wyłączenie go dla nich. W takim przypadku przełącz się na metodę $ .ajax () i włącz tę opcję jawnie dla niezbędnych żądań.

Więcej informacji można znaleźć pod adresem http://docs.jquery.com/Ajax/jQuery.ajaxSetup .

Jak wspomniano w marr75 , plikiGET są buforowane.

Jest kilka sposobów, aby temu zaradzić. Oprócz modyfikowania nagłówka odpowiedzi można również dołączyć losowo wygenerowaną zmienną ciągu zapytania na koniec docelowego adresu URL. W ten sposób IE będzie myśleć, że jest to inny adres URL za każdym razem, gdy zostanie o to poproszony.

Można to zrobić na wiele sposobów (np. Przez użycie Math.random(), zmiana daty itp.).

Oto jeden sposób, w jaki możesz to zrobić:

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

Pobiera są zawsze buforowalne. Jedną ze strategii, która może zadziałać, jest edycja nagłówka odpowiedzi i poinformowanie klienta, aby nie buforował informacji lub aby wkrótce wygaśnął pamięć podręczną.

Jeśli wywołujesz stronę ashx, możesz również wyłączyć cache na serwerze za pomocą następującego kodu:

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

oto co robię dla wywołań Ajax:

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

na mnie działa całkiem nieźle.

NickFitz daje dobrą odpowiedź, ale musisz też wyłączyć buforowanie w IE9. Aby kierować tylko na IE8 i IE9, możesz to zrobić;

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

Odpowiedzi tutaj są bardzo pomocne dla tych, którzy używają jQuery lub z jakiegoś powodu bezpośrednio używają obiektu xmlHttpRequest ...

Jeśli korzystasz z automatycznie generowanego serwera proxy usługi Microsoft, nie jest to tak proste do rozwiązania.

Sztuczka polega na użyciu metody Sys.Net.WebRequestManager.add_invokingRequest w obsłudze zdarzeń, aby zmienić adres URL żądania:

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

Pisałem o tym na blogu: http://yoavniran.wordpress.com/2010/04/27/ie-caching-ajax-results-how-to-fix/

Właśnie napisałem bloga na ten temat, używając tylko ExtJS ( http://thecodeabode.blogspot.com/2010/10/cache-busting-ajax-requests-in-ie.html )

Problem polegał na tym, że korzystałem z określonego formatu przepisywania adresu URL i nie mogłem użyć konwencjonalnych parametrów ciągu zapytania (? Param = wartość), więc zamiast tego napisałem parametr usuwania pamięci podręcznej jako opublikowaną zmienną ..... pomyślałbym że używanie zmiennych POST jest nieco bezpieczniejsze niż GET, po prostu dlatego, że wiele frameworków MVC używa tego wzorca

protokół: // host / kontroler / akcja / param1 / param2

a więc mapowanie nazwy zmiennej do wartości jest tracone, a parametry są po prostu układane w stosy ... więc przy użyciu parametru do pomijania pamięci podręcznej GET

tj. protokół: // host / kontroler / akcja / param1 / param2 / no_cache122300201

no_cache122300201 można pomylić z parametrem $ param3, który może mieć wartość domyślną

to znaczy

akcja funkcji publicznej ($ param1, $ param2, $ param3 = "wartość domyślna") {//..//}

nie ma szans, aby tak się stało w przypadku POSTED busterów pamięci podręcznej

Jeśli korzystasz z ASP.NET MVC, wystarczy dodać ten wiersz na górze akcji kontrolera:

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

}

IE ma prawo do tego buforowania; aby upewnić się, że element nie jest buforowany, nagłówki powinny być odpowiednio ustawione.

Jeśli używasz ASP.NET MVC, możesz napisać ActionFilter; w OnResultExecuted, sprawdź filterContext.HttpContext.Request.IsAjaxRequest(). Jeśli tak, ustaw nagłówek expire odpowiedzi:filterContext.HttpContext.Response.Expires = -1;

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

Niektórzy wolą używać nagłówka Cache - Control: no - cache zamiast expires. Oto różnica:
Cache-Control: no-cache - absolutnie BEZ buforowania
Wygasa: -1 - przeglądarka „zwykle” kontaktuje się z serwerem WWW w celu aktualizacji tej strony za pośrednictwem warunkowego żądania If-Modified-Since. Jednak strona pozostaje w pamięci podręcznej dysku i jest używana w odpowiednich sytuacjach bez kontaktowania się ze zdalnym serwerem WWW, na przykład gdy przyciski WSTECZ i DO PRZODU służą do uzyskiwania dostępu do historii nawigacji lub gdy przeglądarka jest w trybie offline.