2017-08-15 1 views
0

Ich machte eine kleine Anwendung, die Daten von einer Waage über RS232 erhält, und die diese Daten mit einem integrierten Webserver auf einer URL wie http://localhost:51111/Scale1?min=1.5&max=420 zurückgibt. Die Parameter sollen einige Konfigurationsdaten auf die Waage legen.Kann XmlHttpRequest nicht mit CORS arbeiten

Jetzt muss ich die Daten in einer Webseite erhalten, von einem IIS-Server auf einem zentralen Rechner bedient. Es gibt ein CORS-Problem hier, aber mein Firefox scheint CORS zu unterstützen:

gibt True zurück.

die Informationen auf mehreren Foren und JS Bücher gefunden verwenden, habe ich diese JS-Code:

function httpGetAsync() { 
     var theUrl = 'http://localhost:51111/Scale1?min=1.5&max=420'; 
     var req = new XMLHttpRequest(); 
     req.onreadystatechange = function() { 
      if (req.readyState == XMLHttpRequest.DONE) { 
       $('#value').text('state: ' + req.readyState + ', status: ' + req.status + ', text: ' + req.responseText); 
      } 
     } 
     req.open("GET", theUrl, true); // true for asynchronous 
     req.send(null); 
     return; 
    } 

Die Webseite verfügt über zusätzliche HTTP-Header-Kreuz Origin anfordern Scripting (CORS) zu ermöglichen:

Access-Control-Allow-Origin: http://localhost:51111 
Access-Control-Allow-Methods: GET,POST 

Mit Fiddler und dem Firefox-Debugger (F12) kann ich sehen, dass der JS tatsächlich eine Anfrage an die lokale Anwendung sendet, Port 51111 zu hören, auf dieser App kann ich sehen, dass die Min/Max-Daten korrekt empfangen werden, und die App Antworten mit Status 200 und einige Daten im Körper, das ist die rohe Antwort e:

HTTP/1.1 200 OK 
Content-Length: 4 
Server: Microsoft-HTTPAPI/2.0 
Date: Tue, 15 Aug 2017 14:36:50 GMT 

1.15 

sucht cool, aber:

Mein Problem ist, dass die oben JS nicht über den Körper Inhalt: req.status Null 0, nicht 200, und req.responseText ist die leere Zeichenkette anstelle der "1,15".

Ich habe Firefox und Chrome ausprobiert.

+1

Der Server "http: // localhost: 51111" muss so konfiguriert werden, dass er den Antwort-Header "Access-Control-Allow-Origin" und alle anderen erforderlichen "Access-Control-Allow-*" - Antwortheader sendet. Aus Ihrer Frage ist nicht ersichtlich, wo oder wie Sie diese festlegen, aber die in der Frage angegebene Antwort zeigt nicht, dass sie als Antwort-Header empfangen werden. Daher scheint es, dass Sie nicht das "http: // localhost: 51111" haben müssen Server konfiguriert, um sie zu senden – sideshowbarker

+0

@sideshowbarker Sie hatten Recht! Der zusätzliche Header muss in der Antwort des zweiten Servers enthalten sein.Ich lese https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS, um dies zu verstehen. Wenn Sie Ihren Kommentar als Lösung posten würden, würde ich gerne akzeptieren. – Roland

+0

@sideshowbarker Da Sie als Beitragszahler zu dieser Mozilla-Seite aufgeführt sind, sind Sie vielleicht die richtige Person, um mehr über CORS zu erfahren, um zu verstehen, warum die zusätzlichen Header in der Antwort dieses zweiten Servers und nicht in der ersten sein müssen Server. – Roland

Antwort

0

Der Server http://localhost:51111 muss konfiguriert werden, um den Antwortkopf Access-Control-Allow-Origin und alle anderen erforderlichen Antwortkopfzeilen Access-Control-Allow-* zu senden. Das liegt daran, dass es der Server ist, an den der Front-End-JS-Code die Anfrage sendet.

Die in der Frage angegebene Antwort zeigt nicht, dass diese als Antwortheader empfangen werden. Daher scheint es so, als ob der Server http://localhost:51111 nicht konfiguriert sein muss, um sie zu senden.

Standardmäßig erlauben Browser Ihrem Front-End-JS-Code nicht, auf die Antwort von einer stammesübergreifenden Anfrage zuzugreifen - es sei denn, ein Server entscheidet sich dafür. Und die Art und Weise, in der sich die Server dafür entscheiden, übergreifende Anfragen zuzulassen, ist der Antwortkopf Access-Control-Allow-Origin in Antworten.

Die tatsächliche Durchsetzung des CORS-Protokolls wird von Browsern durchgeführt. So ist der Antwort-Header Access-Control-Allow-Origin, was Server verwenden, um mit Browsern zu kommunizieren; Server verwenden es, um den Browsern mitzuteilen, zu welchen Ursprüngen die Browser Antworten von diesem Server bereitstellen sollen.

Deshalb ist in Ihrem Fall der http://localhost:51111 Server derjenige, den Sie konfigurieren müssen, um den richtigen Antwortkopf Access-Control-Allow-Origin zu senden.