After update from 17.3 to 17.5 - Page edit doesn't work

@Pako, @cseeg, @Raphael_L I tested locally using SSL / HTTPS with a clean XWiki 17.5.0 and realtime editing works fine. I followed these steps, if anyone wants to try as well Setup SSL for XWiki running on Jetty+HSQLDB locally, on Ubuntu, for development / debugging purpose. · GitHub . Both Firefox and Chrome have no problems connecting to the secure WebSocket endpoint used to synchronize the content.

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

Hope this helps,
Marius

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)?

Thanks,
Marius

@Powl please check Realtime WYSIWYG behind reverse proxy - #14 by smarsching for some information on how to configure nginx in front of XWiki in order to have the realtime editing work.

The affected XWiki in our case has a reverse proxy (IIS) in front of Jetty.

BUT:

  • it did work before the upgrade to 17.4.0
  • we did not implement any changes to the reverse proxy
  • behaviour seems to affect nginx as well as IIS reverse proxy

This is why I suspect the XWiki code or some dependencies to be the culprit.

Have there been any updates on dependencies?

Regardless of that I will check the reverse proxy logs and see if I find anything in there.

Update:

After explicitly enabling and forwarding wss:// in IIS it works again.

It seems for whatever reason it used to work before the latest updates even though technically it shouldn’t have.

1 Like

Aha. After reading Realtime WYSIWYG behind reverse proxy - #14 by smarsching I enabled websockets support in my nginx proxy config, and now the issue is gone, on my personal wiki. I will try the same on the work wiki.

1 Like

This worked for us too, thanks for that.

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

I would like to try configuring it. What exactly do I have to do? I don’t know much about that kind of configuration.

Hello,

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.

Best regards, Karsten

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 .

More information on the topic can be found at Protocol upgrade mechanism - HTTP | MDN .

BTW, the forum thread I linked above has a post from a user that suggests what Apache configuration is needed Realtime WYSIWYG behind reverse proxy - #12 by smarsching . @Karsten have you checked that discussion? Have you tried that suggested configuration?

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.

1 Like

Thanks a lot. After activating the websocket support in NGINX everything is working as intended again. There is a Checkbox in every Proxy Host entry.

1 Like

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

1 Like

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.

Thanks!

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.

1 Like