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
