[Sliding Sync] Proxy specified in .well-known client file, domain is respected, path is ignored

[sidewinder94]

Steps to reproduce

1. Specify a sliding sync proxy in the well-known client file, under a path: (e.g. https://matrix.example.com/sliding-sync/)
2. Open element web and connect to your instance.
3. Open up the settings, navigate to experimental settings and scroll down to sliding sync. The setting cannot be enabled.

Outcome

What did you expect?

To be able to enable sliding sync by using the proxy announced by my well-known file.

What happened instead?

I cannot enable the sliding-sync feature because element does not fully respect the configured value.

Operating system

Windows

Browser information

Edge v125.0.2535.51

URL for webapp

Private server, element v1.11.67

Application version

No response

Homeserver

Synapse 1.107.0

Will you send logs?

Yes

[sidewinder94]

Some additional details:

I think I've managed to track down the issue to : https://github.com/matrix-org/matrix-react-sdk/blob/88e8e2df03b093277bcf4edd79542fb204208a7f/src/SlidingSyncManager.ts#L408

I put a breakpoint on this line in my browser, proxyUrl has the value configured in my .well-known file.

However, creating a spy to evaluate new URL("/client/server.json", proxyUrl), this displays a value ignoring any path specified in the .well-known.

To reuse my previous example:

proxyUrl = https://matrix.example.com/sliding-sync/
new URL("/client/server.json", proxyUrl) => https://matrix.example.com/client/server.json

Still in the spy, removing the / before client seem to generate an URL that respects the announced value

new URL("client/server.json", proxyUrl) => https://matrix.example.com/sliding-sync/client/server.json

[t3chguy]

The MSC description doesn't state that the proxy can be at a subpath, implying based on the HTTP path directly above the small note about the proxy server that they are at the root.

https://github.com/matrix-org/matrix-spec-proposals/blob/kegan/sync-v3/proposals/3575-sync.md#unstable-prefix

[sidewinder94]

This feels counter intuitive: if the functionality is natively supported, then sure, the HS should expose it at the address specified in the MSC.

However, the proxy is a separate piece of software. Which may be hosted on the same machine, and even on the same domain. It seems quite heavy handed to require a separate domain / port just for the sliding sync proxy instead of just a subpath.

And if you're referencing the small JSON example, I'm reading it as an example to present the expected structure of the document, not as a definition of the allowed (or forbidden values), I may be wrong about that. IMHO, allowed / forbidden values should be specified explicitely, not deduced from an example document.

[t3chguy]

I suggest asking the MSC to clarify otherwise this is stalled until such a time, closing in favour of the MSC.

[sidewinder94]

And how would one do to ask the MSC to clarify? An issue explicitly tells not to open issues in the matrix-spec-proposals repository.

There are a few matrix rooms listed in a README, but it feels like the wrong way to ask for a specification document clarification.

[t3chguy]

And how would one do to ask the MSC to clarify? An issue explicitly tells not to open issues in the matrix-spec-proposals repository.

inline comments on the MSC itself

[sidewinder94]

Will do, thank you Le jeu. 23 mai 2024, 16:57, Michael Telatynski ***@***.***> a écrit :

…

And how would one do to ask the MSC to clarify? An issue explicitly tells not to open issues in the matrix-spec-proposals repository. inline comments on the MSC itself — Reply to this email directly, view it on GitHub <#27496 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA47MMFLIWG5GB4MZX43AS3ZDX7UNAVCNFSM6AAAAABIFTAX6SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMRXGM2TENRUGI> . You are receiving this because you authored the thread.Message ID: ***@***.***>