MSC4402: Consistent redirects for .well-known-files

[derhagen]

Rendered

This MSC fixes matrix-org/matrix-spec#445

---

SCT Stuff

MSC checklist

FCP tickyboxes

[turt2live]

Implementation requirements:

• Web client (following redirect)
• Native/non-web client (following redirect)
• Server (issuing redirect on client API)

[derhagen]

I think the only thing that needs to be implemented is the Clients following redirects.

[derhagen]

Would you like me to include this in the MSC?

[tulir]

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.

[tulir]

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)

[derhagen]

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.

[derhagen]

I just logged in to mozilla.org using Element Web, Fluffychat Web, as well as native GNOME Fractal. After creating a fresh account, I went through the login process with each mentioned client, and also went through key recovery until I was presented with an empty chat list. It worked as expected on all tested clients. The homeserver I specified was always mozilla.org.

Note that mozilla.org already serves a 301 response under .well-known/matrix/client, as proposed in this MSC.

For the record:

$ curl -I https://mozilla.org/.well-known/matrix/client

HTTP/2 301 
access-control-allow-headers: X-Requested-With, Content-Type, Authorization
access-control-allow-methods: GET, POST, PUT, DELETE, OPTIONS
access-control-allow-origin: *
cache-control: max-age=3600
content-length: 162
content-type: text/html
date: Wed, 11 Mar 2026 15:30:50 GMT
location: https://www.mozilla.org/.well-known/matrix/client
server: nginx
x-backend-server: TS
via: 1.1 google
alt-svc: h3=":443"; ma=2592000,h3-29=":443"; ma=2592000

[derhagen]

I did some extra testing with another instance serving a 307 response. Everything worked as expected using Element Web, Fluffychat Web, Cinny Web, as well as native GNOME Fractal. The hostname I specified was always *redacted*.eu

$ curl https://*redacted*.eu/.well-known/matrix/client -I
HTTP/2 307 
access-control-allow-origin: *
location: https://matrix.*redacted*.eu/.well-known/matrix/client
content-length: 18
date: Tue, 24 Mar 2026 16:12:54 GMT

[turt2live]

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.

[derhagen]

I haven't really read the MSC in too much detail, but "this is breaking" sounds scary 😬

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.

[turt2live]

The author believes this MSC is ready for FCP. Implementations need checking.

ref

[derhagen]

The author believes this MSC is ready for FCP. Implementations need checking.

ref

See #4402 (comment) for my notes on checking implementations.

[turt2live]

Overall this looks ready for proposed-FCP, thanks!

My comments are non-blocking for FCP to start.

[turt2live]

MSCs proposed for Final Comment Period (FCP) should meet the requirements outlined in the checklist prior to being accepted into the spec. This checklist is a bit long, but aims to reduce the number of follow-on MSCs after a feature lands.

SCT members: please check off things you check for, and raise a concern against FCP if the checklist is incomplete. If an item doesn't apply, prefer to check it rather than remove it. Unchecking items is encouraged where applicable.

MSC authors: feel free to ask in a thread on your MSC or in the#matrix-spec:matrix.org room for clarification of any of these points.

• Are appropriate implementation(s) specified in the MSC’s PR description?
• Are all MSCs that this MSC depends on already accepted?
• For each new endpoint that is introduced:
  • Have authentication requirements been specified?
  • Have rate-limiting requirements been specified?
  • Have guest access requirements been specified?
  • Are error responses specified?
    • Does each error case have a specified errcode (e.g. M_FORBIDDEN) and HTTP status code?
      • If a new errcode is introduced, is it clear that it is new?
• Will the MSC require a new room version, and if so, has that been made clear?
  • Is the reason for a new room version clearly stated? For example, modifying the set of redacted fields changes how event IDs are calculated, thus requiring a new room version.
• Are backwards-compatibility concerns appropriately addressed?
• Are the endpoint conventions honoured?
  • Do HTTP endpoints use_underscores_like_this?
  • Will the endpoint return unbounded data? If so, has pagination been considered?
  • If the endpoint utilises pagination, is it consistent with the appendices?
• An introduction exists and clearly outlines the problem being solved. Ideally, the first paragraph should be understandable by a non-technical audience.
• All outstanding threads are resolved
  • All feedback is incorporated into the proposal text itself, either as a fix or noted as an alternative
• While the exact sections do not need to be present, the details implied by the proposal template are covered. Namely:
  • Introduction
  • Proposal text
  • Potential issues
  • Alternatives
  • Dependencies
• Stable identifiers are used throughout the proposal, except for the unstable prefix section
  • Unstable prefixes consider the awkward accepted-but-not-merged state
  • Chosen unstable prefixes do not pollute any global namespace (use “org.matrix.mscXXXX”, not “org.matrix”).
• Changes have applicable Sign Off from all authors/editors/contributors
• There is a dedicated "Security Considerations" section which detail any possible attacks/vulnerabilities this proposal may introduce, even if this is "None.". See RFC3552 for things to think about, but in particular pay attention to the OWASP Top Ten.

[turt2live]

@mscbot fcp merge

[mscbot]

Team member @turt2live has proposed to merge this. The next step is review by the rest of the tagged people:

• @clokep
• @dbkr
• @uhoreg
• @turt2live
• @ara4n
• @anoadragon453
• @richvdh
• @tulir
• @erikjohnston
• @KitsuneRal

Once at least 75% of reviewers approve (and there are no outstanding concerns), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for information about what commands tagged team members can give me.

[Johennes]

Is this potentially problematic? If we merge this proposal, a server could only start using 30x-redirects if it controls all of its clients and can ensure that they've also implemented the new version of the spec. This seems feasible in a corporate setup but probably not in the public federation. It sounds a bit crazy but do we not need to version .well-known/matrix/client to prevent incompatibilities?

[derhagen]

I see your point, but given that mozilla has already been rolling this out in production and all the clients I tested so far worked fine with it, I don't think this will be problematic in practice.

The new wording is "Clients should follow 30x redirects" (similar to the wording in the Server-Server-API), so a server admin would hopefully be aware that a few clients might have chosen to not support such a redirect, anyway.

It might still make sense to introduce a versioned well-known like .well-known/matrix/v2/client, e.g. with Matrix 2.0, but if that's desired I think there should be another MSC about this.

[Johennes]

[...] all the clients I tested so far worked fine with it, I don't think this will be problematic in practice.

Ah ok. If clients seem to already value redirects today, I guess this will be fine.

[erikjohnston]

Also, the thing this breaks is auto-discovery of the actual homeserver URL to use when given a full user ID (or a server name). So the damage is limited to user's using clients that don't automatically follow redirects and are trying to login in with a full user ID.

Given that I think this is fine.