Re: Draft for Resumable Uploads

> On Apr 4, 2022, at 6:27 PM, Eric J Bowman <mellowmutt@zoho.com> wrote:
> 
> Missing rest-discuss lately. :(
> 
> >
> > 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.
> >
> 
> Doesn't HTTP already provide a uniform interface capable of solving this problem? Regardless of upload method...
> 
> Server knows the upload was interrupted if the received content falls short of Content-Length, or the connection timed out, or whatever.
> 
> Reconnected client makes HEAD request...
> 
> Server responds 206 with Content-Range: {zero to Content-Length} -- indicating an interrupted upload, if the client didn't make a range request.
> 
> I don't see any prohibition against responding 206 to a non-range request?
> 
> Client now knows how to PATCH the resource. Lather-rinse-repeat until 200 OK on HEAD.
> 
> -Eric
> 


Yes, you can implement something that sort of works by combining various defined methods and header fields, but there are many ambiguities:

First, how does it uniquely identify a resumable upload? Does the server need to send a unique URL to the client? What about the additional roundtrip time? tus-v2 draft solves it by defining `Upload-Token` which is a cryptographically-random token generated on the client side.

We’ve also looked at the `Range` header but decided against it due to it providing too much flexibility. Features like multipart ranges are extremely difficult to support on the server. A single integer in `Upload-Offset` models the capability better and sets the correct expectation. That being said, we can revisit this decision if the work group provides a different perspective.

Overall, we believe that a tightly-scoped standard would benefit implementors and encourage wide adoption.

Guoye