I parametri di JQuery Ajax a volte non vengono inviati su IE

Il problema che sto avendo è che quando uso jquery ajax post, con frequenza molto bassa (<2%), i parametri del post non arrivano mai al server. Vedo la richiesta di posta nel registro di accesso. Sembra che accada solo su IE (l'ho osservato su 7, 8 e 9 nei log).

Quando cambio la chiamata da tipo “post” a tipo “get”, il problema scompare.

Qualcun altro ha mai visto questo strano comportamento su IE? Grazie!

Ho visto questo per varie chiamate ajax, ma qui è un tipico:

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

Aggiornamento : il passaggio “cache: false” non risolve il problema.

Ho trascorso l’ultima settimana rintracciare un problema simile nella mia applicazione (usa Dojo, non JQuery). Dalla tua descrizione e frequenza di occorrenza, direi che è lo stesso problema.

Quando vengono utilizzate connessioni persistenti HTTP tra browser e server (comportamento predefinito), una connessione HTTP può essere chiusa dal server in qualsiasi momento. Questo crea un piccolo buco di temporizzazione quando il browser inizia a inviare una nuova richiesta nello stesso momento in cui il server chiude la connessione. La maggior parte dei browser utilizza una connessione diversa o apre una nuova connessione e invia nuovamente la richiesta. Questo è il comportamento suggerito nella sezione 8.1.4 della RFC 2616:


Un client, un server o un proxy POSSONO chiudere la connessione di trasporto in qualsiasi momento. Ad esempio, un cliente potrebbe aver iniziato a inviare una nuova richiesta nello stesso momento in cui il server ha deciso di chiudere la connessione “intriggers”. Dal punto di vista del server, la connessione viene chiusa mentre era intriggers, ma dal punto di vista del cliente è in corso una richiesta.

Ciò significa che client, server e proxy DEVONO essere in grado di ripristinare da eventi di chiusura asincroni. Il software client DOVREBBE riaprire la connessione di trasporto e ritrasmettere la sequenza interrotta di richieste senza l’interazione dell’utente fintanto che la sequenza della richiesta è idempotente (vedere la sezione 9.1.2).


Internet Explorer tenta di inviare nuovamente la richiesta quando ciò accade, ma quando si verifica che sia un POST, lo interrompe inviando le intestazioni (con Content-Length) ma senza dati effettivi. Questa è una richiesta malformata e dovrebbe sempre portare a un errore HTTP (di solito dopo un certo timeout in attesa di dati che non arrivano mai).

Questo bug è documentato da Microsoft come KB 895954 (consultare http://support.microsoft.com/kb/895954 ). Microsoft ha riconosciuto questo bug in IE 6. Hanno fornito un hotfix e sembra che abbia spedito l’hotfix con ogni versione di IE da allora incluso IE 9. Esistono due problemi con la correzione:

  1. L’aggiornamento rapido non è triggersto per impostazione predefinita. Devi creare una chiave davvero strana usando regedit per triggersre la correzione: HKEY_LOCAL_MACHINE \ Software \ Microsoft \ Internet Explorer \ Main \ FeatureControl \ FEATURE_SKIP_POST_RETRY_ON_INTERNETWRITEFILE_KB895954.

  2. La correzione in realtà non risolve il problema. Il comportamento “fisso” è che quando la connessione viene chiusa quando si tenta di inviare una richiesta, non tenta nemmeno di inviarla di nuovo. Passa semplicemente l’errore lungo l’applicazione javascript.

Sembra che devi aggiungere gestori di errori nel tuo codice e ripubblicare la richiesta tu stesso se fallisce. Sto cercando questa soluzione per la mia applicazione. La mia preoccupazione è che non sono sicuro di come dire se l’errore che ottengo è causato da un tentativo fallito di inviare la query, o qualche errore inviato dal server come risultato della query (nel qual caso non lo faccio voglio rispedirlo).

Ho scritto un programma C per simulare un server web e chiudere esplicitamente una connessione per vedere come il browser la gestisce. Ho scoperto che IE riproduce il comportamento errante il 100% delle volte, mentre Firefox, Safari e Chrome si ripristinano reinviando correttamente il POST su un’altra connessione il 100% delle volte. Forse la risposta è “non usare IE”.

Come risposta diretta alla tua domanda: Sì, abbiamo appena trovato questo problema e non siamo riusciti a trovare una spiegazione ragionevole. Colpisce solo IE e con una frequenza molto bassa – ci è voluto molto tempo per arrivare alla conclusione che si tratta di un jQuery Ajax sporadico nel bug di IE. Abbiamo dovuto “risolvere” il problema restituendo un errore dal server in questa condizione e ripubblicando i dati dopo un ritardo di 1 secondo!

Hacky come l’inferno, ma sembrava essere l’unico modo.

Non c’era assolutamente alcun conflitto con gli elementi DOM ecc. E nessuna ragione logica per ciò si verificava, la pagina può essere aggiornata molte volte dall’utente con successo con errori intermittenti.

Deve essere un bug

Penso che devi impedire la memorizzazione nella cache in Internet Explorer. Prova a impostare la cache delle opzioni su false.

Esempio:

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

I parametri inviati al PHP sono ricevuti da IE in GET :

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

Quindi su PHP dovresti usare REQUEST invece di POST:

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

Questo esempio potrebbe usarlo per la compatibilità con IE7