Re: Draft v1 Update for Resumable Uploads

Guoye Zhang <guoye_zhang@apple.com> Tue, 21 June 2022 05:05 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 A29C2C157902 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 20 Jun 2022 22:05:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.507
X-Spam-Level:
X-Spam-Status: No, score=-3.507 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.745, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, MAILING_LIST_MULTI=-1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com
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 y2k2iZKyrpLF for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 20 Jun 2022 22:05:39 -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 063C3C15D4A6 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Mon, 20 Jun 2022 22:05:38 -0700 (PDT)
Received: from lists by lyra.w3.org with local (Exim 4.92) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1o3W27-0003iy-66 for ietf-http-wg-dist@listhub.w3.org; Tue, 21 Jun 2022 05:02:35 +0000
Resent-Date: Tue, 21 Jun 2022 05:02:35 +0000
Resent-Message-Id: <E1o3W27-0003iy-66@lyra.w3.org>
Received: from mimas.w3.org ([128.30.52.79]) by lyra.w3.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <guoye_zhang@apple.com>) id 1o3W25-0003i0-GM for ietf-http-wg@listhub.w3.org; Tue, 21 Jun 2022 05:02:33 +0000
Received: from ma1-aaemail-dr-lapp01.apple.com ([17.171.2.60]) by mimas.w3.org with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from <guoye_zhang@apple.com>) id 1o3W24-001mzW-Jt for ietf-http-wg@w3.org; Tue, 21 Jun 2022 05:02:33 +0000
Received: from pps.filterd (ma1-aaemail-dr-lapp01.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp01.apple.com (8.16.0.42/8.16.0.42) with SMTP id 25L4susL059370; Mon, 20 Jun 2022 22:02:15 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=20180706; bh=LYwKvY9CZOvDZaRb8wMUvhvlWEKiA5OLI1KGr0X77is=; b=PjyVuSybvhaXqjGrgG+Lk25BgEHkHNCZJRrEkWFBvr7BkocMa0mGU8xYcv9ntD5vTJ9Z UUQjgCiBYVoBhp34KTfZl33IoALnathcvQ2kmz7gYX3T9wUE8x9dGrKvnhy4ZXTSrONn PPHUHrTFsP74ZMQaq7zf3orOKIA3nBrMJ/1kOoZ2sXcmtuQh5jTUBF0CvU+yzupge/sg aaT9DMU0lPna3nWXwsPSi2S4xtsGAjHVAL+kl2+63NOROMxe1KHa3iwxh+elIKj3FM4X aJ7zaSU5xECsAP0RLvFp1ima6IhRt1JKlaX2VzPGCF0Gjn70A7C6uIp0dMam8z8I4dPw VA==
Received: from rn-mailsvcp-mta-lapp04.rno.apple.com (rn-mailsvcp-mta-lapp04.rno.apple.com [10.225.203.152]) by ma1-aaemail-dr-lapp01.apple.com with ESMTP id 3gsdc3eqqe-5 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 20 Jun 2022 22:02:15 -0700
Received: from rn-mailsvcp-mmp-lapp03.rno.apple.com (rn-mailsvcp-mmp-lapp03.rno.apple.com [17.179.253.16]) by rn-mailsvcp-mta-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.18.20220407 64bit (built Apr 7 2022)) with ESMTPS id <0RDT00KAZ9ZLC4E0@rn-mailsvcp-mta-lapp04.rno.apple.com>; Mon, 20 Jun 2022 22:02:12 -0700 (PDT)
Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp03.rno.apple.com by rn-mailsvcp-mmp-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.18.20220407 64bit (built Apr 7 2022)) id <0RDT00B009TWVY00@rn-mailsvcp-mmp-lapp03.rno.apple.com>; Mon, 20 Jun 2022 22:02:12 -0700 (PDT)
X-Va-A:
X-Va-T-CD: 9de54f234ec4db4ee3e1b1387630b962
X-Va-E-CD: 7fa589823f194c8498e6df6440bddbf3
X-Va-R-CD: 87a202228b76ae5a02807a21fbbc1b7c
X-Va-CD: 0
X-Va-ID: d7803138-3a94-424d-a5d4-e5123199e9b1
X-V-A:
X-V-T-CD: 9de54f234ec4db4ee3e1b1387630b962
X-V-E-CD: 7fa589823f194c8498e6df6440bddbf3
X-V-R-CD: 87a202228b76ae5a02807a21fbbc1b7c
X-V-CD: 0
X-V-ID: 3dd743d8-329b-4114-b3d9-6251fe87b840
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.517,18.0.883 definitions=2022-06-21_02:2022-06-17,2022-06-21 signatures=0
Received: from smtpclient.apple (unknown [17.11.144.143]) by rn-mailsvcp-mmp-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.18.20220407 64bit (built Apr 7 2022)) with ESMTPSA id <0RDT00B699ZNW500@rn-mailsvcp-mmp-lapp03.rno.apple.com>; Mon, 20 Jun 2022 22:02:12 -0700 (PDT)
Content-type: text/plain; charset="utf-8"
MIME-version: 1.0 (Mac OS X Mail 16.0 \(3724.0.1.1.31\))
From: Guoye Zhang <guoye_zhang@apple.com>
In-reply-to: <Yq/2QBusKXNEEWCL@xps13>
Date: Mon, 20 Jun 2022 22:02:01 -0700
Cc: ietf-http-wg@w3.org
Content-transfer-encoding: quoted-printable
Message-id: <A70DF60F-A7EF-43A2-8533-860A4676416C@apple.com>
References: <BED5A5BC-3F7F-47E2-815E-DC0483328DFD@apple.com> <Yq67WGkb0LtJIAP9@xps13> <D149DCFE-A5C9-418D-80B4-3B5F138AA497@apple.com> <Yq/mYB6FMLWn/7Oj@xps13> <1A0308B7-266A-4E12-BC6C-6D321BAFC3D3@apple.com> <Yq/2QBusKXNEEWCL@xps13>
To: Glenn Strauss <gs-lists-ietf-http-wg@gluelogic.com>
X-Mailer: Apple Mail (2.3724.0.1.1.31)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.517,18.0.883 definitions=2022-06-21_02:2022-06-17,2022-06-21 signatures=0
Received-SPF: pass client-ip=17.171.2.60; envelope-from=guoye_zhang@apple.com; helo=ma1-aaemail-dr-lapp01.apple.com
X-W3C-Hub-DKIM-Status: validation passed: (address=guoye_zhang@apple.com domain=apple.com), signature is good
X-W3C-Hub-Spam-Status: No, score=-7.0
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.597, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: mimas.w3.org 1o3W24-001mzW-Jt 653467da6fc2683af45664db71c5fe21
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Draft v1 Update for Resumable Uploads
Archived-At: <https://www.w3.org/mid/A70DF60F-A7EF-43A2-8533-860A4676416C@apple.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/40193
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 Jun 19, 2022, at 21:23, Glenn Strauss <gs-lists-ietf-http-wg@gluelogic.com> wrote:
> 
> On Sun, Jun 19, 2022 at 08:56:11PM -0700, Guoye Zhang wrote:
>>> On Jun 19, 2022, at 20:15, Glenn Strauss <gs-lists-ietf-http-wg@gluelogic.com> 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.

Cancellation is equivalent to the connection getting dropped during a regular POST, which is a situation applications already need to handle today. It’s merely an optimization so the server can stop holding onto the token waiting for resumption.

tus-v2 does not change the semantics of an upload. It just tries to make an upload more reliable.
> 
>>> 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.

That would be hard since I wrote most of the draft :)

It’s my fault for assuming that everybody is as familiar with the intend of the draft as I am. I’ll try to do a better job explaining it in the future.

Guoye
> 
> Regards, Glenn
>