Well I got it to work.
“Not so sure” if this is the correct way so use this advice with caution.
I went back to my test instance where it did work and started implementing the config with the live instance as an example.
The content violation turned out not be be blocking the document page from loading but it does leak internal names to the world.
I did solve that issue in a rather hacky way.
- I created an entry in the host file of the reverse-proxy with the same host-name as the one that points to the reverse-proxy itself (yes that’s rather shifty).
- With this host-name spoof in place I could configure nginx to proxy the requests to the actual NextCould instance but using the host-name of the proxy in the request.
- If you then remove the overwritehost entry (if you have one) from the NextCloud config.php it will use the host-name from the incoming request and suddenly richdocuments no longer uses the wrong host-name.
There is probably a less janky way of getting nginx to put a specific host-name in the request headers. The key here is to not rely on the overwritehost feature to fix your reverse-proxy host-name issue but rather to get NextCloud to use the host-name given in the http request.
Of course this is still a workaround the richdocuments app has a bug in it. Or this is by design as built-in-CODE is not meant for commercial use, so ommit reverse-proxy compatibility? (it was already reported some time ago but no fix) Though most home implementation would need a reverse-proxy because they only have one public IP.
Now on to what was actually blocking the document page from loading.
In the NextCloud office config page you have a field “Allow list for WOPI requests” I had that set to 127.0.0.1 obviously I should have added the IP of the reverse-proxy to that list as well.
That resolved the issue.