it-swarm.com.de

Leerer responseText von XMLHttpRequest

Ich habe ein XMLHttpRequest geschrieben, das gut ausgeführt wird, aber einen leeren responseText zurückgibt.

Das Javascript ist wie folgt:

  var anUrl = "http://api.xxx.com/rates/csv/rates.txt";
  var myRequest = new XMLHttpRequest();

  callAjax(anUrl);

  function callAjax(url) {
     myRequest.open("GET", url, true);
     myRequest.onreadystatechange = responseAjax;
                 myRequest.setRequestHeader("Cache-Control", "no-cache");
     myRequest.send(null);
  }

  function responseAjax() {
     if(myRequest.readyState == 4) {
        if(myRequest.status == 200) {
            result = myRequest.responseText;
            alert(result);
            alert("we made it");
        } else {
            alert( " An error has occurred: " + myRequest.statusText);
        }
     }
  }

Der Code läuft gut. Ich kann durchgehen und bekomme den readyState == 4 und einen Status == 200, aber der responseText ist immer leer.

Ich erhalte einen Protokollfehler (in Safari-Debug) von Error Dispatching: getProperties, auf den ich scheinbar keinen Verweis finden kann. 

Ich habe den Code in Safari und Firefox sowohl lokal als auch auf einem Remote-Server ausgeführt.

Wenn die URL in einen Browser eingefügt wird, wird die Zeichenfolge zurückgegeben und der Statuscode 200 angezeigt.

Ich habe einen ähnlichen Code in ein Mac-Widget geschrieben, das gut funktioniert, aber derselbe Code in einem Browser gibt niemals ein Ergebnis zurück.

27
PurplePilot

Ist http://api.xxx.com/ Teil Ihrer Domain? Wenn nicht, werden Sie von der gleichen Origin-Richtlinie blockiert.

Sie können den folgenden Stack Overflow-Beitrag auf einige mögliche Problemumgehungen überprüfen:

26
Daniel Vassallo

PROBLEM GELÖST

In meinem Fall bestand das Problem darin, dass ich den Ajax-Aufruf (mit $ .ajax, $ .get oder $ .getJSON-Methoden von jQuery) mit vollständiger Pfad in der URL param: 

url: " http://mydomain.com/site/cgi-bin/serverApp.php "

Der richtige Weg ist jedoch, den Wert von url als:

uRL: "site/cgi-bin/serverApp.php"

Einige Browser stehen nicht miteinander in Konflikt und machen keine Unterscheidung zwischen dem einen oder anderen Text. In Firefox 3.6 für Mac OS wird vollständiger Pfad als "cross site scripting" bezeichnet ... eine andere Sache in Im selben Browser unterscheidet man zwischen:

http://mydomain.com/site/index.html

Und legen

http://www.mydomain.com/site/index.html

In der Tat ist dies die richtige Punktansicht, aber die meisten Implementierungen unterscheiden sich nicht. Daher bestand die Lösung darin, den gesamten Text zu entfernen, der vollständiger Pfad für das Skript in den Methoden enthält, die die Ajax-Anforderung ausführen. UND .... entfernen Sie alle BASE -Tags in der index.html-Datei

base href = "http://mydomain.com/" <--- schlechte Idee, entferne sie!

Wenn Sie es nicht entfernen, kann diese Version des Browsers für dieses System Ihre Ajax-Anfrage annehmen, als ob es sich um eine Cross-Site-Anfrage handelt!

Ich habe das gleiche Problem aber nur auf dem Mac OS-Rechner. Das Problem ist, dass Firefox die Ajax-Antwort als "Cross Site" -Aufruf behandelt. In jedem anderen Computer/Browser funktioniert das einwandfrei. Ich habe keine Hilfe gefunden (ich denke, das ist ein Problem bei der Firefox-Implementierung), aber ich werde den nächsten Code auf der Serverseite beweisen:

header('Content-type: application/json');

um sicherzustellen, dass der Browser die Daten als "Json-Daten" erhält ...

12
Ivan David

Der Browser verhindert das Cross-Site-Scripting.

Wenn sich die URL außerhalb Ihrer Domäne befindet, müssen Sie dies serverseitig tun oder in Ihre Domäne verschieben.

4
Jacob Relkin

Dies ist möglicherweise nicht der beste Weg, dies zu tun. Aber es hat irgendwie für mich funktioniert, also werde ich damit rennen.

In meiner PHP-Funktion, die die Daten zurückgibt, füge ich eine Zeile vor der Rückgabezeile eine Echo-Anweisung hinzu, die die Daten wiedergibt, die ich senden möchte.

Jetzt sicher, warum es funktioniert hat, aber es tat es. 

1
swl1020

Hatte ein ähnliches Problem wie bei Ihnen. Wir mussten die document.domain-Lösung verwenden, die Sie hier finden:

Möglichkeiten zur Umgehung der Richtlinie über dasselbe Origin

Wir mussten auch auf der Webservice-Seite etwas nachdenken. Der Header "Access-Control-Allow-Origin" wurde hier verwendet:

https://developer.mozilla.org/En/HTTP_access_control

0
wkm