Re: Draft v1 Update for Resumable Uploads
Guoye Zhang <guoye_zhang@apple.com> Mon, 20 June 2022 02:23 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 31BAFC157B33 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sun, 19 Jun 2022 19:23:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.505
X-Spam-Level:
X-Spam-Status: No, score=-3.505 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, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_BLOCKED=0.001, 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 5RETX-WMe12O for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sun, 19 Jun 2022 19:22:59 -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 F3F9CC14F74D for <httpbisa-archive-bis2Juki@lists.ietf.org>; Sun, 19 Jun 2022 19:22:58 -0700 (PDT)
Received: from lists by lyra.w3.org with local (Exim 4.92) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1o370w-00052H-Sa for ietf-http-wg-dist@listhub.w3.org; Mon, 20 Jun 2022 02:19:42 +0000
Resent-Date: Mon, 20 Jun 2022 02:19:42 +0000
Resent-Message-Id: <E1o370w-00052H-Sa@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 1o370u-000518-HN for ietf-http-wg@listhub.w3.org; Mon, 20 Jun 2022 02:19:40 +0000
Received: from ma1-aaemail-dr-lapp03.apple.com ([17.171.2.72]) 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 1o370r-00142j-NA for ietf-http-wg@w3.org; Mon, 20 Jun 2022 02:19:40 +0000
Received: from pps.filterd (ma1-aaemail-dr-lapp03.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp03.apple.com (8.16.0.42/8.16.0.42) with SMTP id 25K2EFQC042702; Sun, 19 Jun 2022 19:19:17 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=PFRdt4Stk31XiRLx+UjOwapT21MfuFE4vmgQTtxGMmI=; b=j566IWkR6C9yNM3PczKek8mlVzd03C49dQ3bOdjCPrNjfS8W+f2/jPdHkbTpcYOAjirg KGJgHhdfYShkLicjiikLw1Pm7P4wxSOC9jXfNrjkvPCwkZuZDprWvSrgl471OTU7WTnD UVKoe7VUvNkwqOB4MwXec/Pc9xUg2SF4rmy+6jn6bHylhEj8FcGvh+eUgagubFMuwO1V OkAKqryYNPCcQT6VNe1L2cDroVi7vZQ7i5tLJh1GoQoTEgXreDWJm6xApZsgQKCCT8NX u/4hlFCGYcaKh/Ys61brdWZAK850ceJNXfnEhb+UNXEvikRWhwzexEVzgsKaRwgj11lA kQ==
Received: from rn-mailsvcp-mta-lapp03.rno.apple.com (rn-mailsvcp-mta-lapp03.rno.apple.com [10.225.203.151]) by ma1-aaemail-dr-lapp03.apple.com with ESMTP id 3gsdpved9a-27 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Sun, 19 Jun 2022 19:19:17 -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-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.18.20220407 64bit (built Apr 7 2022)) with ESMTPS id <0RDR006HF7S4PR30@rn-mailsvcp-mta-lapp03.rno.apple.com>; Sun, 19 Jun 2022 19:19:16 -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 <0RDR00O007KF2X00@rn-mailsvcp-mmp-lapp03.rno.apple.com>; Sun, 19 Jun 2022 19:19:16 -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: ea1e4f08-b18f-4fa5-82c4-50be22a3cfa6
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: ad54a898-63c8-46f1-aaa4-1bbab6992993
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.517,18.0.883 definitions=2022-06-19_12:2022-06-17,2022-06-19 signatures=0
Received: from smtpclient.apple (unknown [17.11.14.78]) 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 <0RDR011K77S37X00@rn-mailsvcp-mmp-lapp03.rno.apple.com>; Sun, 19 Jun 2022 19:19:15 -0700 (PDT)
From: Guoye Zhang <guoye_zhang@apple.com>
Message-id: <A612E09A-F479-4B83-898F-1F6BA7205149@apple.com>
Content-type: multipart/alternative; boundary="Apple-Mail=_1E455D97-6F0D-4985-8DCA-479DDDA2B6EE"
MIME-version: 1.0 (Mac OS X Mail 16.0 \(3724.0.1.1.31\))
Date: Sun, 19 Jun 2022 19:19:05 -0700
In-reply-to: <Yq/VYMe+VUDdnY1c@xps13>
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>
References: <BED5A5BC-3F7F-47E2-815E-DC0483328DFD@apple.com> <Yq67WGkb0LtJIAP9@xps13> <CALGR9oa-zUTL4z_jrzvknBOoeYoksT-mPgz3m3ddUFzBZZ6khg@mail.gmail.com> <Yq/VYMe+VUDdnY1c@xps13>
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-19_12:2022-06-17,2022-06-19 signatures=0
Received-SPF: pass client-ip=17.171.2.72; envelope-from=guoye_zhang@apple.com; helo=ma1-aaemail-dr-lapp03.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.571, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, 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 1o370r-00142j-NA 96f156441ee5c048389ae028b509ef51
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Draft v1 Update for Resumable Uploads
Archived-At: <https://www.w3.org/mid/A612E09A-F479-4B83-898F-1F6BA7205149@apple.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/40172
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 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. Guoye
- Draft v1 Update for Resumable Uploads Guoye Zhang
- Re: Draft v1 Update for Resumable Uploads Austin William Wright
- Re: Draft v1 Update for Resumable Uploads Guoye Zhang
- Re: Draft v1 Update for Resumable Uploads Martin J. Dürst
- Re: Draft v1 Update for Resumable Uploads gs-lists-ietf-http-wg
- Re: Draft v1 Update for Resumable Uploads Guoye Zhang
- Re: Draft v1 Update for Resumable Uploads Eric J Bowman
- Re: Draft v1 Update for Resumable Uploads Lucas Pardue
- Re: Draft v1 Update for Resumable Uploads Guoye Zhang
- Re: Draft v1 Update for Resumable Uploads Eric J Bowman
- Re: Draft v1 Update for Resumable Uploads Guoye Zhang
- Re: Draft v1 Update for Resumable Uploads Guoye Zhang
- Re: Draft v1 Update for Resumable Uploads Eric J Bowman
- Re: Draft v1 Update for Resumable Uploads Glenn Strauss
- Re: Draft v1 Update for Resumable Uploads Guoye Zhang
- Re: Draft v1 Update for Resumable Uploads Lucas Pardue
- Re: Draft v1 Update for Resumable Uploads Eric J Bowman
- Re: Draft v1 Update for Resumable Uploads Glenn Strauss
- Re: Draft v1 Update for Resumable Uploads Glenn Strauss
- Re: Draft v1 Update for Resumable Uploads Glenn Strauss
- Re: Draft v1 Update for Resumable Uploads Eric J Bowman
- Re: Draft v1 Update for Resumable Uploads Mark Nottingham
- Re: Draft v1 Update for Resumable Uploads Glenn Strauss
- Re: Draft v1 Update for Resumable Uploads Guoye Zhang
- Re: Draft v1 Update for Resumable Uploads Eric J Bowman
- Re: Draft v1 Update for Resumable Uploads Eric J Bowman
- Re: Draft v1 Update for Resumable Uploads Julian Reschke
- Re: Draft v1 Update for Resumable Uploads Eric J Bowman
- Re: Draft v1 Update for Resumable Uploads Julian Reschke
- Re: Draft v1 Update for Resumable Uploads Eric J Bowman
- Re: Draft v1 Update for Resumable Uploads Eric J Bowman
- Re: Draft v1 Update for Resumable Uploads Julian Reschke
- Re: Draft v1 Update for Resumable Uploads Eric J Bowman
- Re: Draft v1 Update for Resumable Uploads Eric J Bowman
- Re: Draft v1 Update for Resumable Uploads Guoye Zhang
- Re: Draft v1 Update for Resumable Uploads Greg Wilkins
- Re: Draft v1 Update for Resumable Uploads Guoye Zhang
- Re: Draft v1 Update for Resumable Uploads Greg Wilkins
- Re: Draft v1 Update for Resumable Uploads Poul-Henning Kamp
- Re: Draft v1 Update for Resumable Uploads Guoye Zhang
- Re: Draft v1 Update for Resumable Uploads Guoye Zhang
- Re: Draft v1 Update for Resumable Uploads Greg Wilkins
- Re: Draft v1 Update for Resumable Uploads Guoye Zhang