Der IIS braucht für Websockets (WS:// oder WSS://) ein bisschen Nachhilfe. Der IIS, oder auch die Internetinformationsdienste unterstützen WS/WSS nativ (und auch sehr performant), aber Secure-by-Default mit dem Setting „off“. Das gilt genauso auch für den ARR mit (pro-site) aktivem ReverseProxy.
Die Aktivierung ist aber im Wesentlichen in drei Schritten erledigt.
Lösung
1. Das Windows-Feature (IIS-Feature) Websockets via PowerShell installierenPS C:\> Install-WindowsFeature -name Web-WebSockets
… oder das selbe im GUI (Server-Manager) erledigen. Features Hinzufügen > Webserver > Anwendungsentwicklung > WebSocket-Protokoll
2. Die Nutzung (Inhaltsänderung) der Servervariable HTTP_SEC_WEBSOCKET_EXTENSIONS Serverweit erlauben.
Serverweit: Internetinformationsdienste-Manager > links auf den Serverknoten > rechts „URL Rewrite“ öffnen
Dann die „Servervariablen anzeigen“ …
… und über den „Hinzufügen“ Link die Variable HTTP_SEC_WEBSOCKET_EXTENSIONS anlegen.
3. Die Nutzung für die Proxy-Site erlauben
Dazu die ARR-Site „Inbound“ Regel bearbeiten…
… unter „Servervariablen“ die HTTP_SEC_WEBSOCKET_EXTENSIONS Variable mit dem Wert „0“ und dem Haken „Vorhandenen Wert ersetzen“ hinzufügen.
⚠️ Das GUI lässt hier leider keine leeren Werte zu. Das kann manche Web-Apps (SAP, Sales-Apps, Visitenkartenscanner) verwirren.
Um das zu verhindern kann man in der zu der Site gehörigen web.config einfach die „0“ als Wert löschen und die config wieder speichern. Sobald der Wert dort leer ist, leitet der IIS auch Header ohne Inhalt unverändert weiter.
Update (Windows Server 2022)
Unter Windows Server 2022 sind uns einige Maschinen untergekommen, die aus „irgendeinem Grund“ die Websockets trotz dieser Konfiguration nicht eingeschaltet haben.
Wir konnten bisher noch nicht herausfinden, warum das sporadisch so ist, aber der Fix ist zum Glück einfach.
Im IIS-Konfigurationseditor der Site muss man unter system.webServer/webSocket den Wert enabled auf true setzen.
