Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Push Gateway spec states that valid Pusher URLs are more flexible than they really are #809

Open
callahad opened this issue Apr 16, 2021 · 1 comment
Labels
clarification An area where the expected behaviour is understood, but the spec could do with being more explicit

Comments

@callahad
Copy link
Contributor

The Push Gateway spec states:

Notifications are sent to the URL configured when the pusher is created. This means that the HTTP path may be different depending on the push gateway.

However, the Client-Server API Spec began asserting that the pusher URL "must have a path of /_matrix/push/v1/notify" with version 0.4.0 in August 2018. The change itself was introduced by matrix-org/matrix-spec-proposals#1522.

Thus, the HTTP path cannot be different depending on the push gateway; only the host is allowed to differ.

Synapse began enforcing this restriction in 1.25.0 with the merge of matrix-org/synapse#8865, but the discrepancy between the Push Gateway spec and the Client-Server API spec has caused confusion with real-world Matrix deployments.

The language in the Push Gateway spec ("the HTTP path may be different") predates matrix-org/matrix-spec-proposals#1522, and I suspect it was simply overlooked when reviewing that change.

@callahad callahad added the clarification An area where the expected behaviour is understood, but the spec could do with being more explicit label Apr 16, 2021
@richvdh
Copy link
Member

richvdh commented Apr 21, 2021

See also matrix-org/matrix-spec-proposals#2970 which proposes relaxing the requirement on the pusher URL.

@richvdh richvdh transferred this issue from matrix-org/matrix-spec-proposals Mar 1, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
clarification An area where the expected behaviour is understood, but the spec could do with being more explicit
Projects
None yet
Development

No branches or pull requests

2 participants