CacheFlow breaks Websocket supported Webpages

book

Article ID: 165436

calendar_today

Updated On:

Products

CF-5000 CF-500

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