Now, I don’t have a (reverse) proxy in front of my local XWiki (Jetty) instance. Each proxy has its own config, and it’s not easy to replicate your setup. Can you please confirm that you use a proxy? In this case it is very important that HTTP(S)-To-WebSocket upgrade requests are properly forwarded to the servlet container running XWiki (Jetty / Tomcat). If I understand correctly:
you upgraded XWiki from 17.3 to 17.5 without changing the proxy configuration
realtime editing was working before and stopped working after the upgrade
But I don’t see which change done between 17.3 and 17.5 could cause this…
@Powl your problem seems to be different. You’re not using SSL/HTTPS (secure connection) and @Pako confirmed that for them, it works with non-secure connection. Has the realtime editing worked before for you? Did you upgrade XWiki recently? If not, then you most probably need to check your nginx configuration to make sure ws:// requests are properly forwarded to XWiki. I don’t know nginx that well, but you need to search for “how to forward WebSocket requests in nginx”.
Are you using SSL/HTTPS to connect to your personal / work wiki? Have you upgraded recently to XWiki 17.5? Has realtime editing worked before for you? Do you have a proxy (Apache / nginx) in front of XWiki? If you do, does it work when accessing XWiki directly (skipping the proxy)?
If anyone has a working tomcat10/apache2 proxy config that correctly forwards ws I would be grateful to see it (too dumb to figure it out myself unfortunately).
the same problem when updating from 17.4.0. to 17.4.2
Apache Webserver with Tomcat 10 is also the combination for us.
Localhost on the server without Apache is working.
Unfortunately, I have not yet understood what to do.
Can someone explain this in simple words.
That’s what I tried to do above. Can you be more specific and indicate what part is not clear? I don’t have much experience in configuring Apache, but if I were you I would start from apache proxy forward websocket requests at DuckDuckGo .
Thank you very much for your help. I have read the linked discussion.
But sometimes it’s better to recognize your own limits. I’d better wait until our Apache admin is back from vacation.
Many thanks for XWiki! It is a great software for us.
Thank you for link and support. The Apache configuration was successfully updated (different applications on it made this somewhat more complex). It works wonderfully again.
@mflorea I’d really like to understand if we changed something between 17.4.0 and 17.4.2 that would cause the issue raised. @Karsten you’re sure it was working fine in 17.4.0 and your 17.4.2 setup was the same, without anything configured differently? Thx
Configuring the proxy to properly forward WebSocket requests was needed before 17.4.0, as proven by this thread Realtime WYSIWYG behind reverse proxy that is 2 years old, if you wanted to use realtime. The users that have complained were not using realtime editing before upgrading. The change between 17.4.0 and 17.4.2 is that we’re now waiting for the realtime connection to be established before allowing the user to edit. Normally, failing to connect to the realtime WebSocket end-point should fall back to editing alone (outside realtime), BUT the problem is that the bad WebSocket request forwarded by the HTTP proxy in front of XWiki is not seen as a failed request.. The browser (i.e. the JavaScript code) appears to connect and quickly disconnect to the WebSocket end-point, which leads to an indefinite number of retries. I reported Loading... .
Ok. I have replied on a thread (don’t remember which one) where the use had no problem and when editing he was seeing the RT save bar, and when he upgraded, it started not working. I assumed that they were using RT since they had the RT save bar.
For us, it always looked the same as it does now when I exit editing with “Exit collaboration”.
I think you misunderstood. @Karsten said that the edit mode they used before is the one you now get when leaving realtime editing. So they were editing alone, outside realtime.