Re: Draft v1 Update for Resumable Uploads

Lucas Pardue <> Sun, 19 June 2022 15:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 667B3C14CF00 for <>; Sun, 19 Jun 2022 08:56:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.759
X-Spam-Status: No, score=-2.759 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5agSxWCHncPI for <>; Sun, 19 Jun 2022 08:56:41 -0700 (PDT)
Received: from ( []) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by (Postfix) with ESMTPS id 14E31C14F72E for <>; Sun, 19 Jun 2022 08:56:40 -0700 (PDT)
Received: from lists by with local (Exim 4.92) (envelope-from <>) id 1o2xEq-0008Qk-OW for; Sun, 19 Jun 2022 15:53:24 +0000
Resent-Date: Sun, 19 Jun 2022 15:53:24 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <>) id 1o2xEp-0008Pq-2O for; Sun, 19 Jun 2022 15:53:23 +0000
Received: from ([2607:f8b0:4864:20::f29]) by with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from <>) id 1o2xEo-000r0g-9G for; Sun, 19 Jun 2022 15:53:22 +0000
Received: by with SMTP id t16so7998153qvh.1 for <>; Sun, 19 Jun 2022 08:53:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=PyyVqmd+U2+bsHfqFlDE8UXxNg9xO9N+mqj7ZQWbSbY=; b=avWlaO+I3AbbGUb3dq/raGuNHNtZ7Kgvu9ancEgS3IJIQi6it/2DZgSbqgKFXsw8Uk ilPM2FRZZ2W0m1n0XhowJAz0WkypazplJgUqVIrLmxn0giEhVpTUG0hhz7wF/26V/SoQ qDk7+vRMEHNKK7bYqyW1AzotacwfgNoKUFwJRErFg0oiRZPdVR3KUZPpl8cV2rPXIe5j hXrHqpgSFATPFX1EsG6GBEoZA9CER4D5dbmJ4nr5gNxf3er0sia4l4CO6Mysn2TR55lT FS9uA6G3auBEF81hCMYAvTKz9FZFj4asczvbU4gY5J0cNpFEIn7RZio+nD1lYwUqk/37 7zcg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=PyyVqmd+U2+bsHfqFlDE8UXxNg9xO9N+mqj7ZQWbSbY=; b=V9BmOrmASMxO1jczxwucRW73TPidxfacwKISFEhmIl50z3Mc2GdGOXtYoswaheqfno nS3fOUlV7MSnlmZ6LapUeoYPAhoDZViQbXt71h0fY59H1++iFUeadQoz4o70DcrK9110 wL7iv2VLm+UZsCCTRXohy8Z/iph+O6vsptKCDBktpaduvLAY8qg7yljNJhramuFXKQhZ /zdiWilcCfh+8qfxRTlOQaBK39MaAy13mWrhhzNSQKi2OgeDlML1H2fSb7q53f5mFEix lp8V/uuwPOjxLHmWuDPwuDtDR6T1ZjLfcmsvjGMCDKWsHFKdjt+zU5tsH2hF6aDtw39/ rorQ==
X-Gm-Message-State: AJIora+r/n4ELizuicuxfl+8P5nIpZbsot+4/L3nJ6HTnUPKDtKIdCIn CNOozfWbQdIg2lTaX+UtUkfpg6FxDP3Dy+TxSJv1P5sHhRY=
X-Google-Smtp-Source: AGRyM1tNOm1yQpor69kfB9S/vFtY2WyCQh0b3GGYcDQvX/K3B6rWsknPu068Ut+hAz4fzqZx0agXcLQdVCIYa7XXCl8=
X-Received: by 2002:ad4:5f46:0:b0:46f:9da8:17cc with SMTP id p6-20020ad45f46000000b0046f9da817ccmr9910198qvg.72.1655653989958; Sun, 19 Jun 2022 08:53:09 -0700 (PDT)
MIME-Version: 1.0
References: <> <Yq67WGkb0LtJIAP9@xps13>
In-Reply-To: <Yq67WGkb0LtJIAP9@xps13>
From: Lucas Pardue <>
Date: Sun, 19 Jun 2022 16:52:58 +0100
Message-ID: <>
To: Glenn Strauss <>
Cc: Guoye Zhang <>, HTTP Working Group <>
Content-Type: multipart/alternative; boundary="000000000000f14b4605e1cefba8"
Received-SPF: pass client-ip=2607:f8b0:4864:20::f29;;
X-W3C-Hub-DKIM-Status: validation passed: (, signature is good
X-W3C-Hub-Spam-Status: No, score=-4.9
X-W3C-Scan-Sig: 1o2xEo-000r0g-9G 4142de97ebfac1d83ea7fd709ddca0f7
Subject: Re: Draft v1 Update for Resumable Uploads
Archived-At: <>
X-Mailing-List: <> archive/latest/40164
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

Hi Glenn,

I'd like to respond to one aspectdirectly:

On Sun, Jun 19, 2022 at 7:04 AM <> 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

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

If you have concerns about the first instance of "often", I'd suggest
starting a separate thread against RFC 9110. I don't agree this document
has a requirement to justify that as you suggest.

If you have concerns about the second instance of "often", that is perhaps
where we have different readings causing some friction. RFC 9110 doesn't
have any qualification of the term "it is desirable", I used "often" to
dilute this i.e, "often but not always". A different reading is that,
having seen multiple HTTP-based custom resumable upload approaches from
different vendors, there is an unaddressed use case. Hence it is not seldom
that for applicaitons that feature uploads, resumption is desirable.
Either way, I am happy to remove that second "often" or do other
wordsmithing of this sentence that makes it clear why we think this is a
problem worth standardising in the HTTP WG.