Update configuring-well-known.md

Make use of `example.com` more consistent (replace `DOMAIN`) and simplify Caddy 2 config. Remove Caddy 1 config since Caddy 1 is long past EOL.
This commit is contained in:
Matt Holt 2022-07-19 16:31:01 -06:00 committed by GitHub
parent 5deda13f10
commit 2e02e694b4
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23

View file

@ -15,7 +15,7 @@ All services created by this playbook are meant to be installed on their own ser
As [per the Server-Server specification](https://matrix.org/docs/spec/server_server/r0.1.0.html#server-discovery), to use a Matrix user identifier like `@<username>:<your-domain>` while hosting services on a subdomain like `matrix.<your-domain>`, the Matrix network needs to be instructed of such delegation/redirection. As [per the Server-Server specification](https://matrix.org/docs/spec/server_server/r0.1.0.html#server-discovery), to use a Matrix user identifier like `@<username>:<your-domain>` while hosting services on a subdomain like `matrix.<your-domain>`, the Matrix network needs to be instructed of such delegation/redirection.
Server delegation can be configured using DNS SRV records or by setting up a `/.well-known/matrix/server` file on the base domain (`<your-domain.com>`). Server delegation can be configured using DNS SRV records or by setting up a `/.well-known/matrix/server` file on the base domain (`<your-domain>`).
Both methods have their place and will continue to do so. You only need to use just one of these delegation methods. Both methods have their place and will continue to do so. You only need to use just one of these delegation methods.
For simplicity reasons, our setup advocates for the `/.well-known/matrix/server` method and guides you into using that. For simplicity reasons, our setup advocates for the `/.well-known/matrix/server` method and guides you into using that.
@ -79,7 +79,7 @@ If you're managing the base domain by yourself somehow, you'll need to set up se
To make things easy for you to set up, this playbook generates and hosts 2 well-known files on the Matrix domain's server. The files are generated at `/matrix/static-files/.well-known/matrix/` and hosted at `https://matrix.example.com/.well-known/matrix/server` and `https://matrix.example.com/.well-known/matrix/client`, even though this is the wrong place to host them. To make things easy for you to set up, this playbook generates and hosts 2 well-known files on the Matrix domain's server. The files are generated at `/matrix/static-files/.well-known/matrix/` and hosted at `https://matrix.example.com/.well-known/matrix/server` and `https://matrix.example.com/.well-known/matrix/client`, even though this is the wrong place to host them.
You have 3 options when it comes to installing the files on the base domain's server: You have 4 options when it comes to installing the files on the base domain's server:
### (Option 1): **Copying the files manually** to your base domain's server ### (Option 1): **Copying the files manually** to your base domain's server
@ -116,12 +116,12 @@ With this method, you **don't need** to add special HTTP headers for [CORS](http
**For nginx**, it would be something like this: **For nginx**, it would be something like this:
```nginx ```nginx
# This is your HTTPS-enabled server for DOMAIN. # This is your HTTPS-enabled server for example.com.
server { server {
server_name DOMAIN; server_name example.com;
location /.well-known/matrix { location /.well-known/matrix {
proxy_pass https://matrix.DOMAIN/.well-known/matrix; proxy_pass https://matrix.example.com/.well-known/matrix;
proxy_set_header X-Forwarded-For $remote_addr; proxy_set_header X-Forwarded-For $remote_addr;
} }
@ -133,11 +133,11 @@ server {
```apache ```apache
<VirtualHost *:443> <VirtualHost *:443>
ServerName DOMAIN ServerName example.com
SSLProxyEngine on SSLProxyEngine on
ProxyPass /.well-known/matrix https://matrix.DOMAIN/.well-known/matrix nocanon ProxyPass /.well-known/matrix https://matrix.example.com/.well-known/matrix nocanon
ProxyPassReverse /.well-known/matrix https://matrix.DOMAIN/.well-known/matrix nocanon ProxyPassReverse /.well-known/matrix https://matrix.example.com/.well-known/matrix nocanon
# other configuration # other configuration
</VirtualHost> </VirtualHost>
@ -146,30 +146,10 @@ server {
**For Caddy 2**, it would be something like this: **For Caddy 2**, it would be something like this:
```caddy ```caddy
DOMAIN.com { example.com {
@wellknown { reverse_proxy /.well-known/matrix/* https://matrix.example.com {
path /.well-known/matrix/*:x header_up Host {upstream_hostport}
} }
handle @wellknown {
reverse_proxy https://matrix.DOMAIN.com {
header_up Host {http.reverse_proxy.upstream.hostport}
}
}
# Configration for the base domain goes here
# handle {
# header -Server
# encode zstd gzip
# reverse_proxy localhost:4020
# }
}
```
**For Caddy 1**, it would be something like this:
```caddy
proxy /.well-known/matrix/ https://matrix.DOMAIN {
header_upstream Host {http.reverse_proxy.upstream.hostport}
} }
``` ```
@ -196,7 +176,7 @@ backend matrix-backend
``` ```
# In the _redirects file in the website's root # In the _redirects file in the website's root
/.well-known/matrix/* https://matrix.DOMAIN/.well-known/matrix/:splat 200! /.well-known/matrix/* https://matrix.example.com/.well-known/matrix/:splat 200!
``` ```
**For AWS CloudFront** **For AWS CloudFront**
@ -206,7 +186,7 @@ backend matrix-backend
Make sure to: Make sure to:
- **replace `DOMAIN`** in the server configuration with your actual domain name - **replace `example.com`** in the server configuration with your actual domain name
- and: to **do this for the HTTPS-enabled server block**, as that's where Matrix expects the file to be - and: to **do this for the HTTPS-enabled server block**, as that's where Matrix expects the file to be