Qu'est-ce que cela signifie lorsqu'une requête HTTP renvoie le code d'état 0?
Qu'est-ce que cela signifie lorsque des appels réseau JavaScript tels que fetch ou XMLHttpRequest, ou tout autre type de requête réseau HTTP, échouent avec un code d'état HTTP de 0?
Cela ne semble pas être un code d'état HTTP valide, car les autres codes ont trois chiffres dans la spécification HTTP.
J'ai essayé de débrancher complètement le réseau à titre de test. Cela n’est peut-être pas lié, mais le code d’état 17003 (IIRC) en a résulté. Une recherche superficielle suggère que "la recherche du serveur DNS a échoué".
Le même code fonctionne correctement à partir de certains emplacements et systèmes, mais dans certains environnements, il échoue avec le code d'état 0 et aucun responseText n'est fourni.
Il s'agit d'un HTTP POST typique vers une URL Internet. Cela ne concerne pas le fichier: // qui, si je comprends bien, peut renvoyer 0 indiquant un succès dans Firefox.
Je crois que le code d'erreur indique que la réponse était vide (car même les en-têtes n'ont pas été retournés). Cela signifie que la connexion a été acceptée, puis fermée gracieusement (TCP FIN) . Cela pourrait être causé par un certain nombre de facteurs, mais, en vous basant sur votre description, une forme de pare-feu semble être le coupable le plus probable.
Beaucoup de réponses ici sont fausses. Il semble que les gens comprennent ce qui était à l'origine du statut == 0 dans leur cas particulier, puis généralisent cela comme solution.
Concrètement, le statut == 0 pour un XmlHttpRequest ayant échoué doit être considéré comme une erreur indéfinie.
La spécification W3C actuelle définit les conditions pour lesquelles zéro est renvoyé ici: https://fetch.spec.whatwg.org/#concept-network-error
Comme vous pouvez le constater à partir de la spécification (fetch ou XmlHttpRequest), ce code pourrait être le résultat d'une erreur survenue avant même que le serveur ne soit contacté.
Certaines des situations courantes qui produisent ce code de statut sont reflétées dans les autres réponses, mais il pourrait s'agir de l'un ou l'autre des problèmes suivants:
- Demande d'origine croisée illégale (voir CORS )
- Blocage du pare-feu ou filtrage
- La demande elle-même a été annulée dans le code
- Une extension de navigateur installée est en train de tout gâcher
Ce qui serait utile serait que les navigateurs fournissent des rapports d’erreurs détaillés pour plusieurs de ces scénarios de statut == 0. En effet, parfois le statut == 0 accompagnera un message de console utile, mais dans d'autres, il n'y a aucune autre information.
Pour ce que cela vaut, selon le navigateur, les appels AJAX basés sur jQuery appellent votre rappel de succès avec un code de statut HTTP de 0. Nous avons trouvé un code de statut de "0" qui signifie généralement que l'utilisateur est dirigé vers une page différente avant la fin de l'appel AJAX.
Pas la même technologie que vous utilisez, mais espérons utile à quelqu'un.
wininet.dll renvoie les codes d'état standard et non standard répertoriés ci-dessous.
401 - Unauthorized file
403 - Forbidden file
404 - File Not Found
500 - some inclusion or functions may missed
200 - Completed
12002 - Server timeout
12029,12030, 12031 - dropped connections (either web server or DB server)
12152 - Connection closed by server.
13030 - StatusText properties are unavailable, and a query attempt throws an exception
Pour le code de statut "zéro", essayez-vous de faire une demande sur une page Web locale exécutée sur un serveur Web ou sans serveur Web?
XMLHttpRequest status = 0 et XMLHttpRequest statusText = unknown peut vous aider si vous n'exécutez pas votre script sur un serveur Web.
Contournement: ce que nous avons fini par faire
Nous avons pensé qu'il s'agissait d'un problème de pare-feu et nous avons donc trouvé une solution de contournement qui a fait l'affaire. Si quelqu'un a le même problème, voici ce que nous avons fait:
Nous écrivons toujours les données dans un fichier texte sur le disque dur local, comme nous le faisions auparavant, en utilisant un HTA.
Lorsque l'utilisateur clique sur "renvoyer les données au serveur", le HTA lit ces données et écrit une page HTML contenant ces données sous forme d'îlot de données XML (à l'aide d'un bloc de script SCRIPT LANGU = = XML).
Le HTA lance un lien vers la page HTML dans le navigateur.
La page HTML contient maintenant le javascript qui publie les données sur le serveur (à l'aide de Microsoft.XMLHTTP).
J'espère que cela aide quelqu'un avec une exigence similaire. Dans ce cas, il s’agissait d’un jeu Flash utilisé sur un ordinateur portable lors de salons professionnels. Nous n'avons jamais eu accès à l'ordinateur portable et ne pouvions que l'envoyer par courrier électronique au client, car ce salon se déroulait dans un autre pays.
Un code de réponse HTTP de 0 indique que la demande AJAX a été annulée.
Cela peut se produire à la suite d'un délai d'attente, d'un avortement XHR ou d'un pare-feu tapant sur la requête. Un délai d'attente est commun, cela signifie que la demande n'a pas pu être exécutée dans un délai spécifié. Un avortement XHR est très simple à faire ... vous pouvez en fait appeler .abort () sur un objet XMLHttpRequest pour annuler l'appel AJAX. (C'est une bonne pratique pour une application à une seule page si vous ne voulez pas que les appels AJAX reviennent et tentent de référencer des objets qui ont été détruits.) Comme mentionné dans la réponse marquée, un pare-feu serait également capable d'annuler la demande et de déclencher cette réponse 0.
XHR Abort: Abandonner les requêtes Ajax avec jQuery
var xhr = $.ajax({
type: "POST",
url: "some.php",
data: "name=John&location=Boston",
success: function(msg){
alert( "Data Saved: " + msg );
}
});
//kill the request
xhr.abort()
Il est à noter que l'exécution de la méthode .abort () sur un objet XHR déclenchera également le rappel d'erreur. Si vous effectuez un type de traitement d'erreur qui analyse ces objets, vous remarquerez rapidement qu'un XHR interrompu et un délai d'expiration XHR sont identiques, mais avec jQuery le textStatus transmis au rappel d'erreur sera "annulé" lors d'un abandon. et "timeout" avec un timeout se produit. Si vous utilisez Zepto (très similaire à jQuery), errorType sera "error" en cas d'abandon et "timeout" en cas de dépassement du délai d'attente.
jQuery: error(jqXHR, textStatus, errorThrown);
Zepto: error(xhr, errorType, error);
Comme détaillé par cette réponse sur cette page , un code d'état de 0 signifie que la demande a échoué pour une raison quelconque, et une bibliothèque javascript a interprété l'échec comme un code d'état de 0.
Pour tester cela, vous pouvez effectuer l'une des opérations suivantes:
1) Utilisez cette extension chrome, Requestly pour rediriger votre URL de la version https de votre URL vers la version http, car cela provoquerait une erreur de sécurité du contenu mixte et générerait finalement un code d'état de 0. L'avantage de Cette approche est que vous n'avez pas du tout besoin de changer votre application et vous pouvez simplement "réécrire" votre URL en utilisant cette extension.
2) Modifiez le code de votre application pour que votre point de terminaison soit éventuellement redirigé vers la version http de votre URL au lieu de la version https (ou inversement). Si vous procédez ainsi, la demande échouera avec le code d'état 0.
Dans mon cas, le statut est devenu 0 lorsque j'ai oublié de placer le WWW devant mon domaine. Parce que toutes mes demandes ajax étaient codées en dur http: /WWW.mydomain.com et que la page Web chargée serait simplement http://mydomain.com elle est devenue un problème de sécurité parce que c'est un domaine différent. J'ai fini par faire une redirection dans mon fichier .htaccess pour toujours mettre www devant.
En plus de La réponse de Lee , vous pouvez trouver plus d'informations sur la cause réelle en basculant sur synchrone requêtes, car vous obtiendrez également une exception:
function request(url) {
var request = new XMLHttpRequest();
try {
request.open('GET', url, false);
request.send(null);
} catch (e) {
console.log(url + ': ' + e);
}
}
Par exemple :
NetworkError: une erreur de réseau s'est produite.
Dans mon cas, c’était parce que l’appel AJAX était bloqué par le navigateur en raison de la règle same-Origin . C'était la chose la moins attendue, car tous mes HTML et scripts étaient servis à partir de 127.0.0.1. Comment pourraient-ils être considérés comme ayant des origines différentes?
Quoi qu'il en soit, la cause principale était une balise <base> d'apparence innocente:
<base href='<%=request.getScheme()%>://<%=request.getServerName() + ":" + request.getServerPort() + request.getContextPath()%>/'/>
J'ai enlevé la balise <base>, dont je n'avais pas besoin en passant, et maintenant ça marche!
Si vous testez sur un PC local, cela ne fonctionnera pas. Pour tester l'exemple Ajax, vous devez placer les fichiers HTML sur un serveur Web.
Il est à noter qu'un téléchargement de fichier ajax dépassant la directive client_max_body_size pour nginx renvoie ce code d'erreur.
J'ai trouvé une raison nouvelle et non documentée pour le statut == 0. Voici ce que j'ai eu:
XMLHttpRequest.status === 0
XMLHttpRequest.readyState === 0
XMLHttpRequest.responseText === ''
XMLHttpRequest.state() === 'rejected'
Ce n'était pas d'origine croisée, réseau, ou en raison de demandes annulées (par code ou par la navigation de l'utilisateur). Rien dans la console du développeur ou le journal réseau.
Je n'ai trouvé que très peu de documentation sur state () (Mozilla ne la liste pas, pas le W3C) et rien de tout cela n'a mentionné "rejeté".
Il s'avère que c'était mon bloqueur de publicité (uBlock Origin sur Firefox).
Si quelqu'un d'autre rencontrait ce problème, cela me posait des problèmes en raison de la demande AJAX et de l'envoi d'une demande de formulaire normale. Je l'ai résolu avec la ligne suivante:
<form onsubmit="submitfunc(); return false;">
La clé est la valeur false, ce qui empêche le formulaire d'envoyer. Vous pouvez aussi simplement renvoyer false à l'intérieur de submitfunc (), mais je trouve que l'écrire explicitement est plus clair.