Confluence Collaborative Editing does not work with SSL and Apache 2.4.9 or earlier
Atlassian applications allow the use of reverse-proxies, however Atlassian Support does not provide assistance for configuring them. Consequently, Atlassian can not guarantee providing any support for them.
If assistance with configuration is required, please raise a question on Atlassian Answers.
This article only applies to Atlassian's server products. Learn more about the differences between cloud and server.
Confluence 6.x is configured with Apache 2.4 using SSL and Websockets as described in this guide: Securing your Atlassian applications with Apache using SSL
However, when trying to use collaborative editing, you get an error in the browser and the editor does not load.
- Confluence 6 or higher
- Apache 2.4.9 or earlier (Not Apache 2.2, as it does not support Websockets at all)
- If you are on Apache 2.2, please upgrade to the latest version of 2.4 and check if the issue persists
- SSL configured in Apache and/or Tomcat level
The appropriate modules are loaded, specifically mod_proxy_wstunnel.so
Looking at the web requests on your browser's developer tools, we see the following:
- Requests to Synchrony (e.g. https://servername.domain/synchrony/sockjs/v1/info?t=1485365) work and return a 200 OK status.
- Requests to Websockets (e.g. wss://servername.domain/synchrony/sockjs/v1/808/k1g3xete/websocket) return a 404 not found error.
- Confirm Apache is configured following our guides:
- Check that the proxy parameters have been added to your confluence_install/conf/server.xml file: Cross Site Request Forgery (CSRF) protection changes in Atlassian REST
Confirm the following modules are all loading properly from Apache:
LoadModule proxy_module /usr/lib/apache2/modules/mod_proxy.so LoadModule proxy_http_module /usr/lib/apache2/modules/mod_proxy_http.so LoadModule proxy_wstunnel_module /usr/lib/apache2/modules/mod_proxy_wstunnel.so LoadModule rewrite_module /usr/lib/apache2/modules/mod_rewrite.so
The following bug breaks the SSL handshake because it sends plain-text requests to the Websockets URL, as opposed to SSL requests: Plain-text request is sent to WSS URL (which should be over SSL) in mod_proxy_wstunnel
Workarounds are ways to temporally circumvent a problem, although it still exists in the application.
- A workaround is described in the following post from Stackoverflow: http://stackoverflow.com/a/22873747
Use a different proxy:
Upgrade to Apache 2.4.10 or higher. For some operating systems there is a fix available that has been tested using Apache version 2.4.6-45.