search

matrix-org / matrix-spec

The Matrix protocol specification
Apache License 2.0
188 stars 94 forks source link

handling a base URL with a sub-path is ambiguous #693

Open uhoreg opened 4 years ago

uhoreg commented 4 years ago

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 commented 4 years ago

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

uhoreg commented 4 years ago

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 commented 4 years ago

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 commented 1 year ago

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

uhoreg commented 1 year ago

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 commented 1 year ago

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 commented 4 months ago

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.