Changed handling of web_client_location conflicts with recommended reverse proxy setup

[sumpfralle]

Description

In #11895 the redirect from /_matrix/client to the URL configured in web_client_location was moved to /.

In order to make this new location effective, the local administrator needs to adjust the currently recommended proxy setups, since these include only /_matrix/ and /_synapse/client/.

For example, the nginx setup would need to change in a single line:

< location ~ ^(/_matrix|/_synapse/client) {
> location ~ ^(/_matrix|/_synapse/client|/$) {

But the above change can be tricky for many site operators, since the / path may conflict with their regular (non-matrix) web services.

I conducted a quick survey of the servers listed at https://joinmatrix.org/ for their usage of the web_location_location feature (based on 91 matrix server entries; see the small shell script at the end of this issue):

• 30 servers (unkown) do not offer discovery via the .well-known/matrix/client endpoint (just ignore them)
• 7 servers (local) return a redirect to a relative destination path (probably not related to a Matrix web client)
• 24 servers (missing) do not return a redirect (probably this is just a regular web site - not related to Matrix)
• 6 servers (misleading) return an absolute redirect to a regular web site (probably not related to Matrix)
• 24 servers refer to a Matrix web client

I understand the results as follows:

• 60% (37 out of 61) servers use the / path for non-Matrix content
• 40% (24 out of 61) servers use the / path for redirecting to a Matrix web client

From my point of view there are two options for proceeding:

• A) stick to the / endpoint and update the reverse proxy documentation for this new path to be handed over to matrix-synapse
• B) switch to a "final" endpoint somewhere below /_matrix/ (maybe even back to /_matrix/client) in order to simplify the setup for site operators, which serve regular content below their configured base_url

Personally, I was mislead to using a regular (content) base_url for the dozen of Matrix homeservers, I administer. This was based on the neat reverse proxy setup, which clearly separated the Matrix content (/_matrix/) from the remaining content. Now I face the option of either changing the base_url and re-arrange the proxy setups or just miss out this nice discovery feature. Thus, I would prefer option (B).

---

For reference: I used the following quick approach for testing the Matrix servers published on joinmatrix.org:

curl -s https://joinmatrix.org/servers.json | jq -r '.[].domain' | grep -F . | while read -r domain; do base_url=$(curl -s --max-time 3 "https://$domain/.well-known/matrix/client" | jq -r '.["m.homeserver"]["base_url"]' 2>/dev/null) || { echo "$domain unknown"; continue; }; if ! printf '%s' "$base_url" | grep -q "^http"; then base_url="https://$base_url"; fi; destination=$(curl -s --include "$base_url/" | fromdos | grep -i "^location:" | cut -f 2 -d ' '); [ -z "$destination" ] && echo "$domain missing" && continue; printf '%s' "$destination" | grep -q "^/" && echo "$domain local" && continue; if curl -s "$destination" | grep -q matrixchat; then echo "$domain $destination"; else echo "$domain misleading"; fi; done

Steps to reproduce

• read https://github.com/matrix-org/synapse/blob/develop/docs/usage/configuration/config_documentation.md#web_client_location
• read https://github.com/matrix-org/synapse/blob/develop/docs/reverse_proxy.md#nginx
• notice the absence of / in the reverse proxy configuration

Homeserver

matrix.org

Synapse Version

1.74.0

Installation Method

I don't know

Database

irrelevant

Workers

Single process

Platform

irrelevant

Configuration

No response

Relevant log output

irrelevant

Anything else that would be useful to know?

No response

[clokep]

I'm a bit confused -- can you more concretely provide what you're using as the config for web_client_location?

Honestly hosting your web-client at the same domain as your Matrix server is usually not considered a good idea due to cookie sharing between domains.

[sumpfralle]

Thank you for your quick response!

I use it in the way it is described in the documentation:

The absolute URL to the web client which / will redirect to. Defaults to none.

Example configuration:

web_client_location: https://riot.example.com/

(i.e. the web client runs somewhere else - but the API endpoint provides a way to find it)

For the reference: I noticed this problem in our grouprise setup. (in case you are interested in the use-case of discovering the web client of a Matrix user)

[reivilibre]

I was going to review #14739 and to be honest, I'm a little bit confused here.

I would have thought the purpose of Synapse redirecting / to a web client somewhere else is lost once you have a reverse proxy in front of Synapse. (Why wouldn't you just configure a redirect in your reverse proxy, or configure it to serve some static content?)
I can only think that this feature in Synapse is to make it easier for servers without a reverse proxy, to provide some fallback content rather than just '404 not found' on the root.

I really don't think it's intended to be a necessary feature and I would hesitate encouraging people to route / to Synapse by default — as you say, Matrix traffic has been intentionally separated out under the /_matrix path.

[sumpfralle]

Thanks to @ankit-pn for preparing #14739 and to @reivilibre for initiating the discussion.

In my initial post I suggested two ways for solving the issue. Based on your input, I would add another one (C).

• A) Stick to the / endpoint and update the reverse proxy documentation for this new path to be handed over to matrix-synapse.
• B) Switch to a "final" endpoint somewhere below /_matrix/ (maybe even back to /_matrix/client) in order to simplify the setup for site operators, which serve regular content below their configured base_url.
• C) Stick to the / endpoint and mention in its documentation, that this feature requires additional changes in case of a reverse proxy setup.

Based on @reivilibre's comment, I guess, that (A) is out of question.

Since the matrix:// URI scheme (MSC2312) is somewhere on the horizon, I could imagine, that (C) is suitable in the long term.

Personally I would prefer (B), since it would work right now and thus, I could avoid maintaining manual mappings between Matrix homeservers and the locations of their public web clients.
(and maybe there are some use-cases, where a site-local redirect to a web client would still be of use - even after MSC2312)

What do you think?