Les requêtes jQuery Ajax sont annulées sans être envoyées

Question

Je suis en train de brancher un script de Microsoft à l'Échelle Mondiale Télescope app. Ce dernier est à l'écoute sur le port 5050 pour les commandes. Il est en cours d'exécution sur la même machine que le navigateur (Chrome, mais aussi loin que je peux dire que le comportement est le même avec Firefox 7 et IE 9).

Je suis de l'envoi d'un "Access-Control-Allow-Origin: *" en-tête du fichier html d'origine pour tenter d'éliminer XSS restrictions mon problème.

Mon code pour accéder à WWT est comme suit:

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

url est dans ce cas "http://127.0.0.1:5050/layerApi.aspx?cmd=new et..." (évidemment ... est un raccourci ici pour quelques paramètres supplémentaires).

En regardant les diagnostics du 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 voir WWT faire un nouveau calque. Cependant, je n'ai pas de rappel. Si j'ajoute une erreur de callback qui est appelée, mais l'erreur de propriété sur le jqXHR objet est "d'erreur" et l'état est de 0. Si je regarde le réseau demande dans Chrome, je vois "(annulé)" l'état et pas de réponse.

Si je prends la même URL et la coller dans un nouvel onglet de navigateur, je peux voir que la réponse est le XML.

Bien sûr, une différence ici est que c'est un pas un POSTE, mais j'ai essayé dans mon script et il ne fait aucune différence.

Je suis assez perplexe par ce et apprécie les idées fraîches.

Answer 1

Si quelqu'un d'autre se heurte à cela, 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 de return false; .

Answer 2

Si vous utilisez Chrome, vous ne pouvez pas voir assez d'informations dans le standard Chrome panneau mise en réseau pour déterminer la cause racine de (canceled) la demande.

Vous devez utiliser chrome://net-internals/#events qui va vous montrer le détail sanglant de la demande que vous envoyez - y compris les redirections / sécurité de l'information sur les cookies envoyés etc.

par exemple, la figure suivante montre une redirection, je ne voyais pas dans le réseau de trace - causé par mes cookies ne soient pas envoyés de la croix-sous-domaine:

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)

Answer 3

J'ai eu un problème similaire. Dans mon cas, je suis en train d'utiliser un service web sur un serveur apache + django (le service a été écrit par moi-même). J'ai eu la même sortie que vous: Chrome, dit-il a été annulé alors que FF n'est-il correct. Si j'ai essayé d'accéder à ce service directement sur le navigateur au lieu de l'ajax, il marcherait aussi bien. Googler autour, j'ai trouvé que certains de nouvelles versions de apache n'étaient pas de réglage de la longueur de la réponse correctement dans les en-têtes de réponse, donc je l'ai fait manuellement. Avec django, tout ce que j'avais à faire était de:

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

Si vous avez le contrôle sur le service que vous essayez d'accéder à, savoir comment modifier l'en-tête de réponse dans la plate-forme que vous utilisez, sinon, vous devez contacter le fournisseur de service pour résoudre ce problème. Apparemment, FF et de nombreux autres navigateurs sont capables de gérer correctement cette situation, mais Chrome créateurs ont décidé de faire comme spécifié.

Answer 4

J'ai eu un problème similaire. À l'aide de chrome://net-internals/#événements auxquels j'ai pu voir que mon problème était dû à quelques silencieuse de redirection. Ma demande a été déclenché dans le onload de script. L'url est de la forme, "http://example.com/inner-path" et la 301 a été définitivement rediriger vers "/intérieure-chemin". Pour résoudre le problème j'ai juste changé l'url "/intérieure-chemin" et qui a résolu le problème. Je ne sais toujours pas pourquoi un script qui fonctionnait il y a une semaine soudain de me donner le numéro... Espérons que cela aide quelqu'un

Answer 5

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).