MSC3469: Mandate HTTP Range on Content Repository Endpoints

[ShadowJonathan]

Rendered

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

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

[turt2live]

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.

[ShadowJonathan]

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.

[ShadowJonathan]

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.

[MTRNord]

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.

[turt2live]

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.

[turt2live]

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.

[nukeop]

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