handling a base URL with a sub-path is ambiguous

[uhoreg]

particularly with .well-known. If a base URL of https://example.com/foo is specified, should the client use https://example.com/foo/_matrix/... or https://example.com/_matrix/ (because URL joining usually drops the last path component if it doesn't end with a /)

[turt2live]

arguably the spec doesn't allow subpathing given all the paths are defined as /_matrix, and thus an absolute.

[uhoreg]

arguably the spec doesn't allow subpathing given all the paths are defined as /_matrix, and thus an absolute.

That would also be an acceptable clarification, if that's what we decide to go with.

[turt2live]

tbh the best route might be to just MSC the desired behaviour and clarify it that way. I don't think treating them as absolute is a good idea because that's overly restrictive.

[Thatoo]

Any news on this subject?
As I understood it, it forbids the possibility to share from nextcloud to matrix for exemple : gary-kim/riotchat#369 and nextcloud/server#28226

[uhoreg]

Allowing subpaths would be difficult because federation discovery doesn't allow for a subpath to be specified. So it's likely that the current answer is just "subpaths are not allowed".

This issue is only about the ambiguity of how to handle the property in the Client-Server discovery. A request for adding support for subpaths (particularly, adding something to federation discovery to support that) would be a separate issue.

[Thatoo]

In case it helps to move forward, I copy paste here an answer that has been given in the Office of the MSC Team room :

I suppose you'd need to add the path to the server .well-known (and possibly the SRV results, somehow).
And ideally still host the .well-known at the top-level...