-
Notifications
You must be signed in to change notification settings - Fork 424
MSC4402: Consistent redirects for .well-known-files #4402
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
base: main
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Implementation requirements:
- Web client (following redirect)
- Native/non-web client (following redirect)
- Server (issuing redirect on client API)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the only thing that needs to be implemented is the Clients following redirects.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would you like me to include this in the MSC?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This thread is part of the MSC process rather than a suggestion. In order for the MSC to be considered for merging, appropriate implementations have to be linked in this comment thread (not in the markdown file)
I think in this case the first two bullets might have been a misinterpretation of the MSC though, because the MSC doesn't touch federation .well-known, it just references that as something which already supports redirects.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've updated the list to remove the server following redirect parts and split the client into two items, because web clients and native clients work fairly differently (web clients tend to always follow redirects, but all redirects must have CORS. Native clients may need to implement redirect following manually, but they don't care about CORS)
(also, implementations can just be confirming that something already works and perhaps pointing to the relevant existing code rather than writing new code)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Alright, but you can even remove "Server (issuing redirect on client API)" I guess. In this scenario, the redirect would be set up manually by whoever has access to the webserver behind the base domain.
turt2live
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I haven't really read the MSC in too much detail, but "this is breaking" sounds scary 😬
This review is for an early pass of the checklist.
Signed-off-by: Hagen Echzell <[email protected]>
Signed-off-by: Hagen Echzell <[email protected]>
Signed-off-by: Hagen Echzell <[email protected]>
Note that it only breaks backwards-compatibility for server-client interaction and only in settings where the admin explicitly chooses to make use of a well-known-redirect. Since the new wording is "Clients should follow 30x redirects", admins are made aware that a redirect might not work with all clients. In enterprise settings, this doesn't matter, because a server admin mandates the client to use, anyway. Server admins who can't mandate the client need to wait with using redirects until this change has been broadly implemented. |
Signed-off-by: Hagen Echzell <[email protected]>
Signed-off-by: Hagen Echzell <[email protected]>
Rendered
This MSC fixes matrix-org/matrix-spec#445