[squid-users] Web Socket Support For Reverse Proxy

[Dean E. Weimer]

On 2019-01-04 1:39 am, Amos Jeffries wrote:
> On 4/01/19 5:48 am, Dean E. Weimer wrote:
>> I am running Squid as a reverse proxy for several internally hosted
>> websites, some HTTP and some HTTPS with wild card cerrtificate. We 
>> have
>> recently setup a Atlassian Confluence Server, and are unable to edit 
>> any
>> documents through the reverse proxy. On inspection of client web 
>> console
>> logs we are receiving the following error.
>> 
>> failed: Error during WebSocket handshake: Unexpected response code: 
>> 200
>> 
> 
> The client software does not support the WebSockets fallback
> mechanism(s) properly.

Searching for Fallback information led me to find part of the issue.


It appears that the Confluence web application is using synchrony to 
handle collaborative editing they wrote their own proxy to proxy the web 
socket requests to the synchrony app from within their app. That proxy 
has a known issue of not supporting the fallback feature. Apparently 
this was reported as a major bug in release notes of the beta version of 
the first 6.0 release and hasn't been addressed. The current 
documentation lists it as supported by default and tells you how to 
disable it if for some reason you don't want to allow fallback support.

<https://jira.atlassian.com/browse/CONFSERVER-44250>

XHR fallback has known issues when synchrony service is accessed via the 
synchrony-proxy web application.

Workaround is to ensure that browser traffic goes direct to synchrony 
instead of being routed via the confluence synchrony-proxy web 
application.


>> I have been searching the Squid documentation and can't find anything 
>> on
>> web sockets. Is it not supported in reverse proxy mode?
> 
> Indeed. 200 status is a "success" response from the origin. The data
> requested is still being delivered, just with HTTP instead of 
> WebSockets.
> 
> 
>> 
>> Currently running Squid 4.3, the cache peer for the specific server 
>> is.
>> 
>> cache_peer 10.20.10.25 parent 8490 0 ssl no-query no-digest 
>> originserver
>> name=confluence_parent sslcapath=/usr/local/share/certs
>> sslflags=DONT_VERIFY_PEER login=PASSTHRU front-end-https=on proxy-only
>> cache_peer_access confluence_parent allow CONFLUENCE SSL
>> cache_peer_access confluence_parent deny all
>> 
>> The confluence server is configured to use a proxy, and is aware that 
>> it
>> is there.
> 
> That could be the problem then. Why does the *server* need configuring
> to *use* a proxy?
> 
> Clients use a proxy to fetch requests. Servers *receive* requests from 
> a
> proxy.

The proxy configuration on the server tells it the hostname and port 
used on the proxy to properly rewrite the links.

> 
> 
> Amos
> _______________________________________________
> squid-users mailing list
> squid-users at lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-users

-- 
Thanks,
    Dean E. Weimer
    http://www.dweimer.net/