Re: Draft for Resumable Uploads

On 2022-04-05 10:59, Guoye Zhang wrote:
> 
> 
>> On Apr 4, 2022, at 6:27 PM, Eric J Bowman <mellowmutt@zoho.com> wrote:

>> 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.

If that's a problem on the server side, servers that can't handle that 
would just send a simplified Content-Range header (e.g. with only a 
single range).

Regards,   Martin.

> 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

Received on Tuesday, 5 April 2022 04:52:24 UTC