You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When Synapse is approached with an OPTIONS request, it responds 204, always. It should be returning 404 M_UNRECOGNIZED for endpoints which don't exist at all, and 405 M_UNRECOGNIZED for non-client-server endpoints which do exist, as per the M_UNRECOGNIZED description at https://spec.matrix.org/v1.10/client-server-api/#common-error-codes
Synapse's current behaviour can cause endpoint discovery to be unreliable. For example, matrix-org/matrix-react-sdk#12492 aims to use OPTIONS to discover sliding sync, but because Synapse always returns a success code, the react-sdk thinks sliding sync is supported (even though it's not, as of writing).
The `OPTIONS` approach from #12492 doesn't work because Synapse *always* responds with 204 (success) to `OPTIONS` requests, as described here: element-hq/synapse#17153
We further can't use `HEAD` because it's not part of the allowed CORS methods, meaning the browser will mask the exact status code and error message from us, and the proxy hangs on the request anyways: matrix-org/sliding-sync#429
To avoid these problems, we instead search for an unstable feature flag to be exposed by the server. Presence of this flag denotes native support. See https://github.com/matrix-org/matrix-spec-proposals/pull/3575/files#r1588877046 for details.
Implementations which support sliding sync natively will need to update to support this new unstable feature flag usage.
…12498)
* Check native sliding sync support against an unstable feature flag
The `OPTIONS` approach from #12492 doesn't work because Synapse *always* responds with 204 (success) to `OPTIONS` requests, as described here: element-hq/synapse#17153
We further can't use `HEAD` because it's not part of the allowed CORS methods, meaning the browser will mask the exact status code and error message from us, and the proxy hangs on the request anyways: matrix-org/sliding-sync#429
To avoid these problems, we instead search for an unstable feature flag to be exposed by the server. Presence of this flag denotes native support. See https://github.com/matrix-org/matrix-spec-proposals/pull/3575/files#r1588877046 for details.
Implementations which support sliding sync natively will need to update to support this new unstable feature flag usage.
* Appease the linter
* Appease the tests
Description
When Synapse is approached with an
OPTIONS
request, it responds 204, always. It should be returning404 M_UNRECOGNIZED
for endpoints which don't exist at all, and405 M_UNRECOGNIZED
for non-client-server endpoints which do exist, as per theM_UNRECOGNIZED
description at https://spec.matrix.org/v1.10/client-server-api/#common-error-codesSynapse's current behaviour can cause endpoint discovery to be unreliable. For example, matrix-org/matrix-react-sdk#12492 aims to use
OPTIONS
to discover sliding sync, but because Synapse always returns a success code, the react-sdk thinks sliding sync is supported (even though it's not, as of writing).Steps to reproduce
curl -sv -X OPTIONS https://matrix-client.matrix.org/_matrix/client/this/path/does/not/exist
Homeserver
all
Synapse Version
at least 1.105.1
Installation Method
Other (please mention below)
Database
n/a
Workers
I don't know
Platform
n/a
Configuration
No response
Relevant log output
Anything else that would be useful to know?
No response
The text was updated successfully, but these errors were encountered: