Proxy Health Check fails when using socket connection between Sliding Sync Proxy and Synapse

[Kimiblock]

Steps to reproduce

1. Start Sliding Sync Proxy using socket connection, e.g. SYNCV3_SERVER='/whatever/Synapse/Synapse.sock'
2. Open Element Web and enter Sliding Sync Proxy's address
3. Observe the error from proxyHealthCheck

Outcome

What did you expect?

Element should skip verification when using socket connection in SYNCV3_SERVER, or just add an option to continue anyways

What happened instead?

Element refuses to accept Sliding Sync Proxy's address.

Operating system

Arch Linux

Browser information

LibreWolf 120.0.1-1

URL for webapp

develop.element.io and im.kimiblock.top

Application version

Element version: 1.11.46-240-g655d6adb3 Crypto version: Olm 3.2.15

Homeserver

Synapse 1.98.0

Will you send logs?

Yes, but /rageshake doesn't seem to work

[t3chguy]

This check was added by the creator of the proxy @kegsay

[Kimiblock]

I understand the necessity of proxyHealthCheck's existence since people can easily screw up their sessions, but Sliding Sync Proxy supports socket connection and it'll make sense if we have an option to force proceeding.

[t3chguy]

More likely, the proxy should decouple the variable which is passed through to clients in server.json and the actual socket. As the clients knowing the internal path of the socket is not useful at all.

[kegsay]

Element-web shoudn't be doing this check nowadays. It was important in the early days during development, prior to .well-known having the proxy URL.

[t3chguy]

@kegsay the check isn't done for well-known, only for manual entry.

[Kimiblock]

I have the proxy defined in well known.

{
    "m.homeserver": {
        "base_url": "https://moechat.kimiblock.top"
    },
    "org.matrix.msc3575.proxy": {
        "url": "https://moechat.kimiblock.top"
    },
    "m.integrations": {
        "url": "example.org"
    }
}

[t3chguy]

https://im.kimiblock.top/ is too old then. 1.11.46 is 3 months old vs matrix-org/matrix-react-sdk#11936

[t3chguy]

Actually the well-known isn't read yet, so the above PR only considers "native" mode a-la Conduit, #22264 tracks the need to read the WK value