> 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
This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:44:07 UTC