Websockets reverse-proxy in IIS 8

Hatte ich schon versucht zu erreichen, die gleiche Sache auf IIS 8.5 mit ARR 3.0, und fand endlich das problem. Laut Microsoft ist Erez Benari, dies ist möglich:

WebSocket-Unterstützung erfordert, dass die WebSocket-Funktion installiert werden, die auf IIS, sondern erfordert keine weitere Konfiguration oder Aktion. Installieren Sie das feature über den Server-Manager Rollen und Features Hinzufügen, und wenn das abgeschlossen ist, ARR 3.0 Bearbeitung der Anfragen entsprechend.

Als test habe ich ein Node.js server für WebSocket:

const WebSocketServer = require('ws'); 
const wss = new WebSocketServer({ port: 3011 }); 
Funktion sendWSMessage(msg) { 
wss.Kunden.forEach((client) => { 
client.send(msg); 
}); 
} 
setInterval(function() { 
sendWSMessage ("Hallo client"); 
}, 3000); 

Zusammen mit einem einfachen test Seite:

var websock = new WebSocket('ws://localhost:3011'); 
websock.onmessage = function (event) { 
console.log(event.Daten); 
}; 
websock.onopen = function (event) { 
websock.send("hello server"); 
};

Dann, ich habe eine ARR reverse-proxy auf meiner lokalen Maschine, mit dem folgenden in einem web.config-Datei von einem "wstest" - Verzeichnis auf localhost:

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.webServer>
    <rewrite>
        <rules>
            <rule name="WebSocketTestRule" stopProcessing="true">
                <match url=".*" />
                <conditions>
                    <add input="{CACHE_URL}" pattern="^(.+)://" />
                </conditions>
                <action type="Rewrite" url="{C:1}://localhost:3011/" />
            </rule>
        </rules>
    </rewrite>
</system.webServer>
</configuration>

Diese weiterleiten soll der ganze Verkehr für //localhost/wstest zu einem Node.js server auf port 3011. Die Node-server funktioniert, wenn ich direkt verbinden, um es über ws://localhost:3011. Wenn ich versuche die Verbindung über den proxy über ws://localhost/wstest, der Antrag macht es durch die Node.js server, die Aktualisierung Auftritt, und die Verbindung ist hergestellt.

Chrome sendet:

BEKOMMEN ws://localhost/wstest HTTP/1.1 
Host: localhost 
Connection: Upgrade 
Pragma: no-cache 
Cache-Control: no-cache 
Upgrade: websocket 
Herkunft: Datei://
Sec-WebSocket-Version: 13 
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.84 Safari/537.36 
Accept-Encoding: gzip, deflate, sdch 
Accept-Language: en-US,en;q=0.8 
Sec-WebSocket-Key: 4ufu8nAOj7cKndASs4EX9w== 
Sec-WebSocket-Erweiterungen: permessage-deflate; client_max_window_bits 

Den Node.js server empfängt:

cache-control: no-cache 
connection: upgrade 
pragma: no-cache 
upgrade: Websocket 
accept-encoding: gzip, deflate, sdch 
accept-language: en-US,en;q=0.8 
host: localhost:3011 
max-forwards: 10 
user-agent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.84 Safari/537.36 
Herkunft: Datei://
sec-websocket-version: 13 
sec-websocket-key: fBkTwAS9d/unXYKDE3+Jjg== 
sec-websocket-Erweiterungen: permessage-deflate; client_max_window_bits 
x-original-url: /wstest 
x-forwarded-for: [::1]:54499 
x-arr-log-id: a0b27458-9231-491d-b74b-07ae5a01c300 

Den Node.js server antwortet mit:

HTTP/1.1 101 Switching Protocols 
Upgrade: websocket 
Connection: Upgrade 
Sec-Websocket-Accept: yep8mgQACAc93oGIk8Azde4WSXk= 
Sec-WebSocket-Erweiterungen: permessage-deflate 

Und schließlich Chrome erhält:

HTTP/1.1 101 Switching Protocols 
Upgrade: Websocket 
Sec-WebSocket-Accept: CBSM8dzuDoDG0OrJC28nIqaw/sI= 
Sec-WebSocket-Erweiterungen: permessage-deflate 
X-Powered-By: ARR/3.0 
Connection: Upgrade 
X-Powered-By: ASP.NET 
Datum: Fri, 10 Jun 2016 21:16:16 GMT 
Endzeit: 17:16:16.148 
ReceivedBytes: 0 
SentBytes: 0 

So, jetzt sind Sie verbunden. Dies alles sieht gut aus, der einzige auffällige Unterschied ist, dass die Sec-WebSocket-Key und Sec-WebSocket-Accept " wird geändert in beide Richtungen, indem Sie entweder IIS oder den ARR-proxy.

Aber... keine WebSocket-frames jemals machen es durch den proxy! Wenn Chrome erhält positives feedback auf Ihre upgrade-Anfrage, sendet er seine WebSocket-message-frame, und es ist dann sitzen und warten auf Nachrichten vom server. Die Node.js der server sendet seine frames, und es tritt kein Fehler auf, aber Sie erhielt nie von Chrome. Die Nachricht, dass Chrome gesendet wird nie eingegangen Node.js. Es scheint, dass ARR/IIS fallen die WebSocket-frames in beide Richtungen.

Bemerken, wie Chrome ist, dem server mitzuteilen, dass es unterstützt die permessage-entlüften-Erweiterung, die eine WebSocket-Erweiterung für pro-Nachricht-Komprimierung. Der server antwortet, dass es unterstützt auch permessage-entlüften, so dass, wenn Sie browser und server senden sich gegenseitig Nachrichten, benutzen Sie diese Kompressions-Erweiterung. JEDOCH, der Mann in der Mitte, ARR scheinbar NICHT unterstützen diese Komprimierung! Durch ausschalten der Unterstützung für permessage-deflate auf dem server, die eigentliche WebSocket-frames können nun über den proxy einwandfrei:

const wss = new WebSocketServer({ port: 3011, perMessageDeflate: false }); 

Ich denke, das Problem ist, dass ARR 3.0 nicht unterstützt Sec-Websocket-Extensions header, also es ist so dass der Kopf einfach Durchlaufen. Aber dass diese header werden ausgehandelt zwischen dem client und dem server ist falsch, denn die ARR ist nicht eingebunden in die Verhandlungen und hat keine Möglichkeit zu sagen, die beiden Parteien, die es nicht unterstützen die Weitergabe von komprimierten Nachrichten. Hoffentlich eines Tages, ARR wird in der Lage sein, ordnungsgemäß zu behandeln Erweiterungen durch Verhandlung zwischen sich selbst und den client, und dann tut eine separate Verhandlung zwischen sich und dem server. Wie es jetzt steht, es hat einfach den client und-server verhandeln mit jedem anderen, die Ergebnisse in diesen Fehler.