Les requêtes jQuery Ajax sont annulées sans être envoyées
J'essaie de connecter un script à l'application World-Wide Telescope de Microsoft. Ce dernier écoute sur le port 5050 des commandes. Il fonctionne sur la même machine que le navigateur (Chrome actuellement, mais autant que je sache, le comportement est le même avec Firefox 7 et IE 9).
J'envoie un en-tête "Access-Control-Allow-Origin: *" avec le fichier html d'origine pour tenter d'éliminer les restrictions XSS en tant que problème.
Mon code pour accéder à WWT est le suivant:
$.ajax({
type: 'POST',
url: url,
data: data,
crossDomain: true,
success: success,
dataType: dataType
});
l'URL dans ce cas est "http: //127.0.0.1: 5050/layerApi.aspx? cmd = new & ..." (évidemment ... est un raccourci ici pour certains paramètres supplémentaires).
En regardant les diagnostics de réseau dans Chrome, je peux voir ceci:
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 demande est en train de sortir - je vois que WWT crée une nouvelle couche. Cependant, je ne reçois pas de rappel. Si j'ajoute un rappel d'erreur appelé, mais que la propriété error de l'objet jqXHR est simplement "error" et que le statut est 0. Si je regarde la requête réseau dans Chrome, je vois "( annulé) "en tant que statut et pas de réponse.
Si je prends cette même URL et que je la colle dans un nouvel onglet de navigateur, je peux voir que la réponse correspond au XML attendu.
Bien sûr, une différence est qu’il s’agit d’un GET et non d’un POST, mais j’ai essayé cela dans mon script et cela ne fait aucune différence.
Cela me laisse perplexe et j'apprécierais toute idée nouvelle.
Si quelqu'un d'autre se heurte à ce problème, le problème que nous avions était que nous formulions la demande ajax à partir d'un lien, sans empêcher le lien de suivre. Donc, si vous faites cela dans un attribut onclick, assurez-vous également que vous utilisez return false;.
Si vous utilisez Chrome, vous ne pouvez pas voir suffisamment d'informations dans le panneau de réseau standard Chrome pour déterminer la cause première d'un (canceled) demande.
Vous devez utiliser chrome://net-internals/#events qui vous montrera les détails sanglants de la demande que vous envoyez - y compris les redirections/informations de sécurité cachées concernant les cookies envoyés, etc.
par exemple. Ce qui suit montre une redirection que je ne voyais pas dans la trace du réseau, du fait que mes cookies n'étaient pas envoyés entre sous-domaines:
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)
Dans mon cas, j'avais type='submit' donc, lorsque je soumettais le formulaire, la page était rechargée avant que le ajax ne soit lancé, une solution simple consistait donc à avoir type="button"
type = 'submit' => type = 'bouton'
J'avais un problème similaire. Dans mon cas, j'essaie d'utiliser un service Web sur un serveur Apache + Django (le service a été écrit par moi-même). J'avais le même résultat que vous: Chrome indique qu'il a été annulé alors que FF le fait bien. Si j'essayais d'accéder au service directement sur le navigateur au lieu d'ajax, cela fonctionnerait aussi. En cherchant sur Google, j'ai découvert que certaines versions plus récentes d'Apache ne définissais pas correctement la longueur de la réponse dans les en-têtes de réponse, je l’ai donc fait manuellement. Avec Django, tout ce que je devais faire était:
response['Content-Length'] = len(content)
Si vous avez le contrôle sur le service auquel vous essayez d'accéder, découvrez comment modifier l'en-tête de la réponse sur la plate-forme que vous utilisez. Sinon, vous devrez contacter le fournisseur de services pour résoudre ce problème. Apparemment, FF et de nombreux autres navigateurs sont capables de gérer cette situation correctement, mais Chrome ont décidé de le faire comme spécifié.
J'ai eu un problème similaire. Utilisation de chrome: // net-internals/# events J'ai pu constater que mon problème était dû à une redirection silencieuse. Ma demande d'obtention était déclenchée dans un script de surcharge. L'URL était de la forme " http://example.com/inner-path " et le 301 était en cours de redirection permanente vers "/ chemin-interne". Pour résoudre le problème, je viens de changer l'URL en "/ chemin-interne" et cela a résolu le problème. Je ne sais toujours pas pourquoi un script qui a fonctionné il y a une semaine m'a soudainement posé problème ... J'espère que cela aidera quelqu'un
En développant la réponse de @ Kazetsukai, vous pouvez rencontrer ce problème si vous faites votre demande AJAX de la part de l'utilisateur en cliquant sur un lien.
Si vous configurez votre lien comme suit:
<a href="#" onclick="soAjax()">click me!</a>
Et puis un gestionnaire javascript ressemblant à ceci:
soAjax() {
$.ajax({ ... all your lovely parameters ... });
}
Pour empêcher votre navigateur de suivre le lien et d'annuler toute demande en cours, vous devez ajouter return false Ou e.preventDefault() pour empêcher l'événement click de se propager:
soAjax() {
$.ajax({ ... etc ... });
return false;
}
Ou:
soAjax(e) {
$.ajax({ ... etc ... });
e.preventDefault();
}
J'ai eu le même problème, pour moi je créais l'iframe de manière temporaire et je retirais l'iframe avant la fin de l'ajax, de sorte que le navigateur annule ma demande d'ajax.
(Utilisation de Web Forms ASP.NET)
Mon problème était que j'essayais de déclencher Ajax sur l'événement de clic d'un bouton d'envoi ayant une configuration d'événement de clic côté serveur. Je devais faire le bouton juste un bouton simple (c'est-à-dire <input type="button">)
J'ai eu cette erreur lors d'une demande en utilisant http à une URL qui nécessitait https. Je suppose que l'appel ajax ne gère pas la redirection. C'est le cas même avec l'option crossDomain ajax définie sur true (sur JQuery 1.5.2).
Il existe deux possibilités lorsque AJAX est abandonnée (si ce n’est pas la demande Cross-Origin):
- Vous n'empêchez pas le comportement par défaut de l'élément pour l'événement.
- Vous définissez un délai d'attente de AJAX trop bas ou le serveur principal du réseau/de l'application est lent.
Solution pour 1): Ajoutez return false; Ou e.preventDefault(); dans le gestionnaire d'événements.
Solution for 2): Ajoute une option de délai d'attente lors de la formation de la requête AJAX. Exemple ci-dessous.
$.ajax({
type: 'POST',
url: url,
timeout: 86400,
data: data,
success: success,
dataType: dataType
});
Pour les demandes d'origine croisée, cochez les en-têtes HTTP CORS (Cross-Origin Resource Sharing).
J'ai eu cette erreur d'une manière plus effrayante: L'onglet réseau et les événements chrome: // net-internals/# ne montraient pas la demande une fois le js terminé. Lors de la pause du js dans le message d'erreur callcack, l'onglet de réseau indiquait que la demande était (annulée). Le a toujours été appelé pour exactement une (toujours la même) de plusieurs demandes similaires dans une page Web. Après le redémarrage Chrome, l'erreur ne s'est pas reproduite!
Dans mon cas, c'était la barre oblique manquante dans l'URL. L'ajout de la barre oblique finale a résolu mon problème.
Pour Dropzone.js. Dans mon cas, cela est dû à timeout option la valeur était trop basse par défaut. Alors augmentez-le selon vos besoins.
{
// other dropzone options
timeout: 60000 * 10, // 10 minutes
...
}
J'ai eu le annulé dans Firefox. Certains appels ajax fonctionnent parfaitement pour moi, mais cela a échoué pour le collègue qui a dû l'utiliser.
Lorsque j'ai vérifié cela via les astuces Chrome mentionnées ci-dessus, je n'ai rien trouvé de suspect. Lorsque vous le vérifiez dans firebug, il affiche l'animation de "chargement" après les deux appels importants, et aucun onglet de résultat.
La solution était très simple: allez dans l'historique, trouvez le site Web, faites un clic droit -> oubliez le site Web.
Oublier, pas supprimer.
Après cela, plus de problèmes. Je suppose que cela a quelque chose à voir avec le .htaccess.
J'ai eu le même problème, mais dans mon cas, il s'agissait d'un problème de cookie. Les gars qui travaillaient sur le back-end avaient changé le chemin du cookie JSESSIONID défini lorsque nous nous connectons à notre application, et j'avais un vieux cookie portant ce nom sur mon ordinateur, mais avec l'ancien chemin. Ainsi, lorsque j'ai essayé de me connecter au navigateur (Chrome), le serveur m'a envoyé deux cookies appelés JSESSIONID, avec des valeurs différentes, ce qui l'a naturellement confondu. Il a donc annulé la demande. La suppression des cookies de mon ordinateur a corrigé le problème.
Dans mon cas, le mod-réécriture d'Apache correspondait à l'URL et redirigeait la demande vers https.
Regardez la requête en chrome: // net-internals/# events.
Il montrera un journal interne de la demande. Vérifiez les redirections.