Le richieste jQuery Ajax vengono annullate senza essere inviate

Sto cercando di collegare uno script all'app World-Wide Telescope di Microsoft. Quest'ultimo ascolta i comandi sulla porta 5050. Funziona sulla stessa macchina del browser (Chrome in questo momento, ma per quanto posso dire il comportamento è lo stesso con Firefox 7 e IE 9).

Sto inviando un'intestazione "Access-Control-Allow-Origin: *" con il file html originale per cercare di eliminare le restrizioni XSS come problema mio.

Il mio codice per accedere a WWT è il seguente:

$.ajax({
    type: 'POST',
    url: url,
    data: data,
    crossDomain: true,
    success: success,
    dataType: dataType
});

l'url in questo caso è "http: //127.0.0.1: 5050 / layerApi.aspx? cmd = new & ..." (ovviamente ... qui è una scorciatoia per alcuni parametri aggiuntivi).

Guardando la diagnostica di rete in Chrome, posso vedere questo:

Request URL:http://127.0.0.1:5050/layerApi.aspx?cmd=new&...
Request Headersview source
Accept:application/xml, text/xml, */*; q=0.01
Content-Type:application/x-www-form-urlencoded
Origin:http://gwheeler4
Referer:http://gwheeler4/conceptconnect.html
User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/14.0.835.186 Safari/535.1

La richiesta è in uscita: vedo WWT creare un nuovo livello. Tuttavia, non ricevo una richiamata. Se aggiungo un callback di errore che viene chiamato, ma la proprietà error sull'oggetto jqXHR è solo "error" e lo stato è 0. Se guardo la richiesta di rete in Chrome vedo "(cancellato)" come stato e nessuna risposta .

Se prendo lo stesso URL e lo incollo in una nuova scheda del browser, posso vedere che la risposta è l'XML previsto.

Ovviamente, una differenza qui è che questo è un GET non un POST, ma l'ho provato nel mio script e non fa differenza.

Sono abbastanza perplesso da questo e apprezzerei qualsiasi nuova idea.

Se qualcun altro si imbatte in questo, il problema che abbiamo avuto era che stavamo facendo la richiesta ajax da un collegamento e non impedendo al collegamento di essere seguito. Quindi, se lo stai facendo in un onclickattributo, assicurati di farlo anche tu return false;.

Se utilizzi Chrome, non riesci a visualizzare informazioni sufficienti nel pannello di rete Chrome standard per determinare la causa principale di una (canceled)richiesta.

Devi usare chrome://net-internals/#events che ti mostrerà i dettagli cruenti della richiesta che stai inviando, inclusi reindirizzamenti nascosti / informazioni di sicurezza sui cookie inviati ecc.

ad esempio, il seguente mostra un reindirizzamento che non vedevo nella traccia di rete, causato dal fatto che i miei cookie non venivano inviati al sottodominio:

t=1374052796448 [st=  1]   +URL_REQUEST_START_JOB  [dt=261]
                            --> load_flags = 143540481 (DO_NOT_SAVE_COOKIES | DO_NOT_SEND_AUTH_DATA | DO_NOT_SEND_COOKIES | ENABLE_LOAD_TIMING | MAYBE_USER_GESTURE | REPORT_RAW_HEADERS | VALIDATE_CACHE | VERIFY_EV_CERT)
                            --> method = "GET"
                            --> priority = 2
                            --> url = "https://...."
...
t=1374052796708 [st=261]        HTTP_TRANSACTION_READ_RESPONSE_HEADERS
                                --> HTTP/1.1 302 Moved Temporarily
                                    Content-Type: text/html
                                    Date: Wed, 17 Jul 2013 09:19:56 GMT
...
t=1374052796709 [st=262]     +URL_REQUEST_BLOCKED_ON_DELEGATE  [dt=0]
t=1374052796709 [st=262]        CANCELLED
t=1374052796709 [st=262]   -URL_REQUEST_START_JOB
                            --> net_error = -3 (ERR_ABORTED)

Nel mio caso lo stavo facendo type='submit'quando stavo inviando il modulo la pagina si stava ricaricando prima che il tasto ajax andasse, quindi una soluzione semplice era quella di avere type="button". Se non specifichi un tipo è di submitdefault quindi devi specificarlotype="button"

type='submit' => type='button'

O

Nessun tipo => type='button'

Ho avuto un problema simile. Nel mio caso, sto cercando di utilizzare un servizio web su un server Apache + django (il servizio è stato scritto da me). Avevo lo stesso risultato di te: Chrome dice che è stato cancellato mentre FF lo fa bene. Se provassi ad accedere al servizio direttamente dal browser invece che da ajax, funzionerebbe anche lui. Cercando su Google, ho scoperto che alcune versioni più recenti di Apache non stavano impostando correttamente la lunghezza della risposta nelle intestazioni della risposta, quindi l'ho fatto manualmente. Con Django, tutto quello che dovevo fare era:

response['Content-Length'] = len(content)

Se hai il controllo sul servizio a cui stai tentando di accedere, scopri come modificare l'intestazione della risposta nella piattaforma che stai utilizzando, altrimenti dovresti contattare il fornitore del servizio per risolvere il problema. Apparentemente, FF e molti altri browser sono in grado di gestire correttamente questa situazione, ma i progettisti di Chrome hanno deciso di farlo come specificato.

Ho avuto un problema simile. Utilizzando chrome: // net-internals / # events sono stato in grado di vedere che il mio problema era dovuto a un reindirizzamento silenzioso. La mia richiesta di get è stata licenziata in uno script onload. L'URL era nel formato " http://example.com/inner-path " e il 301 reindirizzava in modo permanente a "/ inner-path". Per risolvere il problema ho appena cambiato l'URL in "/ inner-path" e questo ha risolto il problema. Ancora non so perché una sceneggiatura che ha funzionato una settimana fa mi abbia improvvisamente dato problemi ... Spero che questo aiuti qualcuno

(Utilizzo di Web Form ASP.NET)

Il mio problema era che stavo cercando di attivare Ajax dall'evento clic di un pulsante di invio che aveva una configurazione dell'evento clic lato server. Ho dovuto rendere il pulsante solo un semplice pulsante (cioè <input type="button">)

Ho avuto lo stesso problema, per me stavo creando l'iframe per un modo temporaneo e stavo rimuovendo l'iframe prima che l'ajax diventasse completo, quindi il browser avrebbe annullato la mia richiesta ajax.

Espandendo la risposta di @ Kazetsukai, potresti incorrere in questo problema se stai effettuando la tua richiesta AJAX dall'utente facendo clic su un collegamento.

Se imposti il ​​tuo collegamento in questo modo:

<a href="#" onclick="soAjax()">click me!</a>

E poi un gestore javascript come il seguente:

soAjax() {
    $.ajax({ ... all your lovely parameters ... });       
}

Per impedire al browser di seguire il collegamento e annullare eventuali richieste in corso, è necessario aggiungere return falseo e.preventDefault()interrompere la propagazione dell'evento clic:

soAjax() {
   $.ajax({ ... etc ... });
   return false;
}

O:

soAjax(e) {
   $.ajax({ ... etc ... });
   e.preventDefault();
}

Ci sono due possibilità quando la richiesta AJAX viene rilasciata (se non la richiesta Cross-Origin):

1. Non stai impedendo il comportamento predefinito dell'elemento per l'evento.
2. Hai impostato il timeout di AJAX su un valore troppo basso o il server di backend dell'applicazione / della rete è lento.

Soluzione per 1) : aggiungi return false;oe.preventDefault(); nel gestore eventi.

Soluzione per 2) : aggiungere l'opzione timeout durante la formazione della richiesta AJAX. Esempio sotto.

$.ajax({
    type: 'POST',
    url: url,
    timeout: 86400,
    data: data,
    success: success,
    dataType: dataType
});

Per le richieste cross-origin, controlla le intestazioni HTTP Cross-Origin Resource Sharing (CORS).

Ho ricevuto questo errore quando ho effettuato una richiesta utilizzando http a un URL che richiede https. Immagino che la chiamata ajax non stia gestendo il reindirizzamento. Questo è il caso anche con l'opzione crossDomain ajax impostata su true (su JQuery 1.5.2).

Nel mio caso, la riscrittura del mod di Apache corrispondeva all'URL e reindirizzava la richiesta a https.

Guarda la richiesta in chrome: // net-internals / # events.

Mostrerà un registro interno della richiesta. Verifica la presenza di reindirizzamenti.

Ho avuto lo stesso problema, ma nel mio caso si è rivelato essere un problema con i cookie. I ragazzi che lavoravano sul back-end avevano cambiato il percorso del cookie JSESSIONID impostato quando accediamo alla nostra app, e avevo un vecchio cookie con quel nome sul mio computer, ma con il vecchio percorso. Quindi quando ho provato ad accedere al browser (Chrome) ho inviato due cookie chiamati JSESSIONID, con valori diversi, al server - che comprensibilmente lo ha confuso - quindi ha annullato la richiesta. L'eliminazione dei cookie dal mio computer ha risolto il problema.

Ho riscontrato questo errore in un modo più inquietante: la scheda di rete e gli eventi chrome: // net-internals / # non mostravano la richiesta dopo il completamento di js. Quando si mette in pausa il js nel callcack di errore, la scheda di rete mostrava la richiesta come (annullata). È stato costantemente richiesto esattamente una (sempre la stessa) di diverse richieste simili in una pagina web. Dopo aver riavviato Chrome l'errore non si è ripresentato!

Ho avuto l' annullamento in Firefox . Alcune chiamate ajax funzionavano perfettamente per me, ma non sono riuscite per il collega che in realtà ha dovuto usarle.

Quando l'ho verificato tramite i trucchi di Chrome sopra menzionati, non ho trovato nulla di sospetto. Durante il controllo in Firebug, mostrava l'animazione di "caricamento" dopo le due chiamate malliche e nessuna scheda dei risultati.

La soluzione era semplicissima: vai alla cronologia, trova il sito Web, fai clic con il pulsante destro del mouse -> dimentica il sito Web.
Dimentica, non eliminare.

Dopodiché, nessun problema più. La mia ipotesi è che abbia qualcosa a che fare con .htaccess.

Nel mio caso, era la barra finale mancante nell'URL. L'aggiunta della barra finale ha risolto il mio problema.

Per il caso Dropzone.js. Nel mio caso è stato causato perché il valore timeoutdell'opzione era troppo basso per impostazione predefinita. Quindi aumentalo in base alle tue esigenze.

{
// other dropzone options
timeout: 60000 * 10, // 10 minutes
...
}

Ho avuto questo problema con una particolare rete 3G.
Fallirebbe sempre sulle richieste DELETE con net_error = -101in chrome: // net-internals / # events.

Altre reti hanno funzionato bene, quindi presumo che ci fosse un server proxy difettoso o qualcosa del genere.