Подтвердить что ты не робот

JQuery Ajax просит не работать над IE 10 (из-за кеша)

Я хотел бы начать с этого. Я устал от IE. У меня есть код ниже:

$(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);
        }
    });
});
});

Это вызов ajax для действия контроллера в приложении С# MVC. Он просто идет назад и вперед через календарные месяцы, заменяя html. Теперь я знаю, что вам нужно повторно связать событие из-за вызова html(), и именно поэтому я использую on() с JQuery 1.7. Я использовал delegate(). В FF Chrome он работает по назначению. В IE 10 это не так. Я в недоумении. Я знал, что IE имеет проблемы с делегатом в IE8 и с JQuery < 1.5, но это не так.

Кто-нибудь знает, как это решить?

4b9b3361

Ответ 1

Я отвечаю на вопрос только для будущей справки для других людей. Кажется, что IE кэширует запросы AJAX по какой-то причине, которые я не могу понять.

Я заметил, что с помощью (удивительно хороших) инструментов разработчика IE 10 обеспечивает, что я получал 304 не измененный ответ на мои запросы AJAX. Это было не так в Firefox или Chrome (ответ был 200).

Я добавил параметр cache: false для своих функций AXAJ JQuery, и теперь он работает по назначению.

IE никогда не улавливает меня.

Ответ 2

Краткое дополнение, учитывая, что (мало) я понимаю по этому вопросу. По-видимому, спецификация XmlHttpRequest говорит, что команды XHR GET могут вести себя точно так же, как поиск стандартной веб-страницы (например, щелчок по обычной старой ссылке), и поэтому команды XHR GET могут кэшироваться. Команда IE решила придерживаться этой спецификации, в то время как другие производители браузеров этого не сделали. Хотя я вижу некоторую логику в этом подходе, я думаю, что те из нас, кто ежедневно работает с XHR-запросами, решительно скажут, что мы предпочли бы, чтобы кеширование было отключено по умолчанию, а не на. (-;

Ответ 3

Я долгое время сталкивался с этим вопросом с IE... теперь я всегда заставляю сейчас писать мои вызовы ajax со случайной парой ключ/значение пары.

Я также добавляю cache: false, хотя я нашел сам по себе, он не всегда делает то, что должен (ну, может быть, его просто IE не делает, что он должен)

Вот как я их установил...

$('#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
        }

    }); 

});

Ответ 4

У вас тоже есть эта проблема. Оказывается, что все исправления выше не будут работать, если ответ POST имеет cache-control: max-age. Первый запрос будет извлекать данные, но после этого все запросы (даже если вы добавите случайный атрибут) будут 304'd.

В этом случае IE даже не спросит сервер, изменился ли контент, он просто предполагает, что если он имеет max-age, тогда нет смысла делать запрос.

Более того, спецификации XHR говорят, что 304 не должны передавать какие-либо данные, поэтому в основном вы получаете пустой ответ для POST (только на IE 9 и 10).