Re: Draft v1 Update for Resumable Uploads

Glenn Strauss <gs-lists-ietf-http-wg@gluelogic.com> Mon, 20 June 2022 03:37 UTC

Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB788C15B265 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sun, 19 Jun 2022 20:37:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.662
X-Spam-Level:
X-Spam-Status: No, score=-7.662 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pfe4ESoqe9_E for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sun, 19 Jun 2022 20:37:56 -0700 (PDT)
Received: from lyra.w3.org (lyra.w3.org [128.30.52.18]) (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 ietfa.amsl.com (Postfix) with ESMTPS id B0611C157B34 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Sun, 19 Jun 2022 20:37:56 -0700 (PDT)
Received: from lists by lyra.w3.org with local (Exim 4.92) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1o38Bd-0001CX-1s for ietf-http-wg-dist@listhub.w3.org; Mon, 20 Jun 2022 03:34:49 +0000
Resent-Date: Mon, 20 Jun 2022 03:34:49 +0000
Resent-Message-Id: <E1o38Bd-0001CX-1s@lyra.w3.org>
Received: from titan.w3.org ([128.30.52.76]) by lyra.w3.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <gs-lists-ietf-http-wg@gluelogic.com>) id 1o38Bb-0001Bm-9r for ietf-http-wg@listhub.w3.org; Mon, 20 Jun 2022 03:34:47 +0000
Received: from smtp1.atof.net ([52.86.233.228]) by titan.w3.org with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (Exim 4.94.2) (envelope-from <gs-lists-ietf-http-wg@gluelogic.com>) id 1o38Bb-000zdI-0L for ietf-http-wg@w3.org; Mon, 20 Jun 2022 03:34:46 +0000
X-Spam-Language: en
X-Spam-Relay-Country:
X-Spam-DCC: B=; R=smtp1.atof.net 1102; Body=1 Fuz1=1 Fuz2=1
X-Spam-RBL:
X-Spam-PYZOR: Reported 0 times.
Date: Sun, 19 Jun 2022 23:34:25 -0400
From: Glenn Strauss <gs-lists-ietf-http-wg@gluelogic.com>
To: Lucas Pardue <lucaspardue.24.7@gmail.com>
Cc: Guoye Zhang <guoye_zhang@apple.com>, HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <Yq/qwUIidS42HrIi@xps13>
References: <BED5A5BC-3F7F-47E2-815E-DC0483328DFD@apple.com> <Yq67WGkb0LtJIAP9@xps13> <CALGR9oa-zUTL4z_jrzvknBOoeYoksT-mPgz3m3ddUFzBZZ6khg@mail.gmail.com> <Yq/VYMe+VUDdnY1c@xps13> <CALGR9oamykn+QbTG89ELMLCuHHdP=PEod_jgJ7-6JgJivnNhKA@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
In-Reply-To: <CALGR9oamykn+QbTG89ELMLCuHHdP=PEod_jgJ7-6JgJivnNhKA@mail.gmail.com>
Received-SPF: pass client-ip=52.86.233.228; envelope-from=gs-lists-ietf-http-wg@gluelogic.com; helo=smtp1.atof.net
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: titan.w3.org 1o38Bb-000zdI-0L da8d85dac166054ad740c2656e7242d6
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Draft v1 Update for Resumable Uploads
Archived-At: <https://www.w3.org/mid/Yq/qwUIidS42HrIi@xps13>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/40176
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <https://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

On Mon, Jun 20, 2022 at 03:41:02AM +0100, Lucas Pardue wrote:
> On Mon, Jun 20, 2022 at 3:03 AM Glenn Strauss <
> gs-lists-ietf-http-wg@gluelogic.com> wrote:
> > > 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.
> >
> 
> Thanks for these comments. Speaking to both points, if there were a
> different form of solution would you feel it could be less
> application-specific? I think that would be a good thing for the WG to try
> and come to some answer on; is this a problem that can ever be solved in
> HTTP or not.

I think that Guoye's narrowly scoped problem can have a solid solution
with a small Python script.

Separately, the resource management, security implications (resource
exhaustion denial-of-service), and other considerations associated with
resumable uploads are (I think) better handled as application-specific.

I am fine with a proposed convention, along with shared libraries, e.g.
a reusable server-side python module, to implement the application
resumable upload convention.

My sincere request is that whatever becomes of the draft, that it not
require new changes to generic HTTP servers beyond current standards.

I have provided some examples how resumable uploads might be implemented
using current standards, and so I request that any new protocol justify
why current mechanisms are insufficient and why the new protocol is
substantially better (and hopefully without adding new security
headaches).

An endpoint implementing partial-PUT with an application upload
transaction id may cover a large swath of use cases.

As Eric said:
> yeah, yeah... easier said than done. So is making HTTP stateful.

Making "stateful" the request body portion of a request is a large
change to HTTP semantics.  I think it should remain application
specific to be able to handle a wide range of application-specific
variations.

Cheers, Glenn