Параметры сообщений JQuery Ajax иногда не отправляются в IE

Question

Проблема, с которой я столкнулся, заключается в том, что когда я использую jquery ajax post, с очень низкой частотой (<2%), параметры post никогда не попадают на сервер. Я вижу почтовый запрос в журнале доступа. Кажется, это происходит только в IE (я видел это в журналах 7, 8 и 9). </p>

Когда я переключаю вызов с типа «post» на тип «get», проблема исчезает.

Кто-нибудь еще видел такое странное поведение в IE? Спасибо!

Я видел это для различных вызовов ajax, но вот типичный:

var data= {
    "guess" : "m1",
    "eas" : "hello world"
};

$.ajax({
    url: "http://myco.com/ajaxcall.action",
    data: data,
    type : 'post',
    dataType: 'json',
    success: function(data) {},
    error: function() {}
});

Обновление : передача «cache: false» не решает проблему.

Answer 1

Я провел последнюю неделю, отслеживая аналогичную проблему в своем собственном приложении (использует Dojo, а не JQuery). Исходя из вашего описания и частоты появления, я бы сказал, что это та же проблема.

Когда постоянные соединения HTTP используются между браузером и сервером (поведение по умолчанию), соединение HTTP может быть закрыто сервером в любое время. Это создает очень маленькую временную дыру, когда браузер начинает отправлять новый запрос в то же время, когда сервер закрывает соединение. Большинство браузеров используют другое соединение или открывают новое соединение и повторно отправляют запрос. Такое поведение предлагается в разделе 8.1.4 RFC 2616:

---

Клиент, сервер или прокси МОЖЕТ закрыть транспортное соединение в любом время. Например, клиент мог начать отправлять новый запрос в то же время, что сервер решил закрыть «простоя» подключение. С точки зрения сервера, соединение закрыт, пока он простаивал, но с точки зрения клиента, запрос в процессе.

Это означает, что клиенты, серверы и прокси ДОЛЖНЫ быть в состоянии восстановить из асинхронных событий закрытия. Клиентское программное обеспечение ДОЛЖНО открыть транспортное соединение и ретранслировать прерванную последовательность запросов без взаимодействия с пользователем, пока последовательность запроса идемпотент (см. раздел 9.1.2).

---

Internet Explorer пытается повторно отправить запрос, когда это происходит, , но , когда это происходит в режиме POST, он обрабатывает его, отправляя заголовки (с Content-Length) но нет фактических данных. Это некорректный запрос, который всегда должен приводить к ошибке HTTP (обычно после некоторого времени ожидания данных, которые никогда не поступают).

Эта ошибка задокументирована Microsoft как KB 895954 (см. http://support.microsoft.com/kb/895954). Microsoft впервые распознала эту ошибку в IE 6. Они предоставили исправление и, похоже, с тех пор поставляли исправление для каждой версии IE, включая IE 9. Есть две проблемы с исправлением:

1. Исправление не активировано по умолчанию. Вам нужно создать действительно странный ключ, используя regedit для активации исправления: HKEY_LOCAL_MACHINE \ Software \ Microsoft \ Internet Explorer \ Main \ FeatureControl \ FEATURE_SKIP_POST_RETRY_ON_INTERNETWRITEFILE_KB895954.

2. Исправление не решает проблему. «Фиксированное» поведение заключается в том, что когда соединение закрывается при попытке отправить запрос, оно даже не пытается отправить его повторно. Он просто передает ошибку в приложение javascript.

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

Я написал C-программу для имитации веб-сервера и явного закрытия соединения, чтобы посмотреть, как браузер его обрабатывает. Я обнаружил, что IE воспроизводит ошибочное поведение 100% времени, в то время как Firefox, Safari и Chrome восстанавливаются путем правильной повторной отправки POST по другому соединению 100% времени. Возможно, ответ таков: «Не используйте IE».

Answer 2

Как прямой ответ на ваш вопрос: Да, мы только что столкнулись с этой проблемой и не смогли найти разумного объяснения. Это влияет только на IE и с очень низкой частотой - потребовалось много времени, чтобы прийти к выводу, что это спорадическая ошибка jQuery Ajax в IE. Нам пришлось «исправить» проблему, вернув сбой с сервера при этом условии и повторно опубликовав данные после 1-секундной задержки!

Хаки, как ад, но, казалось, единственный путь.

Определенно не было конфликта с элементами DOM и т. Д., И нет логической причины для этого, пользователь может многократно обновлять страницу с периодическими сбоями.

Должно быть, ошибка.

Answer 3

Параметры, отправляемые в PHP, принимаются от IE в GET:

$.ajax ({
     url: "path/to/ajax.php"
    ,method: "POST"
    ,data: {
         var1: "value1"
        ,var2: true
        ,varX: 123123
    }
    ,cache: false
    ,success: function (data) {
        alert (data);
    }
});

Тогда на PHP вы должны использовать REQUEST вместо POST:

$var1 = $_REQUEST ["var1"]; // value1
$var2 = $_REQUEST ["var2"]; // true
$var3 = $_REQUEST ["var3"]; // 123123

Этот пример можетиспользуйте его для совместимости с IE7

Answer 4

Я думаю, что вы должны предотвратить кэширование в Internet Explorer. Попробуйте установить для параметра cache значение false.

Пример:

$.ajax({
    url: "http://myco.com/ajaxcall.action",
    data: data,
    type : 'post',
    dataType: 'json',
    success: function(data) {},
    error: function() {},
    cache: false
});