Réponses:
Un autre cas:
Il peut être possible d'obtenir un code d'état indiquant 0
si vous avez envoyé un appel AJAX et qu'une actualisation du navigateur a été déclenchée avant d'obtenir la réponse AJAX . L'appel AJAX sera annulé et vous obtiendrez ce statut.
<form onsubmit="return false;">
e.preventDefault();
D'après mon expérience, vous verrez un statut de 0 lorsque:
Même problème ici lors de l'utilisation <button onclick="">submit</button>
. Puis résolu en utilisant<input type="button" onclick="">
Le code d'état 0 signifie que l'URL demandée n'est pas accessible. En changeant http: // quelque chose / quelque chose en https: // quelque chose / quelque chose a fonctionné pour moi. IE jette une erreur indiquant "permission refusée" lorsque le code d'état est 0, les autres navigateurs ne le font pas.
Cet article m'a aidé. J'étais en train de soumettre le formulaire via AJAX et j'ai oublié de l'utiliser return false
(après ma demande ajax), ce qui a conduit à la soumission d'un formulaire classique mais étrangement, il n'a pas été complété.
<form onsubmit="return false;">
a fait l'affaire.
Parce que cela apparaît lorsque vous google ajax status 0 Je voulais laisser un conseil qui m'a juste pris des heures de temps perdu ... J'utilisais ajax pour appeler un service PHP qui se trouvait être le REST_Controller de Phil pour Codeigniter (je ne sais pas si cela a quoi que ce soit à voir avec ou non) et a continué à obtenir le statut 0, à réinstaller 0 et cela me rendait fou. J'étais en train de le déboguer et j'ai remarqué que lorsque j'échouais et retournais au lieu de quitter le message, j'obtiendrais un succès. Enfin, j'ai désactivé le débogage et essayé et cela a fonctionné. Il semble que le débogueur xDebug avec PHP modifiait en quelque sorte la réponse. Si vous utilisez un débogueur PHP, essayez de le désactiver pour voir si cela vous aide.
J'ai trouvé un autre cas où jquery vous donne le code de statut 0 - si pour une raison quelconque XMLHttpRequest n'est pas défini, vous obtiendrez cette erreur.
Évidemment, cela ne se produira normalement pas sur le Web, mais un bogue dans une version nocturne de Firefox l'a fait apparaître dans un add-on que j'écrivais. :)
jQuery.ajax()
objet XHR. La demande n'a même pas été créée lors de l'appel AJAX, toujours obtenir f.open n'est pas une fonction et le code d'état 0. Causé par: Je retournais l' $.ajaxSettings.xhr
objet de $.ajaxSetup({xhr})
, retournant à la new window.XMLHttpRequest();
place résolu le problème
J'ai eu le même problème, et il était lié au blocage XSS (cross site scripting) par le navigateur. J'ai réussi à le faire fonctionner en utilisant un serveur.
Jetez un œil à: http://www.daniweb.com/web-development/javascript-dhtml-ajax/threads/282972/why-am-i-getting-xmlhttprequest.status0
La soumission de formulaire «accidentelle» était exactement le problème que j'avais. Je viens de supprimer complètement les balises FORM et cela semble résoudre le problème. Merci tout le monde!
Nous avons eu un problème similaire - code d'état 0 sur l'appel jquery ajax - et il nous a fallu une journée entière pour le diagnostiquer. Puisque personne n'avait encore mentionné cette raison, j'ai pensé partager.
Dans notre cas, le problème était un crash du serveur HTTP. Un bogue en PHP soufflait Apache, donc du côté du client, cela ressemblait à ceci:
mirek@toccata:~$ telnet our.server.com 80
Trying 180.153.xxx.xxx...
Connected to our.server.com.
Escape character is '^]'.
GET /test.php HTTP/1.0
Host: our.server.com
Connection closed by foreign host.
mirek@toccata:~$
où test.php contenait le code de plantage. Aucune donnée renvoyée par le serveur (pas même les en-têtes) => l'appel ajax a été abandonné avec l'état 0.
Dans mon cas, cela a été causé par l'exécution de mon serveur django sous http://127.0.0.1:8000/
mais l'envoi de l'appel ajax à http://localhost:8000/
. Même si vous vous attendez à ce qu'ils soient mappés à la même adresse, ils ne s'assurent pas que vous n'envoyez pas vos demandes à localhost.
Dans notre cas, le lien de la page est passé de https à http . Même si les utilisateurs étaient connectés, ils n'ont pas pu se charger avec AJAX.
Pour moi, le problème a été causé par la société d'hébergement (Godaddy) traitant les opérations POST qui avaient des données de réponse substantielles (plus de dizaines de kilo-octets) comme une sorte de menace pour la sécurité. Si plus de 6 d'entre eux se sont produits en une minute, l'hôte a refusé d'exécuter le code PHP qui a répondu à la requête POST pendant la minute suivante. Je ne suis pas tout à fait sûr de ce que l'hôte a fait à la place, mais j'ai vu, avec tcpdump, un paquet de réinitialisation TCP en réponse à une demande POST du navigateur. Cela faisait que le code d'état http renvoyé dans un objet jqXHR était 0.
La modification des opérations de POST à GET a résolu le problème. On ne sait pas pourquoi Godaddy impose cette limite, mais changer le code était plus facile que de changer l'hôte.
Je pense que je sais ce qui peut causer cette erreur.
Dans google chrome, il existe une fonctionnalité intégrée pour empêcher les attaques ddos pour les extensions google chrome.
Lorsque les demandes ajax renvoient continuellement plus de 500 erreurs d'état, elles commencent à limiter les demandes.
Par conséquent, il est possible de recevoir le statut 0 sur les demandes suivantes.
Dans une tentative de gagner le prix pour la raison la plus stupide du problème décrit.
Oublier d'appeler
xmlhttp.send(); //yes, you need this pivotal line!
Oui, j'obtenais toujours des retours de statut de zéro de l'appel «ouvert».
Dans mon cas, je l'obtenais mais uniquement sur Safari Mobile. Le problème est que j'utilisais l'URL complète ( http://example.com/wwhat.php ) au lieu de l' URL relative (peu importe.php). Cela n'a aucun sens, cela ne peut pas être un problème XSS car mon site est hébergé sur http://example.com . Je suppose que Safari regarde la partie http et la marque automatiquement comme une demande non sécurisée sans inspecter le reste de l'URL.
Dans mon dépannage, j'ai trouvé que ce AJAX xmlhttpRequest.status == 0 pouvait signifier que l'appel client n'avait pas encore atteint le serveur, mais avait échoué en raison d'un problème côté client. Si la réponse provenait du serveur, l'état doit être l'un des codes de réponse HTTP 1xx / 2xx / 3xx / 4xx / 5xx. Désormais, le dépannage se concentrera sur le problème du CLIENT et pourrait être une connexion réseau Internet interrompue ou l'un de ceux décrits par @Langdon ci-dessus.
Observez la console du navigateur tout en effectuant la demande, si vous voyez "La même politique d'origine interdit la lecture de la ressource distante sur http ajax ..... raison: l'en-tête cors 'access-control-allow-origin' est manquant", vous devez ajoutez "Access-Control-Allow-Origin" dans l'en-tête de réponse. exa: en java, vous pouvez définir ceci comme response.setHeader ("Access-Control-Allow-Origin", "*") où la réponse est HttpServletResponse.