Perché Internet Explorer non invia il corpo del messaggio HTTP sulla chiamata Ajax dopo un errore?

Siamo in grado di ricreare in modo affidabile il seguente scenario:

1. Crea una piccola pagina HTML che invia richieste AJAX a un server (utilizzando HTTP POST)
2. Disconnettiti dalla rete e ricollegati
3. Monitorare i pacchetti generati da IE dopo l'errore

Dopo una connessione di rete fallita, IE effettua la successiva richiesta AJAX ma invia solo l' intestazione HTTP (non il corpo) quando esegue il post HTTP. Ciò causa tutti i tipi di problemi sul server poiché è solo una richiesta parziale. Cerca questo problema con Bing su Google e troverai molte persone che si lamentano di "errori casuali del server" utilizzando AJAX o errori AJAX inspiegabili.

Sappiamo che IE (a differenza della maggior parte degli altri browser) invia sempre un HTTP POST come DUE pacchetti TCP / IP. L'intestazione e il corpo vengono inviati separatamente. Nel caso subito dopo un errore, IE invia solo l'intestazione . IE non invia mai il payload e il server alla fine risponde con un timeout.

Quindi la mia domanda è: perché si comporta in questo modo? Sembra sbagliato in base alle specifiche HTTP e altri browser non si comportano in questo modo. È semplicemente un bug? Sicuramente questo crea scompiglio in qualsiasi applicazione Web basata su AJAX seria.

Informazioni di riferimento:

Esiste un problema simile, attivato da timeout keep-alive HTTP inferiori a 1 minuto ed è documentato qui:

http://us.generation-nt.com/xmlhttprequest-post-sometimes-fails-when-server-using-keep-aliv-help-188813541.html

http://support.microsoft.com/default.aspx?kbid=831167

Non sembra esserci una risposta chiara a questa domanda, quindi fornirò i miei dati empirici come sostituto e fornirò alcuni modi per aggirarli. Forse un giorno qualche membro della SM farà luce su questo ...

1. Se HTTP Keep-Alive è disabilitato sul server, il problema scompare. In altre parole, il tuo server HTTP 1.1 risponderà a ogni richiesta Ajax con una Connection: Closeriga nella risposta. Ciò mantiene IE felice ma fa sì che ogni richiesta Ajax apra una nuova connessione. Ciò può avere un impatto significativo sulle prestazioni, soprattutto su reti ad alta latenza.

2. Il problema viene attivato facilmente se le richieste Ajax vengono effettuate in rapida successione. Ad esempio, facciamo richieste Ajax ogni 100 ms e poi lo stato della rete cambia, l'errore è facile da riprodurre. Sebbene la maggior parte delle applicazioni probabilmente non effettua tali richieste, potresti avere un paio di chiamate al server che si verificano una dopo l'altra, il che potrebbe portare a questo problema. Meno loquace rende IE felice.

3. Succede anche senza l'autenticazione NTLM.

4. Si verifica quando il timeout keep-alive HTTP sul server è più breve del valore predefinito (che è di 60 secondi su Windows). Dettagli forniti nel link in questione.

5. Non succede con Chrome o Firefox. FF invia un pacchetto quindi sembra evitare del tutto questo problema.

6. Succede in IE 6, 7, 8. Impossibile riprodurre con IE 9 beta.

L'articolo della KB di Microsoft intitolato Quando si utilizza Microsoft Internet Explorer o un altro programma per eseguire un'operazione di ripetizione POST, solo i dati di intestazione vengono inseriti sembra risolvere questo problema.

L'articolo fornisce un hotfix. Per i browser successivi, come IE8, si dice che l'hotfix è già incluso ma deve essere abilitato tramite le impostazioni del registro sul PC client.

Ho avuto un problema simile in cui alcune versioni precedenti di IE restituivano solo l'header e non il corpo di un POST. Il mio problema si è rivelato correlato a IE e NTLM. Dal momento che non hai menzionato NTLM, questo probabilmente non aiuta, ma per ogni evenienza:

http://support.microsoft.com/kb/251404

Questo è un tentativo lungo, ma IE (e anche Firefox) a volte "ricorda" la connessione che usa per una richiesta HTTP. Note / esempi:

• In Firefox, se cambio le impostazioni del proxy e premo SHIFT-RELOAD su una pagina, utilizza ancora il vecchio proxy. Tuttavia, se uccido il vecchio proxy ("killall squid"), inizia a utilizzare il nuovo proxy.

• Quando ti disconnetti / riconnetti, ricevi un nuovo indirizzo IP o qualcosa di simile? Puoi in qualche modo monitorare il vecchio indirizzo IP per vedere se IE sta inviando dati a quell'indirizzo ormai morto?

• La mia ipotesi è che IE stia inviando i dati, seguendo il percorso sbagliato. Potrebbe essere abbastanza intelligente da non memorizzare nella cache le connessioni di rete per i pacchetti "POST", ma potrebbe non essere abbastanza intelligente da farlo per i payload POST.

• Questo probabilmente non influisce sulla maggior parte delle app AJAX, poiché le persone raramente si disconnettono e si ricollegano alle loro reti?

Stai utilizzando l'autenticazione NTLM?

Quando si utilizza l'autenticazione NTLM, IE non invia dati post. Invia le informazioni di intestazione, si aspetta un'autorizzazione per l'invio di una risposta non autorizzata e dopo la "nuova autenticazione" invia il messaggio.

Oggi ho riscontrato un problema simile durante l'utilizzo di $ .ajax e sono riuscito a risolverlo impostando async su false.

$.ajax({
  async: false, 
  url: '[post action url]',
  data: $form.serialize(),
  type: 'POST',
  success: successCallback
});