Re: Draft for Resumable Uploads

>

> First, how does it uniquely identify a resumable upload?

> 



A 206 response to a non-range request uniquely, unambiguously, and elegantly identifies an incomplete resource. Identifying a resource as both incomplete *and* completeable, introduces tight coupling at the protocol layer.



The Content-Length header should suffice to inform a client where to resume the upload. Whether it's allowed to or not, seems an application-layer concern (beyond authentication), hidden behind the uniform interface.



>

> Does the server need to send a unique URL to the client?

>



Thought we were talking Web Arch, where all URIs are unique, and the basis of messaging is a client requesting a representation of the identified server resource. Clients may receive URLs from servers, but I can always type 'em into my user-agent, which is of particular note when we're including PUT in the convo. ;)



>

> What about the additional roundtrip time?

>



Wasn't the upload interrupted? Even if it was for a nanosecond, the network connection needs to be re-established... the client needs to re-authenticate with the server... seems we're way beyond one HTTP r/t of latency making any real-world difference.



>

> tus-v2 draft solves it by defining `Upload-Token` which is a 

> cryptographically-random token generated on the client side.

>



To save one HTTP round trip when restarting an interrupted download? That's where ya lost me.



>

> We’ve also looked at the `Range` header but decided 

> against it due to it providing too much flexibility.

>



That's an interesting way of putting it, thanks! I never even considered using it to solve what I call the "partial-PUT problem" we're dealing with, shoulda left it out of my last email, really only Content-Length matters here.



>

> Features like multipart ranges are extremely difficult to

> support on the server.

>



You're preaching to the choir. Granted I've been ranching for the past decade, but before that I was a web developer since 1994 and have coded many a webserver. The fundamentals to which I adhere, have not changed over time. Makes me salty, but if you know where to find any of my old work on archive.org the takeaway should be that it all still functions on the latest browsers. Except the browser-native XSLT stuff.



>

> That being said, we can revisit this decision if the work group provides a different perspective.

>



All about consensus and working code. I'd love to link you to a rest-discuss thread about my PUT/PATCH demo, I had a deliberately-broken example image that responded 206 online for years, back in the aughties; archive.org serves it 200 tho. If you ever *really* tried it you were using curl. It helped me grok/explain resource v representation. The broken representation of one resource (a Mona Lisa icon), was itself a first-class, read-only resource.



Most browsers rendered the incomplete image, some displayed their broken-image icon, none choked on the 206. The same representation was available from a PUT/PATCH-enabled, access-restricted URI (allowing it to be fixed, one way or another, without affecting the other URI dedicated to the broken variant), and the discussion was about how PATCH increases in value the larger the file. ARF vs. ARCF, C = Continue.



At some point you've transferred more of the file than you're willing to Retry and overwrite, vs. Continue appending. I guess if you want you can introduce 1xx responses into the mix there, but I'm not seeing it as necessary.



>

> Overall, we believe that a tightly-scoped standard would benefit

> implementors and encourage wide adoption.

>



All due respect, I'm seeing a tightly-coupled solution to the ages-old partial-PUT problem, which does not falsify using a 206 response to a non-range request to unambiguously communicate the state of the resource as "incomplete" where Content-Length gives the exact byte where the transfer was interrupted. IMHO, a loosely-coupled approach is better for encouraging wide adoption, under the standard as written.



-Eric