Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
uhoreg opened this issue Sep 18, 2020 · 7 comments
Open

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

uhoreg opened this issue Sep 18, 2020 · 7 comments
Labels
A-Client-Server Issues affecting the CS API clarification An area where the expected behaviour is understood, but the spec could do with being more explicit

Comments

@uhoreg
Copy link
Member

uhoreg commented Sep 18, 2020

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
Copy link
Member

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

@turt2live turt2live added clarification An area where the expected behaviour is understood, but the spec could do with being more explicit A-Client-Server Issues affecting the CS API labels Sep 18, 2020
@uhoreg
Copy link
Member Author

uhoreg commented Sep 18, 2020

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
Copy link
Member

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
Copy link

Thatoo commented Jun 26, 2023

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
Copy link
Member Author

uhoreg commented Aug 2, 2023

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
Copy link

Thatoo commented Aug 2, 2023

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
Copy link
Member

clokep commented May 15, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-Client-Server Issues affecting the CS API clarification An area where the expected behaviour is understood, but the spec could do with being more explicit
Projects
None yet
Development

No branches or pull requests

4 participants