XMLHttpRequest Status 0 (responseText ist leer)

Mit XMLHttpRequest können keine Daten abgerufen werden (Status 0 und responseText sind leer):

xmlhttp = new XMLHttpRequest ();
xmlhttp.open ("GET", "http://www.w3schools.com/XML/cd_catalog.xml", true);
xmlhttp.onreadystatechange = function () 
{
  if (xmlhttp.readyState == 4)
    alert ("status" + xmlhttp.status);
}}
xmlhttp.send ();

Es warnt "Status 0".

Die gleiche Situation mit der localhost-Anforderung (cd_catalog.xml wird als lokale Datei gespeichert)

xmlhttp.open ("GET", "http: //localhost/cd_catalog.xml", true);

Aber mit der localhost IP Anfrage

xmlhttp.open ("GET", "http://127.0.0.1/cd_catalog.xml", true);

und mit der lokalen Dateianforderung

xmlhttp.open ("GET", "cd_catalog.xml", true);

alles ist in Ordnung (Status 200)

Was kann das Problem (Status = 0) bei der Online-Anfrage verursachen?

PS: Live-HTTP-Header zeigen, dass in allen 4 Fällen alles in Ordnung ist:

  HTTP / 1.1 200 OK
  Inhaltslänge: 4742

PS2: Apache lokaler Webserver unter VMWare (Host-Betriebssystem Win7, Gast-Betriebssystem Ubuntu, Netzwerkadapter - NAT). Browser - Firefox.

Der Status ist 0, wenn Ihre HTML-Datei mit dem Skript über das Dateischema im Browser geöffnet wird. Stellen Sie sicher, dass Sie die Dateien auf Ihrem Server ablegen (Apache oder Tomcat) und öffnen Sie sie dann über das http-Protokoll im Browser. (dh http: //localhost/myfile.html ) Dies ist die Lösung.

Die Ursache für Ihre Probleme ist, dass Sie versuchen, einen domänenübergreifenden Anruf zu tätigen, der fehlschlägt .

Wenn Sie localhost entwickeln, können Sie domänenübergreifende Anrufe tätigen - ich mache das die ganze Zeit.

Für Firefox müssen Sie es in Ihren Konfigurationseinstellungen aktivieren

signed.applets.codebase_principal_support = true

Fügen Sie dann Ihrem offenen XHR-Code Folgendes hinzu:

  if (isLocalHost()){
    if (typeof(netscape) != 'undefined' && typeof(netscape.security) != 'undefined'){
      netscape.security.PrivilegeManager.enablePrivilege('UniversalBrowserRead');
    }
  }

Wenn ich mich recht erinnere, müssen Sie für IE lediglich die Sicherheitseinstellung des Browsers unter "Verschiedenes → Domänenübergreifend auf Datenquellen zugreifen" aktivieren, damit er mit ActiveX XHRs funktioniert.

IE8 und höher haben auch domänenübergreifende Funktionen zu den nativen XmlHttpRequest-Objekten hinzugefügt, aber ich habe noch nicht mit diesen gespielt.

Stellen Sie sicher, dass Ihr Schaltflächentyp "Schaltfläche nicht senden" ist, was zu einem Statuskonflikt geführt hat, den ich kürzlich getroffen habe.

Wenn der Server auf eine OPTIONS-Methode und auf GET und POST (je nachdem, welche Sie verwenden) mit einem Header wie folgt antwortet:

Access-Control-Allow-Origin: *

Es könnte in Ordnung funktionieren. Scheint in FireFox 3.5 und rekonq 0.4.0. Anscheinend sagt der Server mit diesem Header und der ersten Antwort auf OPTIONEN zum Browser: "Fahren Sie fort und lassen Sie diese domänenübergreifende Anforderung durchlaufen."

Berücksichtigen Sie auch das Anforderungszeitlimit :

Moderne Browser geben readyState = 4 und s tatus = 0 zurück, wenn vor der Serverantwort zu viel Zeit vergeht.

Fügen Sie setRequestHeader("Access-Control-Allow-Origin","*")Ihrer Serverantwort hinzu.

Ich hatte ein ähnliches Problem. Alles war in Ordnung, der "Readystate" war 4, aber der "Status" war 0. Dies lag daran, dass ich einen tragbaren Apache PHP-Server verwendete und meine Datei, in der ich das "XMLHttpRequest" -Objekt verwendete, eine HTML-Datei war. Ich habe die Dateierweiterung in PHP geändert und das Problem wurde behoben.

Öffnen Sie die Javascript-Konsole . Dort wird eine Fehlermeldung angezeigt. In meinem Fall war es CORS.

Zur Beantwortung der Frage, warum http://127.0.0.1/cd_catalog.xmlfunktioniert , während http://localhost/cd_catalog.xmlnicht: Firefox behandelt 127.0.0.1 und localhost als zwei verschiedene Domänen.

Um zu sehen, wo das Problem liegt, gehen Sie zu ... |, wenn Sie den kryptischen Fehler 0 erhalten Weitere Tools | Entwicklertools (Strg + Umschalt + I) in Chrome (auf der Seite mit dem Fehler)

Lesen Sie den roten Text im Protokoll, um die wahre Fehlermeldung zu erhalten. Wenn zu viel drin ist, klicken Sie mit der rechten Maustaste und klicken Sie auf Konsole löschen. Führen Sie dann Ihre letzte Anfrage erneut aus.

Mein erstes Problem war, dass ich zum ersten Mal Autorisierungsheader an meinen eigenen domänenübergreifenden Webdienst für den Browser übergab.

Ich hatte bereits:

Access-Control-Allow-Origin: *

Aber nicht:

Access-Control-Allow-Methods: GET, POST, PUT, DELETE
Access-Control-Allow-Headers: Authorization

im Antwortheader meines Webdienstes.

Nachdem ich das hinzugefügt hatte, war mein Fehler Null von meinem eigenen Webserver sowie beim lokalen Ausführen der Datei index.html ohne Webserver verschwunden, gab aber immer noch Fehler im Codestift aus.

Zurück zu ... | Weitere Tools | Entwicklertools, während der Fehler in Codepen angezeigt wird, und es wird klar erklärt: Codepen verwendet https, daher kann ich http nicht aufrufen, da die Sicherheit geringer ist.

Ich muss daher meinen Webdienst auf https hosten.

Wissen, wie man die wahre Fehlermeldung erhält - von unschätzbarem Wert!

Hier ist ein weiterer Fall, in dem status === 0speziell für das Hochladen:

Wenn Sie einen 'load'Ereignishandler anhängen XHR.upload, wie von MDN vorgeschlagen (scrollen Sie nach unten zum Upload-Teil von 'Überwachungsfortschritt'), hat das XHR-Objekt status=0und alle anderen Eigenschaften sind leere Zeichenfolgen. Wenn Sie die anhängen'load' Handler wie beim Herunterladen von Inhalten direkt an das XHR-Objekt , sollte dies in Ordnung sein (vorausgesetzt, Sie führen localhost nicht aus).

Wenn Sie jedoch gute Daten in Ihren 'progress'Ereignishandlern erhalten möchten , müssen Sie einen Handler anhängen XHR.upload, nicht direkt an das XHR-Objekt selbst.

Ich habe dies bisher nur unter Chrome OSX getestet, daher bin ich mir nicht sicher, wie groß das Problem hier in der MDN-Dokumentation und inwieweit in der Implementierung von Chrome ist.

Alex Robinson gibt bereits (und zuerst) die richtige Antwort auf dieses Problem. Aber um es etwas näher zu erläutern ...

Sie müssen den HTTP-Antwortheader hinzufügen:

Access-Control-Allow-Origin: *

Wenn Sie dies tun, ist das Ergebnis nicht nur "könnte funktionieren", sondern "wird funktionieren".

NB Was Sie hinzufügen müssen , ist ein HTTP - Antwort - Header - so dass Sie nur diese auf einem Server tun , die Sie steuern. Es wird niemals möglich sein, http://w3schools.com/XML/cd_catalog.xml direkt von seiner ursprünglichen URL mit einem abzurufenXMLHttpRequest (gemäß der Frage des OP) , da diese Ressource dies nicht tut (zumindest nicht ab dem 24. April 2015). Fügen Sie einen solchen CORS-Header hinzu.

http://en.wikipedia.org/wiki/Cross-origin_resource_sharing bietet weitere Informationen.

Mein ähnliches Problem wurde durch Überprüfen meines HTML-Codes gelöst. Ich hatte einen onclickHandler in meinem Formular, der die Schaltfläche an eine Methode sendet. so : onclick="sendFalconRequestWithHeaders()". Diese Methode ruft Ajax genau wie Ihre auf und macht, was ich will. Aber nicht wie erwartet gab mein Browser nichts zurück.

Aus der harten Arbeit von jemandem gelernt , habe ich in diesem Handler falsch zurückgegeben und gelöst. Lassen Sie mich erwähne , dass zu diesem Beitrag vor der Ankunft, ich ein ganzes 3-Tage - Wochenend und einen halben Tag im Büro Schreiben von Code ausgegeben habe Implementierung CORS filters, jetty configandere jersey and embedded jettyähnliche Sachen - nur dieses Problem zu beheben, revolvierende alle mein Verständnis um.cross domain ajax requests Und Standards Zeug. Es war lächerlich, wie einfach Fehler in Javascript dich dumm machen.

Um wahr zu sein, habe ich versucht signed.applets.codebase_principal_support = trueund geschrieben isLocalHost() **if**. Möglicherweise muss diese Methode von uns implementiert werden. Firefox sagt, dass es keine solche gibt. Jetzt muss ich meinen Code bereinigen, um den Git-Patch sauber einzureichen. Danke an jemanden.

Eine Browseranforderung "127.0.0.1/somefile.html" kommt unverändert auf dem lokalen Webserver an, während "localhost / somefile.html" als "0: 0: 0: 0: 0: 0: 0: 1 / somefile.html" ankommt "wenn IPv6 unterstützt wird. Letztere können also so verarbeitet werden, dass sie von einer Domain zu einer anderen wechseln.

Alex Robinson und bmju lieferten wertvolle Informationen zum Verständnis von Problemen zwischen den Ursprüngen. Ich wollte hinzufügen, dass Sie möglicherweise einen expliziten OPTIONS-Aufruf in Ihrem Client-Code ausführen müssen, bevor Sie den gewünschten GET / POST ausführen (z. B. gegen einen CORS OAuth-Service-Endpunkt). Ihr Browser / Ihre Bibliothek verarbeitet die OPTIONS-Anforderung möglicherweise nicht automatisch. Gruber, dies ist eine der möglichen Antworten auf Ihre Frage.

Ich hatte das gleiche Problem (readyState war 4 und Status 0) , dann folgte ich einem anderen Ansatz, der in diesem Tutorial erläutert wurde: https://spring.io/guides/gs/consuming-rest-jquery/

Er hat XMLHttpRequest überhaupt nicht verwendet , sondern die Methode jquery $ .ajax () :

<head>
    <script src="https://ajax.googleapis.com/ajax/libs/jquery/1.10.2/jquery.min.js"></script>
    <script src="hello.js"></script>
</head>

<body>
    <div>
        <p class="greeting-id">The ID is </p>
        <p class="greeting-content">The content is </p>
    </div>
</body>

und für die Datei public / hello.js (oder Sie können sie direkt in denselben HTML-Code einfügen):

$(document).ready(function() 
 {
    $.ajax({
        url: "http://rest-service.guides.spring.io/greeting"
   }).then(function(data) {
      $('.greeting-id').append(data.id);
      $('.greeting-content').append(data.content);
   });
 });

Ich musste meine aktuelle IP-Adresse (erneut) zur Whitelist von Atlas MongoDB hinzufügen und habe so den Fehler XMLHttpRequest Status 0 beseitigt

Ich hatte gerade dieses Problem, weil ich es 0.0.0.0als Server verwendet habe, es geändert habe localhostund es funktioniert.

Bearbeiten: Bitte lesen Sie die Kommentare von Malvolio unten, da das Wissen dieser Antwort veraltet ist.

Sie können keine domänenübergreifenden XMLHttpRequests durchführen.

Der Aufruf von 127.0.0.1funktioniert, weil sich Ihre Testseite unter befindet 127.0.0.1, und der lokale Test funktioniert auch, da ... es sich um einen lokalen Test handelt.

Die beiden anderen Tests schlagen fehl, da JavaScript über XMLHttpRequest nicht mit einem entfernten Server kommunizieren kann.

Sie könnten stattdessen entweder Folgendes in Betracht ziehen:

• XMLHttp-fordern Sie Ihren eigenen Server auf, Ihren Remote-XML-Inhalt für Sie abzurufen (z. B. PHP-Skript).
• Versuchen Sie, einen Dienst wie GoogleAppEngine zu verwenden, wenn Sie das vollständige JavaScript beibehalten möchten.

hoffentlich hilft das