From 90d486c4f6808d4bc372dbfe46cba5043f8ff666 Mon Sep 17 00:00:00 2001 From: Slavi Pantaleev Date: Mon, 13 Jul 2026 16:35:07 +0300 Subject: [PATCH] Correct CORS guidance for 302-redirect based well-known setup The docs claimed that reverse-proxying "or simply a 302 redirect" needs no CORS headers. That is only true for reverse-proxying: browsers apply CORS checks to every response in a redirect chain, so a redirect response itself must also carry Access-Control-Allow-Origin, otherwise web clients fail even though the final destination sets the header. Fixes #4650 Co-Authored-By: Claude Fable 5 --- docs/configuring-well-known.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/docs/configuring-well-known.md b/docs/configuring-well-known.md index a2561f90e..c6623e2f5 100644 --- a/docs/configuring-well-known.md +++ b/docs/configuring-well-known.md @@ -112,7 +112,9 @@ This option is less fragile and generally better. On the base domain's server (e.g. `example.com`), you can set up reverse-proxying (or simply a 302 redirect), so that any access for the `/.well-known/matrix` location prefix is forwarded to the Matrix domain's server (e.g. `matrix.example.com`). -With this method, you **don't need** to add special HTTP headers for [CORS](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS) reasons (like `Access-Control-Allow-Origin`), because your Matrix server (where requests ultimately go) will be configured by this playbook correctly. +With reverse-proxying, you **don't need** to add special HTTP headers for [CORS](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS) reasons (like `Access-Control-Allow-Origin`), because your Matrix server (where requests ultimately go) will be configured by this playbook correctly. + +If you use a 302 redirect instead, be aware that browsers apply CORS checks to every response in the redirect chain, so the redirect response itself must also carry an `Access-Control-Allow-Origin: *` header. Otherwise, web-based Matrix clients (like Element Web) may fail to work even though the final destination sets the header correctly. **For nginx**, it would be something like this: