Re: Draft for Resumable Uploads

>

>---------------------

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.



>


>---------------------


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.



>
>---------------------

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