Re: Draft v1 Update for Resumable Uploads

> On Jun 19, 2022, at 21:23, Glenn Strauss <gs-lists-ietf-http-wg@gluelogic.com> wrote:
> 
> On Sun, Jun 19, 2022 at 08:56:11PM -0700, Guoye Zhang wrote:
>>> On Jun 19, 2022, at 20:15, Glenn Strauss <gs-lists-ietf-http-wg@gluelogic.com> wrote:
>>> 
>>> If you are writing an RFC extending HTTP for the internet, then you
>>> really need to stop thinking so narrowly about your application-specific
>>> intended use case.
>> 
>> Why can’t the server start processing the upload in a non-idempotent way? The client can only resume from the interruption point, so the series of resumption can be treated as one single overall upload. This does not require idempotence at all.
> 
> If tus-v2 protocol (as currently written) permits the client to cancel
> the upload at any point, then whether or not data is corrupt and how the
> server should recover (or not) is application-specific.
> 
> Sure, *you* can decide that this is ok for *your* application use case,
> but there is no single generic "right" answer.

Cancellation is equivalent to the connection getting dropped during a regular POST, which is a situation applications already need to handle today. It’s merely an optimization so the server can stop holding onto the token waiting for resumption.

tus-v2 does not change the semantics of an upload. It just tries to make an upload more reliable.
> 
>>> PATCH with media-type application/tus-v2 may be a better solution
>>> as you can define the body any way that you like, which may include a
>>> custom (header) section in the body containing metadata such as the
>>> information you can not currently describe in Content-Range.
>> 
>> Content-Range requires the range to include the end offset which is not always available. We need something like “Content-Range: 42-/*” to achieve feature parity with the current tus protocol. Not sure if changing the definition of Content-Range is desirable.
> 
> The structure of the request body can be whatever you define for
> application/tus-v2.  The *request body* payload could itself contain
> a custom "Guoye-Content-Range" header and other metadata followed by
> a CRLF and then the data.
> 
> 
> 
> Guoye, I respectfully request that you remove yourself from the authors
> drafting this RFC.  You continue to struggle with numerous concepts in
> existing standards, including basic HTTP semantics and PATCH media-type,
> and that does not lend itself to productive creation of new RFCs.

That would be hard since I wrote most of the draft :)

It’s my fault for assuming that everybody is as familiar with the intend of the draft as I am. I’ll try to do a better job explaining it in the future.

Guoye
> 
> Regards, Glenn
>

Received on Tuesday, 21 June 2022 05:02:33 UTC