Re: Draft for Resumable Uploads

> 
> On Apr 2, 2022, at 12:48 AM, Julian Reschke <julian.reschke@gmx.de> wrote:
> 
> Am 01.04.2022 um 21:30 schrieb Guoye Zhang:
>> 
>> ...
>>> 
>>> tus-v2 assumes that there is a separate resource for uploading, as
>>> opposed to
>>> targeting a resource and letting the server decide whether it can
>>> upload into
>>> a temporary resource for that target. It doesn't indicate what the server
>>> is to do with the data once it is uploaded, which implies this is just
>>> part
>>> of a private agreement instead of a standard protocol.
>> 
>> tus-v2 is not intended to be a protocol using HTTP, it is designed to be
>> an extension of HTTP. In particular, any upload methods, regardless of
>> POST, PUT, etc can be transparently upgraded to support resumable
>> uploads. It should not prevent the server from organizing the resource
>> in any way.
>> ...
> 
> What is this supposed to mean? Could you elaborate on this distinction?
> 
> Best regards, Julian
> 
Sure, what I’m trying to say is that this draft is intended to be genetic mechanism to upgrade any upload into resumable upload regardless of method or URI. I could imagine a future where this is implemented by the CDNs and browsers. The website just posts a plain HTML form, and the origin server also just receives a plain POST, but during transit, browser detects resumable upload support and handles interrupted uploads gracefully.

The exact mechanism (headers and formats of control messages) isn’t set in stone, and we’re happy to make changes if it is in conflict with any existing protocols on top of HTTP. But our overall goal is for this to be easily implementable not only on top of existing HTTP libraries, but also in the HTTP libraries themselves (which is why I said it’s extending HTTP).

Guoye