Re: Draft v1 Update for Resumable Uploads

> On Jun 19, 2022, at 19:03, Glenn Strauss <gs-lists-ietf-http-wg@gluelogic.com> wrote:
> 
> On Sun, Jun 19, 2022 at 04:52:58PM +0100, Lucas Pardue wrote:
>> Hi Glenn,
>> 
>> I'd like to respond to one aspectdirectly:
>> 
>> On Sun, Jun 19, 2022 at 7:04 AM <gs-lists-ietf-http-wg@gluelogic.com> wrote:
>> 
>>> On Thu, Jun 16, 2022 at 02:30:59PM -0700, Guoye Zhang wrote:
>>>> Our previous resumable upload draft generated a lot of discussions.
>>> 
>>> At least in my case, I attempted to be polite after you submitted a
>>> draft without first doing a survey of existing RFCs.  You admitted no
>>> knowledge of WebDAV RFCs, which I deemed a large oversight considering
>>> the nature of the tus-v2 protocol.
>>> 
>>>> I’m glad to announce that we have a new draft ready to address many
>>> feedbacks that suggested adopting the PATCH method.
>>> 
>>> The draft abstract begins with unsubstantiated claims to justify itself,
>>> and I believe that almost all of those claims are also misleading.
>>> 
>>> "HTTP clients often encounter interrupted data transfers as a result of
>>> canceled requests or dropped connections. [...] it is often desirable to
>>> issue subsequent requests that transfer only the remainder of the
>>> representation."
>>> 
>>> The multiple uses of "often" are misrepresentations, IMHO.
>>> 
>>> A large percentage of HTTP requests are GET/HEAD and have no body.
>>> A sizable percentage (if not more) of HTTP POST requests are small,
>>> e.g. using POST as an alternative to GET along with XSRF tokens.
>>> 
>>> What data do you have to support the claims in the draft Abstract?
>>> What percentage of requests have request bodies, and further have
>>> request bodies that are sufficiently large that it is excessively
>>> wasteful to resend the entire representation? (and when safe to do so!)
>>> 
>> 
>> The text you quote from the tus v2 draft is based on an almost verbatim
>> section of text from RFC 9110 Section 14 [1], which describes Range
>> Requests. Quote:
>> 
>>> Clients often encounter interrupted data transfers as a result of
>> canceled requests or dropped connections. When a client has stored a
>> partial representation, it is desirable to request the remainder of that
>> representation in a subsequent request rather than transfer the entire
>> representation.
> 
> In RFC 9110, that paragraph *immediately* follows the heading "Range
> Requests".  In that context, "Clients often encounter interrupted data
> transfers" implicitly refers to downloads, as described in the section.
> 
> On the other hand, when quoted in the Abstract of the tus draft titled
> "tus - Resumable Uploads Protocol", I mistook that to refer to uploads.
> Hence, I found the statements misleading, since "interrupted data
> transfers" is ambiguous and could refer to downloads or uploads.
> 
>> I wrote the tus v2 text to explicity juxtapose resumable HTTP downloads
>> against uploads. To quote the abstract in full:
>> 
>>> HTTP clients often encounter interrupted data transfers as a result
>>   of canceled requests or dropped connections.  Prior to interruption,
>>   part of a representation may have been exchanged.  To complete the
>>   data transfer of the entire representation, it is often desirable to
>>   issue subsequent requests that transfer only the remainder of the
>>   representation.  HTTP range requests support this concept of
>>   resumable downloads from server to client.  This document describes a
>>   mechanism that supports resumable uploads from client to server using
>>   HTTP.
> 
> When a client uses an idempotent HTTP request method, such as GET, then
> the client may repeat a disconnected request, and may attempt to utilize
> a Range request.
> 
> When a client is providing a request body upload with a non-idempotent
> method, such as POST or PUT, then the request is not necessarily safe to
> repeat.  Appropriate behavior to attempt to recover may be
> application-specific.
> 
> I want to emphasize: **application-specific**
> 
> Hence, I still think that Abstract is misleading and an inaccurate
> attempt to convey equivalence between client download using an
> idempotent method, and client upload using a non-idempotent method.
> They are not equivalent; there are very important distinctions that
> should be explicitly stated before trying to describe similarities.
> 
>> A different reading is that,
>> having seen multiple HTTP-based custom resumable upload approaches from
>> different vendors, there is an unaddressed use case.
> 
> I do agree with the sentiment, just not the proposed solution.
> 
>> Hence it is not seldom
>> that for applicaitons that feature uploads, resumption is desirable.
> 
> Again:
> upload recovery is **application-specific** with a non-idempotent method
> (automatic retrying by a client is not generically or universally safe)
> 
> "tus - Resumable Uploads Protocol" is application-specific as I read it.
> I think the draft should proceed to describe an application-specific
> protocol and should severely scale back its attempt to generically
> extend HTTP for resumable uploads.
> 
> Cheers, Glenn

The protocol isn’t trying to make POST idempotent. If the resumption attempt fails, the upload will be considered a failure. The client will not restart the upload automatically unless directed by the server.

Guoye