Yes, I have configured this successfully. This behavior is due to IIS ARR inability of handling websocket compression properly. When launching a session, Chrome sends a websocket upgrade request containing a “Sec-WebSocket-Extensions” header with a value of “permessage-deflate”; the proxy server receives this message and forwards it to the gateway server, which responds back with the websocket protocol swap, including the “permessage-deflate” compression. However, while the proxy server receives subsequent websocket frames from the gateway server, it does not forward them back to the client (browser).
We can add a server variable within the inbound proxy rule so that the “Sec-WebSocket-Extensions” header is cleared, meaning that the requested compression isn’t used for websocket frames.
Do the following on the proxy server:
- Add the server variable within IIS Manager > URL Rewrite > View Server Variable… > Add…
Server Variable Name: HTTP_SEC_WEBSOCKET_EXTENSIONS
- Edit inbound rule (IIS Manager > Your Site > URL Rewrite) and add server variable:
Name: HTTP_SEC_WEBSOCKET_EXTENSIONS
Value: “”
Replace the existing value: True
- Locate path where web.config is stored. (e.g. %SystemDrive%\inetpub\wwwroot)
-
Clear value for HTTP_SEC_WEBSOCKET_EXTENSIONS variable within web.config.
<set name="HTTP_SEC_WEBSOCKET_EXTENSIONS" value="" />
