Code D'état HTTP 0-qu'est-ce que cela signifie pour fetch, ou XMLHttpRequest?
en ce qui concerne le code de retour 0 pour les appels réseau JavaScript fetch, XMLHttpRequest et MS XMLHTTP, j'ai un HTA (Microsoft HTML application - offline HTML + JavaScript application) qui utilise L'objet COM standard MS XMLHTTP ( Microsoft.XMLHTTP
ou Msxml2.XMLHTTP
selon la version détectée) via le code JavaScript pour renvoyer certaines données au serveur.
il retourne le code de statut 0. Ce n'est apparemment pas valide, code d'état HTTP (ils doivent être trois chiffres selon les spécifications officielles). (BTW, j'ai essayé de débrancher la connexion réseau et j'ai eu le code d'état 17003 ou quelque chose comme ça, ce qui je pense que d'après beaucoup de googling signifie "échec de la recherche sur le serveur DNS".)
cela fonctionne très bien pour moi et d'autres personnes qui l'ont testé à différents endroits. Cependant, j'ai envoyé ceci au client et il a reçu un code D'état HTTP de zéro, et la réponse HTTP est vide. Le client l'a essayé à deux endroits, mais tant au sein de leur réseau d'entreprise.
il s'agit d'un message HTTP vers une URL HTTP sur Internet (PAS un fichier:// requête qui, je crois comprendre, retournerait aussi le code d'état 0 pour le succès sous Mozilla). Je suis presque sûr que c'est un code d'échec car il devrait retourner une certaine confirmation comme le responseText
, et nous ne recevons pas les données enregistrées dans la base de données.
13 réponses
je crois que le code d'erreur indique que la réponse était vide (même les en-têtes n'ont pas été retournés). Cela signifie que la connexion a été acceptée puis fermée avec élégance (TCP FIN). Il y a un certain nombre de choses qui pourraient causer cela, mais d'après votre description, une forme de pare-feu semble être le coupable le plus probable.
Beaucoup de réponses ici sont faux. il semble que les gens comprennent ce qui causait le statut==0 dans leur cas particulier et puis de généraliser que la réponse.
pratiquement parlant, l'état==0 pour un échec XmlHttpRequest devrait être considéré comme une erreur non définie.
la spécification W3C actuelle définit les conditions pour lesquelles Zéro est retourné ici: https://fetch.spec.whatwg.org/#concept-network-error
comme vous pouvez le voir à partir de la spécification (fetch ou XmlHttpRequest) ce code pourrait être le résultat d'une erreur qui s'est produite même avant que le serveur 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 de l'autre de ces problèmes:
- demande D'origine croisée illégale (voir CORS )
- Pare-feu bloquer ou de filtrage
- la requête elle-même a été annulée sous le code
- installé Une extension de navigateur qui est de déblayage les choses
ce qui serait utile serait que les navigateurs fournissent des rapports d'erreur détaillés pour plus de ces scénarios d'état==0. En effet, parfois l'état = = 0 accompagnera un message de console utile, mais dans d'autres il n'y a pas d'autres informations.
pour ce que ça vaut, selon le navigateur, les appels AJAX basés sur jQuery appelleront votre succès avec un code de statut HTTP de 0. Nous avons trouvé un code d'état de "0" signifie habituellement que l'utilisateur navigue vers une page différente avant que L'appel AJAX ne soit terminé.
pas la même pile de technologie que vous utilisez, mais avec un peu de chance utile à quelqu'un.
wininet.dll
renvoie les codes de statut standard et non standard énuméré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 d'état "zéro" essayez-vous de faire une requête sur une page Web locale fonctionnant sur un serveur web ou sans serveur web?
XMLHttpRequest status = 0 et XMLHttpRequest statusText = inconnu peut vous aider si vous n'êtes pas l'exécution de votre script sur un serveur web.
Solution: ce que nous avons fini par faire
nous avons pensé que c'était à cause des problèmes de pare-feu, alors nous avons trouvé une solution qui a fait l'affaire. Si quelqu'un a ce même problème, voici ce que nous avons fait:
-
nous écrivons toujours les données à un fichier texte sur le disque dur local comme nous l'avons fait précédemment, en utilisant un HTA.
-
Lorsque l'utilisateur clique sur "envoyer des données vers serveur", le HTA lit dans les données et écrit une page HTML qui inclut ces données comme une île de données XML (en fait en utilisant un langage de SCRIPT=bloc de script XML).
-
le HTA lance un lien vers la page HTML du navigateur.
-
la page HTML contient maintenant le javascript qui affiche les données sur le serveur (en utilisant Microsoft.XMLHTTP).
Espérons que cette aide toute personne ayant 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 nous ne pouvions l'envoyer qu'au client par courriel, car ce salon se déroulait dans un autre pays.
un code de réponse HTTP de 0 indique que la requête AJAX a été annulée.
cela peut se produire soit à partir d'un timeout, avortement XHR ou un piétinement pare-feu sur la demande. Un timeout est commun, cela signifie que la requête n'a pas été exécutée dans un délai spécifié. Un avortement XHR est très simple à faire... vous pouvez réellement appeler .abort() sur un objet XMLHttpRequest pour annuler L'appel AJAX. ( C'est une bonne pratique pour une application d'une seule page si vous ne voulez pas Appels AJAX qui renvoient et tentent de référencer des objets qui ont été détruits. ) tel que mentionné dans la réponse marquée, un pare-feu serait également capable d'annuler la requête et de déclencher cette réponse 0.
XHR Abandonner: Abort requêtes Ajax à l'aide de 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 intéressant de noter que l'exécution de l' .la méthode abort () sur un objet XHR va également déclencher le callback d'erreur. Si vous faites n'importe quel genre d'erreur en manipulant ces objets, vous remarquerez rapidement qu'un XHR avorté et un timeout XHR sont identiques, mais avec jQuery le statut de texts qui est passé au callback d'erreur sera "avorté" quand avorté et "timeout" avec un timeout se produit. Si vous utilisez Zepto (très similaire à jQuery), l'errorType sera "erreur" en cas d'abandon et "timeout" en cas de timeout.
jQuery: error(jqXHR, textStatus, errorThrown);
Zepto: error(xhr, errorType, error);
dans mon cas, le statut est devenu 0 quand j'ai oublié de mettre le WWW en avant de mon domaine. Parce que toutes mes demandes ajax étaient codées en dur http:/WWW.mydomain.com et la page chargée serait juste http://mydomain.com it became a security issue because its a different domain. J'ai fini par faire une redirection dans mon .htaccess fichier pour toujours mettre www en avant.
comme détaillé par cette réponse sur cette page , un code d'état de 0 signifie que la requête 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 ceci vous pouvez faire l'un des suivants:
1) Utilisez cette extension chrome, Requestly pour rediriger votre url à partir de la version https
de votre url vers la version http
, car cela entraînera une erreur de sécurité de contenu mixte, et finalement générer un code d'état de 0. L'avantage de cette approche est que vous n'avez pas à changer votre application, et vous pouvez simplement "réécrire" votre url à l'aide de cette extension.
2) changez le code de votre application pour éventuellement faire rediriger votre endpoint vers la version http
de votre url au lieu de la version https
(ou vice versa). Si vous faites cela, la requête échouera avec le code d'état 0.
dans mon cas, c'était parce que L'appel AJAX était bloqué par le navigateur à cause de la Politique de même origine . 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 profonde était une innocente <base>
étiquette:
<base href='<%=request.getScheme()%>://<%=request.getServerName() + ":" + request.getServerPort() + request.getContextPath()%>/'/>
j'ai enlevé l'étiquette <base>
, ce que je n'ai pas fait besoin d'ailleurs, et maintenant il fonctionne très bien!
en plus de la réponse de Lee , vous pouvez trouver plus d'informations sur la cause réelle en passant à demandes synchrones , comme 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 est survenue.
dans le cas où quelqu'un d'autre tombe sur ce problème, cela me donnait des problèmes en raison de la demande AJAX et une demande normale de formulaire envoyé. Je l'ai résolu avec la ligne suivante:
<form onsubmit="submitfunc(); return false;">
la clé est la fausse déclaration, ce qui fait que le formulaire ne doit pas être envoyé. Vous pouvez aussi simplement renvoyer false De l'intérieur de submitfunc (), mais je trouve que c'est écrit explicitement pour être plus clair.
il est à noter qu'un téléchargement de fichier ajax dépassant la directive client_max_body_size
pour nginx retournera ce code d'erreur.
j'ai trouvé un nouveau sans-papiers et la raison pour status == 0. Voici ce que j'avais:
XMLHttpRequest.status === 0
XMLHttpRequest.readyState === 0
XMLHttpRequest.responseText === ''
XMLHttpRequest.state() === 'rejected'
il n'était pas d'origine croisée, réseau, ou en raison de demandes annulées (par code ou par navigation utilisateur). Rien dans la console du développeur ou le journal réseau.
j'ai pu trouver très peu de documentation sur state() (Mozilla ne l'a pas listée, W3C l'A) et aucune ne mentionnait"rejetée".
S'avère que c'était mon bloqueur publicitaire (uBlock Origine sur Firefox).