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

MSC3469: Mandate HTTP Range on Content Repository Endpoints #3469

Open
wants to merge 3 commits into
base: main
Choose a base branch
from

Conversation

ShadowJonathan
Copy link
Contributor

@ShadowJonathan ShadowJonathan commented Nov 3, 2021

Rendered

Signed-off-by: Jonathan de Jong <jonathan@automatia.nl>

Preview: https://pr3469--matrix-org-previews.netlify.app

@ShadowJonathan ShadowJonathan changed the title MSCXXXX: HTTP Range on Content Repository MSC3469: HTTP Range on Content Repository Nov 3, 2021
@turt2live turt2live added client-server Client-Server API kind:maintenance MSC which clarifies/updates existing spec proposal A matrix spec change proposal proposal-in-review labels Nov 3, 2021
Comment on lines +10 to +11
Most modern browsers depend on this mechanism to scrub through video footage, and the absence would
make some media playback unable to be scrubbed through.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is not a strong rationale for why we should mandate it in the spec. Considering this is a http feature, we rarely (if ever) need to specify how servers use HTTP features. For example, we don't mandate that servers (or clients) use Content-Type: application/json

I'm heavily inclined to leave this as an implementation detail given it's "good to have" but not a requirement for the protocol to operate. At best, this could be a suggestion in the spec which doesn't require an MSC.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Currently there's 0 mention or recommendation about this in the spec, thus the MSC.

I don't think that separating concerns and leaving it to "a HTTP-specific thing" is reasonable here, as I've seen little indication, guidelines, thoughts, or otherwise to genuinely abstract matrix to other protocols, even low-bandwidth just maps existing HTTP endpoints to be converted into CoAP. This is in the interest of clients to be able to rely on this, for example, for resumable downloads, I think that integrating this in the spec (even as a "if you use HTTP, support this" wording) would raise the level of quality that clients can expect from servers, instead of only finding it optional.

HTTP Range is nearly ubiquitous on the internet today, I think that this is expected, and I think it's reasonable for the spec to enforce that.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The primary reason why this could be useful is for clients resuming or scrubbing through media, which both are pretty useful on its own, this MSC would only make it so that all servers and media repositories have to present that same interface, so that matrix clients can fully rely on it always existing on the server, standardisation.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My opinion for mandating is actually not standardization but simply usability for the end user. Imagine a homeserver with high upload limits (those realistically exist) and a lets say 2GB video file. Today a user has to first download the whole file, then scrubs, then realizes he needed only minute 2 to minute 3. But had to wait 10m for the video to load. Being able to directly jump in those cases would highly improve usability and quality of clients in matrix as a whole in my opinion.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sorry for the latency here. I still strongly believe that this can be done as a note in the actual spec, without the requirement of an MSC. "Servers may wish to implement [HTTP Range] request support", for example.

Enforcing/requiring it would mean having an MSC, though imo a stronger argument is also needed to send such a proposal through FCP.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

for clarity: I believe a spec PR can be opened and MSC closed for this particular feature, at least as a SHOULD. If the goal is to make the Range header support a MUST, the MSC needs a stronger use case imo.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is blocking an important user experience feature, what can be done to get this moving, and then implemented in synapse?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
client-server Client-Server API kind:maintenance MSC which clarifies/updates existing spec proposal A matrix spec change proposal
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants