Re: Draft for Resumable Uploads

> On Apr 6, 2022, at 2:20 AM, Eric J Bowman <mellowmutt@zoho.com> wrote:
> 
> >
> >---------------------
> 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.
> >---------------------
> >
> 
> My preference would be not asking everybody to restrict their applications to POST based on the limitations of HTML browsers, in an age when any HTTP method is available in some JS library or another. If I want to revive my old browser-native XSLT code, it would be a piece of cake to just "wrap it" a bit different and have it still work -- the XSLT of it hasn't bit-rotted. Given that, and my having changed careers a decade ago, if we're still stuck with just GET and POST when discussing HTTP, I guess I may as well just mosey on back to the herd.
> 
> As to RESTfulness, using HTML forms certainly qualifies if the implementations are /resource not /endpoint oriented -- to oversimplify, no big thing to POST my PATCH given proper application architecture.
> 
tus-v2 is agnostic to HTTP methods. POST was just picked for the examples because it’s the most commonly-used upload method. You can upgrade any upload operation with any method to resumable upload using the procedures described in the draft.

> >
> >---------------------
> Well, I was still in elementary school 20 years ago so I’m not familiar with the history. APPEND would have been nice.
> >---------------------
> >
> 
> My hobby protocol, MONTage, eschews the UA in favor of the AI and has SUBMIT/RETRACT methods and so on, but still no APPEND for the same reason PATCH was preferred bitd. The semantics of the operation are the same, regardless of what byte you're starting at, or if the last byte happens to be EOF. So Append doesn't warrant its own method. One of many things I've been legitimately wrong about, architecture-wise.
> 
> >
> >---------------------
> 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.
> >---------------------
> >
> 
> I don't think anyone has even meant to imply that this isn't a problem worth solving. That being said... 20 years ago we figured _every_ upload was *replaceable* on failure, while realizing PATCH would increase in value hand-in-hand with filesize over time. Reckoning day has arrived! ;) Thanks for your contribution, and I mean that, otherwise I wouldn't bother. If I intended to stick around and argue this I'd go back to using Sylpheed and proper email quoting. Just wanted to point out "prior art" exists re: 206, even if my example code has bit-rotted beyond recovery it's still quite simple and straightforward.
> 
> >
> >---------------------
> > (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?
> >
> 
> Ha! I'm a huge aficionado of OPTIONS, especially with a wildcard, but I don't see how it applies here? An OPTIONS request is not prerequisite to an Allow header in response. I'm also not aware of any restriction to including the Allow header on *any* 2xx response, or on a PUT request, or even a 404/410. So let's work this out:
> 
> client1: PUT /resource C-L = 256
> server: only receives 128 before connection closes
> client2: GET /resource before that connection closes
> server: 404 if the PUT was meant to create; otherwise 200/204 with Etag, expected behavior either way
> client 1: connection failed 128 bytes in, no server response
> server: decides how to handle the 128 bytes received, accepts instead of tossing
> client2: GET /resource
> server: 206 C-L = 128
> client1: is back, HEAD /resource
> server: 206 C-L = 128
> client1: PATCH /resource 128-256 (or, re-PUT)
> server: 2xx
> --later--
> client2: GET /resource
> server: 200 OK
> 
> I'm not seeing any problem with that, which in any way shape or form, needs any sort of convoluted approach using 1xx or headers to clarify a fundamental HTTP transaction.
> 
There isn’t a huge delta between what you’ve described and what’s currently in the draft. You’ve also identified the same core procedures for resumable upload: creation, offset retrieval, and resumption. The only extra thing we have is cancellation since we don’t want servers to hold on to resources any longer than necessary if clients already decided to give up.

One thing that drove many aspects of the design is our desire to seamlessly upgrade any upload to resumable upload. To us, it’s hugely valuable that a browser or an OS can implement this mechanism under the hood, and all websites and applications would benefit from it without any code change on the client side. This is the reason we have tokens and other newly defined headers, since we don’t want to misinterpret the server supporting something different but happens to use the same header fields.

The reason we are bringing this to workgroup is to look for ways to improve the draft. We like how the draft turned out and how easy it is to implement, as there are already multiple experimental implementations, but we are not experts in HTTP semantics. Changing 204 to 206, adopting Content-Length, or adopting PATCH are the feedbacks we are looking for and I’m happy to discuss them further. However, I would keep strongly advocating for some way to support feature detection and automatic upgrade since it’s one of the core motivations of the draft.

Guoye

> >
> >---------------------
> 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.
> >---------------------
> >
> 
> As an implemeter, I have reached a Zen-like acceptance of the fact that I never have been nor will I ever be on the "winning side" in any debate with a browser vendor. I swear to you though, I am not opposed to your idea on the basis of who you work for. I am opposed to it because your considerations have led to an RPC-grafted-onto-HTTP solution. Which may very well see some adoption short-term, but I doubt it'll be there five years down the road, and I believe I have presented a concrete alternative.
> 
> -Eric
> 
>