feat: Add setup checks and verify WOPI connectivity

[juliusknorr]

• Add a setup check to verify that we are running the latest Collabora release
• Add a setup check to verify connectivity with the collabora server
• Extend the connectivity checks with using the new Collabora endpoint to verify WOPI access (that Collabora can reach Nextcloud)

Fixes #4267

Needs CollaboraOnline/online#11162 for self-signed certificates that are not trusted on Collabora (without validation)

[juliusknorr]

@meven I'm struggling to get CI passing as when the check runs Collabora returns an UnspecifiedError, however the status code is a 200 as far as I see in the logs.

Do you have any clue why that is not passing?

wsd-00001-00032 2025-03-20 21:32:08.932036 +0000 [ websrv_poll ] DBG  #30: Handling request: /hosting/wopiAccessCheck, closeConnection false| wsd/ClientRequestDispatcher.cpp:700
  wsd-00001-00032 2025-03-20 21:32:08.932046 +0000 [ websrv_poll ] DBG  #30: Wopi Access Check request: /hosting/wopiAccessCheck| wsd/ClientRequestDispatcher.cpp:1140
  wsd-00001-00032 2025-03-20 21:32:08.932087 +0000 [ websrv_poll ] DBG  Connecting to 172.17.0.1:8081 (Unencrypted)| net/NetUtil.cpp:458
  wsd-00001-00032 2025-03-20 21:32:08.932105 +0000 [ websrv_poll ] DBG  #-1: starting asyncRequest: GET 172.17.0.1:8081 /status.php| net/HttpRequest.hpp:1340
  wsd-00001-00032 2025-03-20 21:32:08.932112 +0000 [ websrv_poll ] DBG  #30: Handled request: /hosting/wopiAccessCheck, inBuf[sz 231 -> 54, rm 177], connection open true| wsd/ClientRequestDispatcher.cpp:994
  wsd-00001-00022 2025-03-20 21:32:08.932537 +0000 [ asyncdns ] DBG  #31: Created socket. Thread affinity set to 0x7fd3450006c0, Socket[#31, IPv4 @ :0]| net/Socket.hpp:474
  wsd-00001-00022 2025-03-20 21:32:08.932558 +0000 [ asyncdns ] DBG  #31 New socket connected to 172.17.0.1:8081 (Unencrypted)| net/NetUtil.cpp:517
  wsd-00001-00032 2025-03-20 21:32:09.116401 +0000 [ websrv_poll ] DBG  #31: Closed after reading. Read result: 0 errno: 0| net/Socket.hpp:1515
  wsd-00001-00032 2025-03-20 21:32:09.116470 +0000 [ websrv_poll ] DBG  #30: Wopi Access Check: got response state: State::Error , response status code: 200 (OK) , last errno: 0| wsd/ClientRequestDispatcher.cpp:1316
  wsd-00001-00032 2025-03-20 21:32:09.116522 +0000 [ websrv_poll ] INF  #30: Wopi Access Check request, result: UnspecifiedError| wsd/ClientRequestDispatcher.cpp:1226
  wsd-00001-00032 2025-03-20 21:32:09.116552 +0000 [ websrv_poll ] DBG  #31: Closed socket Socket[#31, IPv4 @ :0]| net/Socket.hpp:171
  wsd-00001-00032 2025-03-20 21:32:09.116588 +0000 [ websrv_poll ] DBG  #30: Closed socket Socket[#30, IPv6 @ ::ffff:172.18.0.1:64643]| net/Socket.hpp:171

[juliusknorr]

@meven Any further hint? Would be great to get this in

[meven]

@meven Any further hint? Would be great to get this in

Thank you for the ping, was really busy back in March.

  wsd-00001-00032 2025-03-20 21:32:09.116470 +0000 [ websrv_poll ] DBG  #30: Wopi Access Check: got response state: State::Error , response status code: 200 (OK) , last errno: 0| wsd/ClientRequestDispatcher.cpp:1316

Points toward an explicit error contacting the wopi/nextcloud host.
The error could be improved, the fact the response Status code is 200 might point toward a bug.

This might be a bug in the insecure/HTTP code path.

Looking

[meven]

I haven't managed to find the origin.
With 25.04, code has changed, would be curious to know if that changes something.
A bit busy ATM, will be back on it.

[juliusknorr]

I'll do a rebase to see if the nightly code build now behaves different (that is one built from online master branch)

[meven]

It seems like your callballUrl request's response was empty and wasn't in one of the three case:

• Response code was 10*
• Response code was 204 (https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/204)
• Header had Content-Length = 0
• The answer body had any content ("OK" for instance)

Consequently our http client considered this answer erroneous, as it prematurely disconnected.

(A 200 with no Content-Length, must have some content, as 204 is to be used when no Content is needed).

A curl -v request to your callback to your endpoint should reveal it.

Thanks @Ashod for helping on this.

[juliusknorr]

Thanks that is very helpful, let me push a step in CI run run that curl.

Content-Length missing rings a bell (https://cweiske.de/tagebuch/content-length-header-missing.htm) and locally i do see it sent back as a response header.

[juliusknorr]

Yes, it seems that when running the tests with the built-in webserver in CI we have a content but no content length.

I'm not sure that is expected as the response header should be optional even if we have some body.

I'll test if the tests pass if i switch to an empty response with 204 instead

 [4351] [Wed Jun  4 16:23:54 2025] [::1]:38488 [200]: GET /status.php
< HTTP/1.1 200 OK
< Host: localhost:8081
< Date: Wed, 04 Jun 2025 16:23:54 GMT
< Connection: close
< X-Powered-By: PHP/8.1.32
< Content-Security-Policy:default-src 'self'; script-src 'self' 'nonce-9WBcjYjKqk8FWft6yHCr/3ufHhm2GuyxynXmlilspWA='; style-src 'self' 'unsafe-inline'; frame-src *; img-src * data: blob:; font-src 'self' data:; media-src *; connect-src *; object-src 'none'; base-uri 'self';
< Referrer-Policy: no-referrer
< X-Content-Type-Options: nosniff
< X-Frame-Options: SAMEORIGIN
< X-Permitted-Cross-Domain-Policies: none
< X-Robots-Tag: noindex, nofollow
< X-XSS-Protection: 1; mode=block
< Set-Cookie: nc_sameSiteCookielax=true; path=/; httponly;expires=Fri, 31-Dec-2100 23:59:59 GMT; SameSite=lax
< Set-Cookie: nc_sameSiteCookiestrict=true; path=/; httponly;expires=Fri, 31-Dec-2100 23:59:59 GMT; SameSite=strict
< Access-Control-Allow-Origin: *
< Content-Type: application/json

@Ashod

[meven]

Yes, it seems that when running the tests with the built-in webserver in CI we have a content but no content length.
I'm not sure that is expected as the response header should be optional even if we have some body.

It should be optional if you have some body (http streaming then), which coolwsd can detect. The only condition then, is the socket not to be closing with data mid-flight (as for other cases).
If not that's a bug on coolwsd side.
I am looking into it.

[meven]

I'll test if the tests pass if i switch to an empty response with 204 instead

Did you have the time for this ?

[juliusknorr]

Rebased again, Ci should tell if that makes a difference

[meven]

Failed to verify WOPI connectivity
The Collabora server could not properly reach the Nextcloud server at http://172.17.0.1:8081/ The host for this request is not allowed to be used as a WOPI Host, this is likely a configuration issue in coolwsd.xml

From https://github.com/nextcloud/richdocuments/actions/runs/18386970418/job/52387713241?pr=4470

Is that a valid failure case, or is it that the Collabora instance has no wopi host set ?
Just as a reminder Wopi host is set to host of the first incoming request by default.
If a second host is needed it needs to be set in coolwsd.xml host (this can be done through command-line too).

[juliusknorr]

For the integration test that was the case. The interesting failure is in the cypress ones:

https://github.com/nextcloud/richdocuments/actions/runs/18386970434/job/52387705950?pr=4470

Checking configuration
🛈 Configured WOPI URL: http://localhost:9980
🛈 Configured public WOPI URL: http://localhost:9980
🛈 Configured callback URL: http://172.17.0.1:8081/

✓ Fetched /hosting/discovery endpoint
✓ Valid mimetype response
✓ Valid capabilities entry
✓ Fetched /hosting/capabilities endpoint
✓ Detected WOPI server: Collabora Online Development Edition 25.04.7.0
[5002] [Thu Oct  9 19:33:37 2025] 172.18.0.2:35734 Accepted
[5002] [Thu Oct  9 19:33:37 2025] 172.18.0.2:35734 [200]: GET /status.php
[5002] [Thu Oct  9 19:33:37 2025] 172.18.0.2:35734 Closing
Failed to verify WOPI connectivity
The Collabora server could not properly reach the Nextcloud server at http://172.17.0.1:8081/ Unknown error "UnspecifiedError". Check the server logs of Collabora for more details.

You can also find the Collabora logs there if you unfold the stop container step:

[meven]

For the integration test that was the case. The interesting failure is in the cypress ones:

https://github.com/nextcloud/richdocuments/actions/runs/18386970434/job/52387705950?pr=4470

Checking configuration
🛈 Configured WOPI URL: http://localhost:9980
🛈 Configured public WOPI URL: http://localhost:9980
🛈 Configured callback URL: http://172.17.0.1:8081/

✓ Fetched /hosting/discovery endpoint
✓ Valid mimetype response
✓ Valid capabilities entry
✓ Fetched /hosting/capabilities endpoint
✓ Detected WOPI server: Collabora Online Development Edition 25.04.7.0
[5002] [Thu Oct  9 19:33:37 2025] 172.18.0.2:35734 Accepted
[5002] [Thu Oct  9 19:33:37 2025] 172.18.0.2:35734 [200]: GET /status.php
[5002] [Thu Oct  9 19:33:37 2025] 172.18.0.2:35734 Closing
Failed to verify WOPI connectivity
The Collabora server could not properly reach the Nextcloud server at http://172.17.0.1:8081/ Unknown error "UnspecifiedError". Check the server logs of Collabora for more details.

You can also find the Collabora logs there if you unfold the stop container step:

For the integration test that was the case. The interesting failure is in the cypress ones:

https://github.com/nextcloud/richdocuments/actions/runs/18386970434/job/52387705950?pr=4470

Checking configuration
🛈 Configured WOPI URL: http://localhost:9980
🛈 Configured public WOPI URL: http://localhost:9980
🛈 Configured callback URL: http://172.17.0.1:8081/

✓ Fetched /hosting/discovery endpoint
✓ Valid mimetype response
✓ Valid capabilities entry
✓ Fetched /hosting/capabilities endpoint
✓ Detected WOPI server: Collabora Online Development Edition 25.04.7.0
[5002] [Thu Oct  9 19:33:37 2025] 172.18.0.2:35734 Accepted
[5002] [Thu Oct  9 19:33:37 2025] 172.18.0.2:35734 [200]: GET /status.php
[5002] [Thu Oct  9 19:33:37 2025] 172.18.0.2:35734 Closing
Failed to verify WOPI connectivity
The Collabora server could not properly reach the Nextcloud server at http://172.17.0.1:8081/ Unknown error "UnspecifiedError". Check the server logs of Collabora for more details.

You can also find the Collabora logs there if you unfold the stop container step:

We can see in the logs that curl -v 172.17.0.1:8081/status.php returns 400 :

* Connected to 172.17.0.1 (172.17.0.1) port 8081
> GET /status.php HTTP/1.1
> Host: 172.17.0.1:8081
> User-Agent: curl/8.5.0
> Accept: */*
> 
[5002] [Thu Oct  9 19:33:34 2025] 10.197.43.98:58716 Accepted
[5002] [Thu Oct  9 19:33:34 2025] 10.197.43.98:58716 [400]: GET /status.php
< HTTP/1.1 400 Bad Request
< Host: 172.17.0.1:8081
< Date: Thu, 09 Oct 2025 19:33:34 GMT
< Connection: close
< X-Powered-By: PHP/8.2.29
< Content-Security-Policy:default-src 'self'; script-src 'self' 'nonce-GwaA7Hz0A+QiPtELP3PbPRvWlUzQ2lo8kPRVuB3chRw='; style-src 'self' 'unsafe-inline'; frame-src *; img-src * data: blob:; font-src 'self' data:; media-src *; connect-src *; object-src 'none'; base-uri 'self';
< Referrer-Policy: no-referrer
< X-Content-Type-Options: nosniff
< X-Frame-Options: SAMEORIGIN
< X-Permitted-Cross-Domain-Policies: none
< X-Robots-Tag: noindex, nofollow
< Set-Cookie: nc_sameSiteCookielax=true; path=/; httponly;expires=Fri, 31-Dec-2100 23:59:59 GMT; SameSite=lax
< Set-Cookie: nc_sameSiteCookiestrict=true; path=/; httponly;expires=Fri, 31-Dec-2100 23:59:59 GMT; SameSite=strict
< Content-Type: application/json

I checked the current wopiAccesCheck should send NotHttpSuccess, but it doesn't, I am checking if there is a bug.