urlsrc is used verbatim from cached discovery, so the editor only works on one Nextcloud address

Summary

urlsrc is taken verbatim from Collabora's cached WOPI discovery document and used directly as the editor iframe's src. Because that value is an absolute URL, a Nextcloud instance reachable at more than one address can only ever open documents on one of them.

The chain

1. Service/DiscoveryService::getDiscoveryEndpoint() fetches /hosting/discovery from the single configured wopi_url, and the response is cached (CachedRequestService).
2. WOPI/Parser::getUrlSrcValue() returns the urlsrc attribute verbatim — the only transformation is str_replace('\.', '.', …).
3. That value reaches the front end as Config.get('urlsrc'), and src/helpers/url.js::getWopiUrl() concatenates it with the query parameters to form the iframe URL.
4. coolwsd emits an absolute URL in urlsrc, derived from the Host of the discovery request (or from server_name when set).

So the origin baked into step 4 is fixed for every user and every session, regardless of which address they actually reached Nextcloud on.

public_wopi_url does not help: Service/ConnectivityService::autoConfigurePublicUrl() derives it from urlsrc (domainOnly($determinedUrl)) to feed the CSP. It is an output of discovery, not an override of it.

Impact

Any deployment where Nextcloud is reachable at more than one origin — a LAN address and a public domain, a .onion, split-horizon DNS — gets a working editor on exactly one of them and a blank frame on the rest. Self-hosted setups hit this routinely.

Expected

A way to have the editor load same-origin, for deployments that reverse-proxy Collabora underneath the Nextcloud origin (/browser, /cool, /hosting). Either:

• an option to strip the scheme+host from urlsrc, leaving a root-relative URL the browser resolves against the current origin; or
• treat a configured public_wopi_url as an override applied to urlsrc, rather than a value derived from it.

Notes

A root-relative urlsrc appears to work with no other change: nothing in the path validates it as absolute, and AddContentSecurityPolicyListener already adds 'self' as a frame domain. domainOnly('/browser/…') returns '', which getDomainList()'s array_filter drops, so no stale CSP origin is added either.

I have this working by rewriting the discovery response in the reverse proxy (Apache mod_substitute, stripping the origin from urlsrc and favIconUrl) — documents open and edit correctly on every address simultaneously. That works, but it is a workaround for something that seems like it should be configurable.

Versions: richdocuments 11.1.0, Nextcloud 34.0.3, Collabora Online Development Edition 26.04.3.2.

Start by tracing Service/DiscoveryService::getDiscoveryEndpoint() through WOPI/Parser::getUrlSrcValue(), src/helpers/url.js::getWopiUrl(), and ConnectivityService::autoConfigurePublicUrl(). Compare the proposed same-origin and public_wopi_url approaches, then verify that documents open from multiple Nextcloud addresses while the existing CSP handling remains valid.