mirror of
https://github.com/spantaleev/matrix-docker-ansible-deploy.git
synced 2026-07-13 18:31:11 +03:00
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 <noreply@anthropic.com>
This commit is contained in:
@@ -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:
|
||||
|
||||
|
||||
Reference in New Issue
Block a user