Search squid archive

Re: Web Socket Support For Reverse Proxy

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users

--
Thanks,
   Dean E. Weimer
   http://www.dweimer.net/
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users




[Index of Archives]     [Linux Audio Users]     [Samba]     [Big List of Linux Books]     [Linux USB]     [Yosemite News]

  Powered by Linux