Re: Draft v1 Update for Resumable Uploads

[Glenn Strauss <[e-mail]>]

On Mon, Jun 20, 2022 at 03:41:02AM +0100, Lucas Pardue wrote:
> On Mon, Jun 20, 2022 at 3:03 AM Glenn Strauss <
> [e-mail]> wrote:
> > > A different reading is that,
> > > having seen multiple HTTP-based custom resumable upload approaches from
> > > different vendors, there is an unaddressed use case.
> >
> > I do agree with the sentiment, just not the proposed solution.
> >
> > > Hence it is not seldom
> > > that for applicaitons that feature uploads, resumption is desirable.
> >
> > Again:
> > upload recovery is **application-specific** with a non-idempotent method
> > (automatic retrying by a client is not generically or universally safe)
> >
> > "tus - Resumable Uploads Protocol" is application-specific as I read it.
> > I think the draft should proceed to describe an application-specific
> > protocol and should severely scale back its attempt to generically
> > extend HTTP for resumable uploads.
> >
> 
> Thanks for these comments. Speaking to both points, if there were a
> different form of solution would you feel it could be less
> application-specific? I think that would be a good thing for the WG to try
> and come to some answer on; is this a problem that can ever be solved in
> HTTP or not.

I think that Guoye's narrowly scoped problem can have a solid solution
with a small Python script.

Separately, the resource management, security implications (resource
exhaustion denial-of-service), and other considerations associated with
resumable uploads are (I think) better handled as application-specific.

I am fine with a proposed convention, along with shared libraries, e.g.
a reusable server-side python module, to implement the application
resumable upload convention.

My sincere request is that whatever becomes of the draft, that it not
require new changes to generic HTTP servers beyond current standards.

I have provided some examples how resumable uploads might be implemented
using current standards, and so I request that any new protocol justify
why current mechanisms are insufficient and why the new protocol is
substantially better (and hopefully without adding new security
headaches).

An endpoint implementing partial-PUT with an application upload
transaction id may cover a large swath of use cases.

As Eric said:
> yeah, yeah... easier said than done. So is making HTTP stateful.

Making "stateful" the request body portion of a request is a large
change to HTTP semantics.  I think it should remain application
specific to be able to handle a wide range of application-specific
variations.

Cheers, Glenn