Re: Draft v1 Update for Resumable Uploads

Glenn Strauss <> Mon, 20 June 2022 04:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5AD56C15D886 for <>; Sun, 19 Jun 2022 21:27:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.661
X-Spam-Status: No, score=-2.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, MAILING_LIST_MULTI=-1, 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
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id d1_vnKqzfIJn for <>; Sun, 19 Jun 2022 21:27:04 -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 4CDA0C15D87C for <>; Sun, 19 Jun 2022 21:26:58 -0700 (PDT)
Received: from lists by with local (Exim 4.92) (envelope-from <>) id 1o38x5-00083d-Bg for; Mon, 20 Jun 2022 04:23:51 +0000
Resent-Date: Mon, 20 Jun 2022 04:23:51 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <>) id 1o38x3-00082s-UP for; Mon, 20 Jun 2022 04:23:49 +0000
Received: from ([]) by with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (Exim 4.94.2) (envelope-from <>) id 1o38x3-0017XK-7p for; Mon, 20 Jun 2022 04:23:49 +0000
X-Spam-Language: en
X-Spam-DCC: B=; 1102; Body=1 Fuz1=1 Fuz2=1
X-Spam-PYZOR: Reported 0 times.
Date: Mon, 20 Jun 2022 00:23:28 -0400
From: Glenn Strauss <>
To: Guoye Zhang <>
Message-ID: <Yq/2QBusKXNEEWCL@xps13>
References: <> <Yq67WGkb0LtJIAP9@xps13> <> <Yq/mYB6FMLWn/7Oj@xps13> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <>
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-6.2
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: 1o38x3-0017XK-7p b90feb5e3fcb22fb6b278dfa933a3928
Subject: Re: Draft v1 Update for Resumable Uploads
Archived-At: <>
X-Mailing-List: <> archive/latest/40178
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

On Sun, Jun 19, 2022 at 08:56:11PM -0700, Guoye Zhang wrote:
> > On Jun 19, 2022, at 20:15, Glenn Strauss <> wrote:
> >
> > If you are writing an RFC extending HTTP for the internet, then you
> > really need to stop thinking so narrowly about your application-specific
> > intended use case.
> Why can’t the server start processing the upload in a non-idempotent way? The client can only resume from the interruption point, so the series of resumption can be treated as one single overall upload. This does not require idempotence at all.

If tus-v2 protocol (as currently written) permits the client to cancel
the upload at any point, then whether or not data is corrupt and how the
server should recover (or not) is application-specific.

Sure, *you* can decide that this is ok for *your* application use case,
but there is no single generic "right" answer.

> > PATCH with media-type application/tus-v2 may be a better solution
> > as you can define the body any way that you like, which may include a
> > custom (header) section in the body containing metadata such as the
> > information you can not currently describe in Content-Range.
> Content-Range requires the range to include the end offset which is not always available. We need something like “Content-Range: 42-/*” to achieve feature parity with the current tus protocol. Not sure if changing the definition of Content-Range is desirable.

The structure of the request body can be whatever you define for
application/tus-v2.  The *request body* payload could itself contain
a custom "Guoye-Content-Range" header and other metadata followed by
a CRLF and then the data.

Guoye, I respectfully request that you remove yourself from the authors
drafting this RFC.  You continue to struggle with numerous concepts in
existing standards, including basic HTTP semantics and PATCH media-type,
and that does not lend itself to productive creation of new RFCs.

Regards, Glenn