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

Re: Draft v1 Update for Resumable Uploads

From: Guoye Zhang <guoye_zhang@apple.com>
Date: Sun, 19 Jun 2022 19:19:05 -0700
Message-id: <A612E09A-F479-4B83-898F-1F6BA7205149@apple.com>
Cc: Lucas Pardue <lucaspardue.24.7@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
To: Glenn Strauss <gs-lists-ietf-http-wg@gluelogic.com>

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

Received on Monday, 20 June 2022 02:19:40 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:44:07 UTC