2013-03-31 8 views
12

Chciałbym zacząć od tego. Mam dość IE. Mam poniższy kod:Żądania Ajax jquery nie działają na IE 10 (z powodu pamięci podręcznej)

$(function() { 
$("#cal").on('click', "#forward", function() { 
    $.ajax({ 
     url: "Home/Calendar?target=forward", 
     type: "GET", 
     success: function (result) { 
      $("#cal").html(result); 
     } 
    }); 
    }); 
}); 

$(function() { 
$("#cal").on('click', "#backwards", function() { 

    $.ajax({ 
     url: "Home/Calendar?target=backwards", 
     type: "GET", 
     success: function (result) { 
      $("#cal").html(result); 
     } 
    }); 
}); 
}); 

Jest to wywołanie ajax do akcji kontrolera w aplikacji C# MVC. Po prostu zmienia się miesiąc z kalendarzem, zastępując HTML. Teraz wiem, że trzeba ponownie dołączyć do zdarzenia z powodu wywołania html() i dlatego używam on() z JQuery 1.7. Użyłem również delegate(). W FF Chrome działa tak, jak powinien. W IE 10 nie. Jestem w rozterce. Wiedziałem, że IE miał problemy z delegatem w IE8 iz JQuery < 1.5, ale tak nie jest.

Czy ktoś wie, jak rozwiązać ten problem?

+0

to pomaga? http://stackoverflow.com/questions/4100872/jquery-code-not-working-in-ie?rq=1 – Axarydax

+0

nie, mam ten kod do innego pliku, który ładuję za pomocą Scripts.Render ("~ Scripts/calendarJS.js "), więc nie jest to problem z typem. Dodałem także ładunek dokumentu, ale wciąż nic nie ma. – idipous

Odpowiedz

36

Odpowiadam na to pytanie tylko dla przyszłych referencji dla innych osób. Wygląda na to, że IE buforuje żądania AJAX z jakiegoś powodu, którego nie jestem w stanie zrozumieć.

Zauważyłem, że używanie (zaskakująco dobrych) narzędzi programistycznych IE 10 zapewnia, że ​​otrzymałem 304 niezmodyfikowaną odpowiedź na moje żądania AJAX. Nie było tak w Firefoksie ani Chrome (200 było odpowiedzią).

Dodałem opcję cache: false do moich funkcji AXAJ JQuery i teraz działa zgodnie z przeznaczeniem.

IE nigdy nie przejmuje się mnie zadziwić.

+4

IE to buforujący potwór – iGanja

+0

Och, to świetny +1.':)' – Jai

+1

Dokładny problem. Dokładne rozwiązanie. Bardzo dobrze. +1 –

2

Krótki dodatek, biorąc pod uwagę, co (mało) rozumiem na ten temat. Wygląda na to, że specyfikacja XmlHttpRequest mówi, że polecenia XHR GET mogą zachowywać się jak standardowe pobieranie stron internetowych (np. Klikając na zwykłe stare łącze), a zatem polecenia XHR GET mogą być buforowane. Zespół IE zdecydował się przestrzegać tej specyfikacji, podczas gdy inni twórcy przeglądarek tego nie zrobili. Chociaż widzę pewną logikę w tym podejściu, myślę, że ci z nas, którzy codziennie pracują z żądaniami XHR, zdecydowanie powiedzieliby, że wolelibyśmy, aby buforowanie było domyślnie wyłączone, a nie włączone. (-;

0

wpadłem na to długo długo dawno temu z IE ... teraz ja zawsze sprawiają, że punkt teraz napisać moje rozmowy ajax z klucza losowego tylną parą/wartość

ja również. dodać cache: false chociaż znalazłem sam, że nie zawsze to, co powinno (no, może jej tylko IE nie robi to, co powinien)

ten sposób ustawić je ...

$('#trigger').submit(function(e){ 

    e.preventDefault(); 

    var randnum = Math.floor(Math.random()*1001); //magic starts here 

    $.ajax({ 
     type: "POST", 
     url: "folder/file.php", 
     cache: false, 
     data: "random=" + randnum, //pure magic 
     success: function(){ 
      // do stuff here 
     } 

    }); 

}); 
0

Ten problem również się pojawi. Okazuje się, że wszystkie powyższe poprawki nie zadziałają, jeśli Odpowiedź POST ma numer cache-control: max-age. Pierwsze żądanie pobierze dane, ale potem wszystkie żądania (nawet jeśli dodasz losowy atrybut) będą miały 304 dni.

W takim przypadku IE nawet nie zapyta serwera, czy treść się zmieniła, zakłada tylko, że jeśli ma numer max-age, to nie ma sensu robić żądania.

Ponadto specyfikacje XHR mówią, że 304 nie powinny przekazywać żadnych danych, więc zasadniczo otrzymujesz pustą odpowiedź na POST (tylko w IE 9 i 10).

Powiązane problemy