Re: Draft for Resumable Uploads

> On Apr 5, 2022, at 9:31 PM, Eric J Bowman <mellowmutt@zoho.com> wrote:
> 
> >
> >----------------------------
> To give you an example, let’s suppose we have an html form like this:
> 
> <form action="/upload" enctype="multipart/form-data" method="post">
>   <input type="file" name="file">
>   <input type="submit" value="Submit">
> </form>
> 
> When a user click “Submit”, the browser sends a `POST /upload` request with the file content as the request body. However, if the upload interrupts and the client tries `HEAD /upload`, how does the server know which upload the client is referring to?
> >------------------------------
> >
> 
> Indeed! In your example /upload is a tightly-coupled RPC endpoint; if the request body is the file content why are you using POST instead of PUT? 'HEAD/resource' lets the server know exactly which "upload" is referenced: if it was interrupted, the server knows it, and responds 206. Because REST.
> 
> >
> >------------------------------
> The server can of course use surrounding information (such as Cookie) to look up the incomplete upload. However, that prevents the same client to submit multiple forms concurrently. Alternatively, the server can also generate dynamic HTML pages to encode a unique identifier in the form action URL, but that prevents caching and doesn’t solve other non-HTML use cases.
> >------------------------------
> >
> 
> Or, the client and server could use a uniform interface based on the URI of the actual resource being manipulated via the transfer of representations which precisely indicate application state? So much easier in my experience from a coding and caching perspective, regardless of how browser behavior changes over time. Can we agree to assume the UA is curl, to continue this discussion? Instead of limiting it to the protocol shortcomings of HTML forms as implemented in browsers, which are easily worked around?
> 
> >
> >------------------------------
> `Upload-Token` is designed to resolve this issue by labeling every upload with a unique ID.
> >------------------------------
> >
> 
> No, I got that. Once again, no offense intended, but this is where you lose me as a REST acolyte. The uniform interface allows well-defined actions against well-defined resources, without all the overhead and complexity of assigning per-action UIDs -- that's some other (SOAPy) architectural style.
> 
I hope we can improve things today, and many upload endpoints are modeled after an HTML form submission today because of its native support in browsers. While I cannot judge the REST-fulness of it, my preference would not be to ask everybody to redesign their applications.

> >
> >------------------------------
> Thanks, I will look it up.
> >------------------------------
> >
> 
> I wish you could, but I know of no archive of the old Yahoo rest-discuss list, or it'd be easy to search "partial PUT and 206" because I think that was my thread title bitd...???
> 
> >
> >------------------------------
> The recent trend has shifted to define standards with no ambiguity and with strict requirements for implementations, as people recognize that unplanned extensibility makes interop much more difficult. HTTP/3 standard is a good example of that philosophy, whereas if you give the PATCH RFC5789 to 100 people to implement, they will end up with 100 incompatible protocols.
> >------------------------------
> >
> 
> I prefer to stick with fundamentals which have stood me in good stead for decades (I pick up occasional hired-gun work for HTML, CSS, JS, and even XSLT because the blue-collar IT folks I know deal with XML daily; the first CMS I ever coded was SSJS when it was called Netscape LiveWire and everyone was like, JS is a client-side language). I can't follow trends. Especially not in calving season. No offense taken if you choose to disregard my review of your concept based on I'm out-of-touch, old-fashioned, whatevs; I am what I am, and that's always in favor of loose coupling when it comes to HTTP.
> 
> >
> >  (1) Is a resumable upload standard necessary?
> >
> 
> No. 20 years ago, the question was "are resumable uploads necessary" and the answer was including PATCH in the uniform interface. Not that it made me happy, as I was arguing for an APPEND method lol. One of the absolute joys of putting ideas to the rogue's gallery of usual suspects around here, is having most of 'em shot down, and learning from it. Me replying to two active threads simultaneously on this list, is extra-unusual and does not mean I won't r-lurk and say nothing for years, but you've got my goat with this one.
> 
Well, I was still in elementary school 20 years ago so I’m not familiar with the history. APPEND would have been nice.

> >
> > I think this is an easy argument. Current state of many 
> > incompatible protocols makes it impossible to interop.
> >
> 
> Heh! :) I think this is amongst the hardest of HTTP arguments or it woulda been settled long ago.
> 
The state of things is that nearly no upload is resumable, and anyone who needs it invents their own incompatible protocols. Someone else should chime in, as I do not know how to proceed if we cannot even agree on whether this is a problem worth solving.

> >
> > (2) Does everyone agree with tus-v2’s main goals? To design a
> > mechanism to upgrade any upload to resumable upload...
> >
> 
> -1
> 
> HTTP protocol is agnostic as far as how the representations are created... for any given resource, they may be uploaded, calculated, read from disk, result from a UA dialog, etc. I maintain that the starting point ought to be identifying a resource as incomplete and putting PUT/PATCH in an "Allow" header, problem solved because uniform interface.
> 
How do you deliver the “Allow” header? If the upload is interrupted, the server likely hasn’t had a chance to send the response yet. Do you require clients to send an `OPTIONS *` request before uploading?

As an implementor, I don’t think any of these details is so obvious such that it’s not worth documenting. Happy to explain what consideration went into our decisions in the draft, and would be glad to revisit them if you have a concrete alternative.

Guoye

> >
> >------------------------------
> (3) What about the protocol details? 204 vs 206, Upload-Offset vs Content-Length vs Content-Range.
> >------------------------------
> >
> 
> I've never found a use for 203 or 205, but the rest of 200-206... I'm a big fan of 201/202. Because sometimes content needs to wait on moderation, transformation, etc. before a subsequent HEAD reports 200 i.e. successful upload. 204's a cache hit. 206 just needs a bit of fleshing out. Upload-Offset, also useless to me. Content-Range, nice feature if implemented, not relevant here. The only client gonna know what the Content-Length should be, is the one that failed to upload, hence interpreting C-L as "last byte received" on a 206 is obvious to said client, and the resulting action (retry with PUT or append with PATCH) is transparent to all, and really easy to spot in the httpd's logfile.
> 
> -Eric
> 
>