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

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

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

Когда я переключаю вызов с типа "пост", чтобы напечатать "получить", проблема исчезнет.

Кто-нибудь еще видел это странное поведение в 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" не устраняет проблему.

4b9b3361

ОТВЕТЫ

Ответ 1

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

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

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

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

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

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

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

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

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

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

Ответ 2

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

Хакки, как черт, но, казалось, был единственным способом.

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

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

Ответ 3

Я думаю, вам нужно предотвратить кеширование в Internet Explorer. Попробуйте установить кеш опций в false.

Пример:

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

Ответ 4

Параметры, отправленные на 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