CacheFlow breaks Websocket supported Webpages
Article ID: 165436
Updated On:
Products
Issue/Introduction
When accessing a Websocket supported webpage through CacheFlow it will fail to load. This happens because the CacheFlow will strip the "Connection: Upgrade" header and the "Upgrade: Websocket" header when sending the request upstream.
These headers are Hop-By-Hop headers as defined in RFC2616 and are only useful for a single transport-level connection, meaning that they are intended to be stripped by intermediary devices. The CacheFlow will not regenerate these headers as it does not understand them.
Both the "Connection: Upgrade" and the "Upgrade: Websocket" header are required to establish a Websocket connection as per RFC6455. Therefore when the headers are stripped and the request is forwarded upstream the server will respond back with an appropriate error code such as "400 Bad Request".
Resolution
To work around this problem any requests that are attempting to upgrade their connection should be bypassed before reaching the CacheFlow, or if this is not possible by the CacheFlow.
The following Local Policy configuration will ensure that these requests are dynamically bypassed.
CacheFlow# inline policy local abcd
<access>
request.header.Connection=Upgrade bypass(yes)
abcd
As with all dynamically bypassed connections the first request will fail and the CacheFlow will ask the client to Refresh. Once this is done the connection will be in the dynamic bypass table as shown below.
CacheFlow# show proxy-services dynamic-bypass
Reason legend:
U - User policy A - Asymmetric route N - Non-HTTP
C - Connect error R - Receive error 5 - 5xx
Client IP address Server IP address Timeout (minutes) Use Count Reasons
10.10.11.2 1.2.3.4 59 1 U
Feedback
