Re: Draft v1 Update for Resumable Uploads

[Glenn Strauss <[e-mail]>]

On Sun, Jun 19, 2022 at 08:56:11PM -0700, Guoye Zhang wrote:
> > On Jun 19, 2022, at 20:15, Glenn Strauss <[e-mail]> 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.

> > 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.

Regards, Glenn