W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2022

Re: Draft for Resumable Uploads

From: Guoye Zhang <guoye_zhang@apple.com>
Date: Mon, 04 Apr 2022 18:59:50 -0700
Message-id: <2FADC394-0954-4AA2-8F55-6CDF88833CB3@apple.com>
Cc: Julian Reschke <julian.reschke@gmx.de>, ietf-http-wg <ietf-http-wg@w3.org>
To: Eric J Bowman <mellowmutt@zoho.com>


> 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
Received on Tuesday, 5 April 2022 02:00:07 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 April 2022 02:00:07 UTC