WebSocket nicht verbinden kann, um etwas anderes als 127.0.0.1 / localhost
Ich habe eine testapp, die aus einer HTML5/WebSocket-client und einem HTTP - /WS-server. Beide Server sind in C#; der HTTP-server meiner eigenen einfache Sache, und die WS-server ist auch homebrew basiert auf Konzepten von http://nugget.codeplex.com/. HTTP server listening on 0.0.0.0:5959-und WS-server auf 0.0.0.0:5960 (Annahme von verbindungen von beliebigen Clients aus, aber auf unterschiedliche ports).
Meine index.html enthält einige JavaScript-Code, öffnet sich ein WebSocket zu 'ws://'+document.location.hostname+':5960/' (d.h. die gleiche IP-Adresse, die Webseite, die kamen, aber auf port 5960). Der WS-server sendet Daten jeder 100ms. Alles in allem, ist es eine ziemlich einfache demo.
Ich bin mit Chrome 12.0 auf Windows7.
Habe ich herausgefunden, dass der HTTP-server funktioniert von jedem client aus einen browser auf meinem Rechner wies auf 127.0.0.1:5959 oder localhost:5959, UND es funktioniert, wenn jede Maschine (bei mir oder einer remote-Maschine... "remote" - Wesen von einem anderen PC auf meinem Schreibtisch 🙂 trifft meinen server-Maschine arbeiten-interne 10-net-Adresse 10.122.0.159:5959. Alles wie erwartet funktioniert in HTTP land.
Jedoch die WebSocket-funktioniert nur auf 127.0.0.1 und localhost; remote-Maschinen können erfolgreich Holen HTML von 10.122.0.159:5959 aber das WebSocket-KEINE Verbindung zu 10.122.0.159:5960. In der Tat, wenn ich meinen lokalen browser, um seine eigenen 10-net-Adresse (10.122.0.159:5959) bekomme ich das gleiche Ergebnis - HTML-lädt aber WebSocket-Verbindung nicht mit.
Irgendwelche Ideen, warum dies geschehen könnte?
Tut CORS verlangen, dass die WS werden mit dem gleichen port wie der HTTP-Anforderung stammt, aus? Wenn ja, gibt es eine spezielle Ausnahme von der Regel für 127.0.0.1?
Vielen Dank,
-Dave
Update
Es scheint verursacht zu werden durch einen proxy-server blockiert ws://- Anfragen. Unser Unternehmen beschäftigt einen proxy-server für die Inhaltsfilterung und all das übliche Zeug, und unsere Browser sind für die Verwendung konfiguriert ist.
Chrome nutzt den IE-proxy-Einstellungen des IE-Standardeinstellungen sind für localhost zu nicht verwenden Sie einen proxy-server. Wenn ich das Kontrollkästchen für lokale verbindungen auch über die proxy-server, meine ws://Anfragen auf localhost blockiert. Umgekehrt, wenn ich deaktivieren Sie das Kontrollkästchen "use proxy server" - box mein server hat rx der WS-Anfrage. Ähnlich ist es mit der remote-Maschine, wenn ich schalten Sie den proxy auf den entfernten Rechner meinen server hat rx das ws://- Anforderung.
Also ist es ein proxy-Sache, nicht eine CORS-oder socket-Ding, und jetzt bin ich off zu erkunden, proxy-Einstellungen, mit unsere IT-Leute.
- "Fragen unsere IT-Leute, um änderungen" in was für einer Welt würde das funktionieren?
Du musst angemeldet sein, um einen Kommentar abzugeben.
Gibt es keine WebSocket-Beschränkung auf cross-origin-außer dem, was geregelt wird, die von der CORS-Sicherheit im handshake.
Es klingt wie etwas, was falsch ist mit dem WebSocket-server und es ist nur lauscht auf localhost auf verbindungen. Ich möchte hinzufügen, einige debug-Ausgabe in die OnClientConnect routine im Nugget (WebSocketServer.cs), so dass Sie sehen können, wenn die socket-verbindungen geschehen. Wenn Sie wirklich denke, es ist nicht ein problem mit dem server, dann würde ich vorschlagen, mit wireshark und vergleichen Sie die localhost-Verbindung zu dem remote-Anschluss.
Auch, wenn Sie das SilverLight-WebSocket-Prototyp (README) in IE 9, dann sind Sie beschränkt auf die ports 4502-4534 für WebSocket-verbindungen. Es ist möglich, dass für localhost diese Einschränkung ist aufgehoben.
Es ist/war in der Tat ein proxy-Sache.
Statt zu Fragen, unsere IT-Leute, um änderungen vorzunehmen (viel Glück mit, dass, eh?) Ich einfach deaktiviert proxy für 10.122.0.159 ([Howto für IE/Chrome][1]). Ich experimentierte kurz mit ausschalten für das ws://- Protokoll, konnte aber nicht, dass es funktioniert, so für jetzt nur noch öffnen, die eine IP-Adresse funktioniert der trick.