Web Socket Support For Reverse Proxy

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Web Socket Support For Reverse Proxy

dweimer
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

I have been searching the Squid documentation and can't find anything on
web sockets. Is it not supported in reverse proxy mode?

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. There instructions only discuss settings specific to Nginx and
Apache, in both cases the Confluence connector is the same the
difference is the settings for Nginx and Apache.

--
Thanks,
    Dean E. Weimer
    http://www.dweimer.net/
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Web Socket Support For Reverse Proxy

Amos Jeffries
Administrator
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.


> 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.


> There instructions only discuss settings specific to Nginx and
> Apache, in both cases the Confluence connector is the same the
> difference is the settings for Nginx and Apache.
>


Amos
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Web Socket Support For Reverse Proxy

dweimer
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
> [hidden email]
> http://lists.squid-cache.org/listinfo/squid-users

--
Thanks,
    Dean E. Weimer
    http://www.dweimer.net/
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users