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.

Sign up for GitHub

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

Jump to bottom

MSC3469: Mandate HTTP Range on Content Repository Endpoints #3469

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

MSC3469: Mandate HTTP Range on Content Repository Endpoints #3469

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
41dfaac
first draft
ShadowJonathan Nov 3, 2021
fc06ccd
rename
ShadowJonathan Nov 3, 2021
302df55
add additional context
ShadowJonathan Nov 3, 2021
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
24 changes: 24 additions & 0 deletions proposals/3469-http-range.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,24 @@
# MSC3469: HTTP Range on content repository

## Proposal

This MSC aims to make HTTP Range capability *mandatory* on the content repository fetch endpoint.

[HTTP Range](https://developer.mozilla.org/en-US/docs/Web/HTTP/Range_requests) is a Header-based
method by which browsers and other clients can request a certain byte-range of a file.

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.
Comment on lines +10 to +11
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?


This would only affect CS endpoint `/_matrix/media/v3/download/{serverName}/{mediaId}`.

## Additional context

Related: https://github.com/vector-im/element-web/issues/4265

This MSC is to make the behavior standard, and consistent across the matrix ecosystem.

## Unstable prefix

This MSC would only add a well-known HTTP capability to an existing endpoint, which can easily be
ignored by existing clients, I think it's overkill to require an unstable prefix for this.