Rejecting WebSocket upgrade

[R053NR07]

Describe the Bug

Collabora is running as Container behind an nginx proxy. The specified server_name is collabora.example.org:443. When trying to open a document the collabora server rejects the WebSocket Upgrade with following error log:

wsd-01159-01289 2025-06-05 12:24:20.855554 +0000 [ websrv_poll ] ERR  #17: Rejecting WebSocket upgrade with: origin [https://collabora.example.org] expected [https://collabora.example.org:443] instead| net/WebSocketHandler.hpp:1037

Steps to Reproduce

1. Run a collabora server with version cp-25.04.2-2 (or another version which has commit b86a1bf active)
2. Setup an Nginx frontproxy with SSL Termination active; let it listen on the standard Port 443
3. Open an Document in Nextcloud

Expected Behavior

The document should open for editing.

Actual Behavior

Loading the document fails with frontend error:

Socket-Verbindung konnte nicht hergestellt werden oder Socket-Verbindung wurde unerwartet geschlossen. Der Reverse-Proxy ist möglicherweise falsch konfiguriert. Bitte wenden Sie sich an den Administrator. Weitere Informationen zur Proxy-Konfiguration finden Sie unter https://sdk.collaboraonline.com/docs/installation/Proxy_settings.html

and an error log in the collabora backend:

wsd-01159-01289 2025-06-05 12:24:20.855554 +0000 [ websrv_poll ] ERR  #17: Rejecting WebSocket upgrade with: origin [https://collabora.example.org] expected [https://collabora.example.org:443] instead| net/WebSocketHandler.hpp:1037

Desktop

(Please complete the following information)

• Collabora version: 25.04.2-2
• OS and version: Debian Bullseye
• Browser and version: Firefox

Additional Context

As mentioned above I believe b86a1bf causes the issue by introducing origin checks. For me it's not possible to get the origin with the port attached to it since the standard port 443 is truncated from the request. This causes the check to fail and the upgrade to reject.

In my case the setup runs in Kubernetes behind an nginx ingress. For me it's not possible to use another port than 443.

[pm20973]

The exact same issue on our end. We use an Ubuntu Distro and have it installed locally on the server not via docker/kubernetes with apache2 as reverse proxy.

I will check if another (non-standard) port bypasses the error.

[kmbuthia]

Exact same issue here as well. I suspect this PR broke things...and there's a comment there that alludes to this potentially breaking people's installations: https://github.com/CollaboraOnline/online/pull/11471 The change is not friendly for setups that use reverse-proxies that automatically manipulate headers like "Origin".

Anyway, since my instance is deployed with Docker, downgrading to collabora/code:24.04.13.2.1 fixed the issue for me.

[pm20973]

The exact same issue on our end. We use an Ubuntu Distro and have it installed locally on the server not via docker/kubernetes with apache2 as reverse proxy.

I will check if another (non-standard) port bypasses the error.

So from our end a change of the standard port is not a solution. And thx @kmbuthia it really seems to be a problem with the new change for cpp check. Yeah, we also could only downgrade again to get the instance working again, no other solution or "work around" could be applied for a quick solution.

[benedikt-s]

I'm experiencing the same issue, with Apache 2.4 as SSL-terminating reverse proxy.

This workaround in the Apache config – rewriting the Origin header to include the port – solved it for me:

RequestHeader set Origin "https://collabora.example.org:443" "expr=%{req_novary:Origin} == 'https://collabora.example.org'"

A proper fix would be much appreciated, though ...

[hagak]

Same issue here using the helm chart behind nginx-ingress setup. Revert back to v24 until a proper fix is made.

[R053NR07]

A workaround for nginx equivalent to @benedikt-s approach is something like:

more_set_input_headers "Origin: $http_origin:443";

[fluboi]

A easy workaround with nginx is to add on the reverse proxy: proxy_set_header Origin '$http_origin:443';

Using more_set_input_headers as suggested by @R053NR07 might also work, but require headers-more module

[benedikt-s]

A word of caution for these nginx workarounds: As they unconditionally set the header, they undermine the functionality of the Origin header as the server now cannot detect when an illegal origin is used! Whether this actually poses a serious security threat here I can't estimate, most likely it's neglectable... but you should be aware.

[caolanm]

In the origin check, expanding default ports out sounds like a reasonable thing to do that would resolve the initial issue I imagine

[caolanm]

I think that should resolve this