WOPI "edit" action returns 404 ("Cannot GET") in v9.3.2 Docker image despite being advertised in /hosting/discovery

[georgfleiter]

Summary

The WOPI hosting "edit" action for .docx (and presumably other WOPI-hosted formats) returns an Express 404 ("Cannot GET ...") when navigated to directly, even though the exact same URL template is advertised as valid in /hosting/discovery.

Environment

• Image: ghcr.io/euro-office/documentserver:v9.3.2
• (digest sha256:5a1a8b7083856b309f09a5b06aa96f80182cbdfccddcae6c082ecf7a2b3cbf2b, identical to :latest at time of testing)
• Docker Compose deployment, own WOPI host implementation (CheckFileInfo/GetFile/PutFile per spec) reachable via internal Docker DNS
• Confirmed as a regression: the identical request succeeds against onlyoffice/documentserver:9.4.0.1

Steps to Reproduce

1. Run the image with a working WOPI host.
2. Query /hosting/discovery -- it advertises an edit action for ext="docx", e.g.:
3. Navigate a browser (GET) to that exact URL template, filled in with a valid WOPISrc (URL-encoded pointer to your WOPI host's /wopi/files/{id}) and a valid access_token: http:///hosting/wopi/word/edit?WOPISrc=&access_token=

Expected Behavior

The editor HTML page loads, and DocService subsequently calls CheckFileInfo on the
WOPI host -- exactly as it does with OnlyOffice 9.4.0.1 for the identical request.

Actual Behavior

The server responds with a 404 and the plain-text Express default page:

Cannot GET /hosting/wopi/word/edit

No CheckFileInfo request is ever made to the WOPI host (confirmed via host-side access logs) -- the request fails before reaching any WOPI logic.

Additional Notes

• This is a different bug from the proof-key-signing issue (Bug: WOPI broken: entrypoint.sh writes wopi.privateKey with literal \n instead of real newlines → DECODER routines::unsupported #177 / WOPI proof key generation stores escaped newlines in local.json, causing checkFileInfo to fail #251) -- this build does not exhibit that bug; this looks like aa separate, newer regression.
• Possibly related to the Node.js 20->22 upgrade mentioned in the v9.3.2 changelog, if

that changed how Express routes are registered/compiled in the pkg snapshot build.

• Same request pattern works correctly against onlyoffice/documentserver:9.4.0.1.

Screenshot attached showing the rendered "Cannot GET" response.