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...

[clokep]

I suppose you'd need to add the path to the server .well-known (and possibly the SRV results, somehow).

I recently became aware that CalDAV and CardDAV support specifying a path for server discovery using DNS SRV by also specifying a DNS TXT record with the same name that includes a string of path=/foo.

This is defined in RFC 6764, which defers some details to RFC 6763.

An example:

During server resolution, if a SRV record is found for _matrix-fed._tcp.matrix.org, also look up TXT for _matrix-fed._tcp.matrix.org, then search for a key-value pair of path= in the response strings.

[richvdh]

@uhoreg wrote:

A request for adding support for subpaths (particularly, adding something to federation discovery to support that) would be a separate issue.

There seems to be some inconsistency here: @turt2live has closed matrix-org/matrix-spec-proposals#1931 and #1625 as duplicates of this issue, despite being essentially requests for adding support for subpaths.

AFAICT, this is the canonical issue for "support for subpaths" in the matrix spec.