MSC3870: Async media upload extension: upload to URL #3870
Conversation
Fizzadar
changed the title
turt2live
added
proposal
Fizzadar
changed the title
| { | ||
| "content_uri": "mxc://example.com/AQwafuaFswefuhsfAFAgsw", | ||
| "unused_expires_at": 1647257217083, | ||
| "upload_url": "https://cdn.example.com/media-repo/upload/XAPw4CtrzArk?signed=h4tGOHvCu" |
There was a problem hiding this comment.
What HTTP method does the client use to upload the file? POST? PUT? Or do you need another parameter to specify the method?
There was a problem hiding this comment.
Clarified in ba15fa9 (PUT, for now).
There was a problem hiding this comment.
We can probably encode it into the field here, making it generic against providers.
| "upload_url": "https://cdn.example.com/media-repo/upload/XAPw4CtrzArk?signed=h4tGOHvCu" | |
| "upload_location": "PUT https://cdn.example.com/media-repo/upload/XAPw4CtrzArk?signed=h4tGOHvCu" |
There was a problem hiding this comment.
I think we should use a separate field here just to be explicit, upload_method, will update.
| The proposal modifies the MSC2246 create endpoint to optionally include a URL that a compatible | ||
| client may use to upload the content for the created MXID. This is considered optional and the | ||
| client may continue to upload via the new upload endpoint defined in MSC2246. |
There was a problem hiding this comment.
Clients should be required to use the URL when the server generates one, I think. The server is almost certainly trying to shed bandwidth load when it generates one of these URLs, and it's already gone through the effort to allocate a storage location for the client. That's a lot of wasted effort/cash if the client ignores the field.
For MSC purposes, making it required I think means:
- New endpoint version for
/create, to encourage clients to opt-in to the field's presence - Deprecating the old endpoint version, further pushing clients towards the new one
- On
PUT /upload, an error code to denote that uploads aren't welcome for that URI. This does not require a new endpoint version because the client already opted-in to using the new upload URL-supported endpoint earlier in the process.
There was a problem hiding this comment.
Wouldn't clients still be able to avoid using the CDN by using the old synchronous upload endpoint?
If we're going through the effort to insist that clients use the upload_url, should we also start making plans tokill the ability to do synchrous uploads direct to the media server at all?
There was a problem hiding this comment.
I think we should leave this optional for now, and defer deprecation or blocking of direct upload to a later MSC. Allowing both in theory makes switching over to the upload URLs easier for client dev, and then we avoid all introducing additional complexity as part of this MSC.
There was a problem hiding this comment.
Wouldn't clients still be able to avoid using the CDN by using the old synchronous upload endpoint?
If we're going through the effort to insist that clients use the
upload_url, should we also start making plans tokill the ability to do synchrous uploads direct to the media server at all?
The proposed plan deprecates the endpoint, making it eligible for removal in a later version of the spec.
I think we should leave this optional for now, and defer deprecation or blocking of direct upload to a later MSC. Allowing both in theory makes switching over to the upload URLs easier for client dev, and then we avoid all introducing additional complexity as part of this MSC.
Clients can still use deprecated endpoints, but without a reason to change there's not much motivation for them to implement this. I do feel quite strongly that if the server provides a URL, the client must use that URL.
There was a problem hiding this comment.
I just pushed up fixes for the other things. I think deferring the new endpoint version and requiring clients use the URL provided is the right call - it'd be a quick follow up MSC, or might tie in with replacement plans for the old upload endpoints. Either way I don't see any real benefit to bundling it into this MSC.
| client may use to upload the content for the created MXID. This is considered optional and the | ||
| client may continue to upload via the new upload endpoint defined in MSC2246. | ||
|
|
||
| `POST /_matrix/media/v3/create` |
There was a problem hiding this comment.
If keeping the optional behaviour:
| `POST /_matrix/media/v3/create` | |
| `POST /_matrix/media/v1/create` |
If making it mandatory per https://github.com/matrix-org/matrix-spec-proposals/pull/3870/files#r1488692873 :
| `POST /_matrix/media/v3/create` | |
| `POST /_matrix/media/v2/create` |
(the v3 endpoint has never existed in the spec)
| { | ||
| "content_uri": "mxc://example.com/AQwafuaFswefuhsfAFAgsw", | ||
| "unused_expires_at": 1647257217083, | ||
| "upload_url": "https://cdn.example.com/media-repo/upload/XAPw4CtrzArk?signed=h4tGOHvCu" |
There was a problem hiding this comment.
I assume the URL expires at the same time as unused_expires_at - just need to document that in the MSC.
|
Re: implementation: Beeper's custom HS/media-repo both already support this as well as all our clients. I don't recall if this is sufficient though? |
Rendered.
Extension that builds on MSC2246.
Signed off by Nick @ Beeper (@Fizzadar) [email protected].