Re: Draft for Resumable Uploads
"Roy T. Fielding" <fielding@gbiv.com> Tue, 12 April 2022 18:13 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 9327A3A1847 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 12 Apr 2022 11:13:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.759
X-Spam-Level:
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.248, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gbiv.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oOA6AzPtEHPX for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 12 Apr 2022 11:13:21 -0700 (PDT)
Received: from lyra.w3.org (lyra.w3.org [128.30.52.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7B603A1845 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Tue, 12 Apr 2022 11:13:20 -0700 (PDT)
Received: from lists by lyra.w3.org with local (Exim 4.92) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1neKyg-0003YJ-0o for ietf-http-wg-dist@listhub.w3.org; Tue, 12 Apr 2022 18:10:58 +0000
Resent-Date: Tue, 12 Apr 2022 18:10:58 +0000
Resent-Message-Id: <E1neKyg-0003YJ-0o@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 <fielding@gbiv.com>) id 1neKyd-0003Wz-Ko for ietf-http-wg@listhub.w3.org; Tue, 12 Apr 2022 18:10:55 +0000
Received: from bird.elm.relay.mailchannels.net ([23.83.212.17]) by mimas.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <fielding@gbiv.com>) id 1neKyO-0006sn-CZ for ietf-http-wg@w3.org; Tue, 12 Apr 2022 18:10:55 +0000
X-Sender-Id: dreamhost|x-authsender|fielding@gbiv.com
Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 917F66A02FC for <ietf-http-wg@w3.org>; Tue, 12 Apr 2022 18:10:25 +0000 (UTC)
Received: from pdx1-sub0-mail-a209.dreamhost.com (unknown [127.0.0.6]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id AF8536A07DB for <ietf-http-wg@w3.org>; Tue, 12 Apr 2022 18:10:24 +0000 (UTC)
ARC-Seal: i=1; s=arc-2022; d=mailchannels.net; t=1649787024; a=rsa-sha256; cv=none; b=PV7lBrQJ3qGG7lvd7RECAQ8fy6MDkygPD2LUVbc06Ef02eARQGcclIfgIZ01qQFO0An1tq roVOTl/9rpfSUzcc5hlO1cwgrHAWcApLHgblpb5mOr0LxELbPYiDAVNR5hlTS4nP0NRDW+ tfPFThGdJ4XjDobQwOM/rIxVYC+wk19phyHJOB1ptPDZgHuVDqGwbumfJL8U6P7HXMLSmy 5Nd1LSw/kczRHxTcQBZUgiaKh84fyQq+n/SVJxhDuog5mt0jLtsWJDzL+SDHAOTxHh/+Su 6wk/3/a2kwLJwyNRsA2+SWxJN8LVsi+B1EBi960axo7BE/8L46zcWlFfN2X6iQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=mailchannels.net; s=arc-2022; t=1649787024; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references:dkim-signature; bh=nLG9JD3Mi2hPDBZ4R6is5anMiBPT+ePZpVssxKC69s4=; b=cSIma3r3IE2uFndKZVbtoiv4MWFJAnTtRZ7fpIWqN2oWBTWNaedWO4jD0fmfkyfVZjIMOZ iaZ4921JRORJPbFIU3pZ+HqlUPyiPltf4yOM0B5hUO6fYnYuHOCnNM3tANIQSkRntvFrEH oPSB4wUFR3qJaGG8e7N2UmcwFxJ+DahQ96GhNoY0npjREpNjyXQsWOqwexGIqczc48CN2p CLsLBUP7cdndIBBMwlUGuvLQ8f7asj2NWuDJOjFxzTPtmW4eHMPAW9beTK+7w4bogz2/xV +WzGmptCi/B0jnFuNDPGcuxnyRdixRwUu9xQEFZH/wXPyS/pQyWO0I57a+6ilA==
ARC-Authentication-Results: i=1; rspamd-cf675fb6d-gq4gk; auth=pass smtp.auth=dreamhost smtp.mailfrom=fielding@gbiv.com
X-Sender-Id: dreamhost|x-authsender|fielding@gbiv.com
Received: from pdx1-sub0-mail-a209.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384) by 100.116.106.98 (trex/6.7.1); Tue, 12 Apr 2022 18:10:25 +0000
X-MC-Relay: Neutral
X-MailChannels-SenderId: dreamhost|x-authsender|fielding@gbiv.com
X-MailChannels-Auth-Id: dreamhost
X-Company-Tank: 360fd3d024177d1d_1649787024982_3827480343
X-MC-Loop-Signature: 1649787024982:1179870631
X-MC-Ingress-Time: 1649787024981
Received: from smtpclient.apple (ip72-194-77-117.oc.oc.cox.net [72.194.77.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: fielding@gbiv.com) by pdx1-sub0-mail-a209.dreamhost.com (Postfix) with ESMTPSA id 4KdDKX26q3z1SH for <ietf-http-wg@w3.org>; Tue, 12 Apr 2022 11:10:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gbiv.com; s=dreamhost; t=1649787024; bh=H/wqN9lzJgSvRAi+dl8fNYUOQm+Fu4yOakJY2nRfqzo=; h=From:Content-Type:Subject:Date:To; b=nRcU3tG3YKhXam9b6R0g6UktQWCnDePkVO1ajzThTSf/q7EzswvFp3pVdPzcBa4xH ppIQrXIPfrMogsjD4rOqJ4uDgEbERyiB0pcyR6vpWo+pJ9N3sencubjj4bus+tmTGb aU1TwcZD+sIyWmjZYBgVg8Qrnspr1gmcRCFLbcRXUlAh/c+EOwU0na+wHKJAIu97iV 8sJHbCz/RenXu5FOVtOt6DaTvyJ9iDdLoCZl6rgnjdIfa4qI+W79iQ9Edtj387lRgG s/EUrGBBJL2eSNgJyI+fxspdlamu1Q+UHGe7R56Jryjche396Kc0WoH0GpahL72Fnl 0HoXTduptDCBA==
From: "Roy T. Fielding" <fielding@gbiv.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_2D001918-8A79-4646-85F0-A0BDC281F67D"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.80.82.1.1\))
Date: Tue, 12 Apr 2022 11:10:22 -0700
References: <CANY19NvMcPQaHRamFe-yy-E38xKo2XrmFCKVRoPbyBMQhoY6vA@mail.gmail.com> <EA8A9F25-D49F-41DE-B98E-A013E1E68CAF@apple.com> <6e64f598-e82b-bff5-5ed9-c3c3f4b01439@gmx.de> <C6907036-146C-4FAB-938E-238473CB42B4@apple.com> <17ff7558cda.10ad81f8113705.2829201994677815148@zoho.com> <2FADC394-0954-4AA2-8F55-6CDF88833CB3@apple.com> <17ff85458eb.119b6ffbd16630.2281063094525551184@zoho.com> <a0670d54-d999-807c-23e2-95e357e73104@gmx.de> <17ff868f14e.d111a4c016833.788757655885004970@zoho.com> <4c1aabee-bc23-6d19-2e5d-8fdf3b3532ad@gmx.de> <892B7A86-57D0-4B21-9899-65EF3FA84A12@bzfx.net> <17ffd4d64d2.c4f12f9734385.3620821323075353432@zoho.com> <904B5382-ADCA-461F-B47C-583874D4FB55@bzfx.net> <17ffe8ddd90.1257859fc38181.7721145847915462132@zoho.com> <54BB33F9-DF98-48DB-BA2B-C8A63208BA21@bzfx.net> <1800309bddc.ec99308354061.3626360867795203460@zoho.com> <48744eb6-4437-508c-f61c-06918839e858@gmx.de> <1801b361c47.db210b21123021.8993280150669755607@zoho.com> <9b3236fc-284f-29f5-6405-850dcc2e6fed@gmx.de>
To: ietf-http-wg <ietf-http-wg@w3.org>
In-Reply-To: <9b3236fc-284f-29f5-6405-850dcc2e6fed@gmx.de>
Message-Id: <5B3291E4-CA3B-4D6E-92F0-512D89E44A79@gbiv.com>
X-Mailer: Apple Mail (2.3696.80.82.1.1)
Received-SPF: pass client-ip=23.83.212.17; envelope-from=fielding@gbiv.com; helo=bird.elm.relay.mailchannels.net
X-W3C-Hub-DKIM-Status: validation passed: (address=fielding@gbiv.com domain=gbiv.com), signature is good
X-W3C-Hub-Spam-Status: No, score=-6.1
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, 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_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, W3C_AA=-1, W3C_DB=-1, W3C_IRA=-1, W3C_WL=-1
X-W3C-Scan-Sig: mimas.w3.org 1neKyO-0006sn-CZ e5162e2c5c1316e14bdcc0b001860253
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Draft for Resumable Uploads
Archived-At: <https://www.w3.org/mid/5B3291E4-CA3B-4D6E-92F0-512D89E44A79@gbiv.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/39994
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 Apr 11, 2022, at 10:45 PM, Julian Reschke <julian.reschke@gmx.de> wrote: > > Am 12.04.2022 um 02:39 schrieb Eric J Bowman: >> > >> >> >> >> A resource has to exist first, before it can support PATCH. >> >> >> > >> > Says who? >> > >> >> Common sense? Clearly-defined method semantics is part-and-parcel of a >> uniform interface. If we're going to muddy the waters by allowing >> partial PUT (or PUT no content to DELETE), and PATCH to create a primary >> resource (not sayin' PATCH can't result in a /previous-version resource >> being minted), then I guess HTML was right all along to only bother >> defining GET and POST in forms. > > ... > > Well. You are in disagreement with the spec. > > The issue here being that "existence" of a resource is somewhat hard to > define. I've defined this before. A resource is a mapping of a URI to value over time, and thus always exists as a function because there is no distinction between an origin server that doesn't exist, a resource that is not yet mapped by the origin server (but could be), or the network being down. For example, OPTIONS can target a resource that has no representation. A value (the selected representation) is what might or might not exist at any single point in time for any given request. The question for PATCH (when I originally proposed it in HTTP/1.1) was whether a non-existent representation would be treated equivalent to a zero-length representation for the semantics of PATCH. I chose to define it as such because that would match the semantics of the Unix patch command. Hence, that's the definition. However, I don't think this discussion is relevant to the proposed upload mechanism. HTTP's methods are defined by the method spec, not by opinions on what the name allows, and Julian pointed to the right spec. The problem with extending old methods to do new tricks is that such extensions must be defined with respect to what happens when the extension is ignored. A partially ignored extension can wreak havoc, both within protocol chains and within single server implementations that are internally layered with method-specific assumptions. There are only two options for implementing this while staying within HTTP. The first is to immediately respond with 202 Accepted and the instructions for resuming/finalizing the upload if failed. The second is to immediately send a 1xx response to the client that directs them to a separate temporary resource corresponding to *this* request content being uploaded, upon which the client can do resumable tricks if this request fails. Both achieve the goal, are method-independent, and don't change the semantics for deployed practice. A 202 response changes the normal response flow, which loses whether the initial request succeeded. This is probably not desired most of the time, since resuming an upload is rare. A 1xx response does not change the normal response flow, but requires that the *client* that indicated support for doing a resumable upload support also support a 1xx response. IMO, that trade-off is obvious. Yes, that requires a protocol chain that supports 1xx responses. It is completely and utterly irresponsible at this point to allow NEW FUNCTIONALITY to be supported by stacks that are somehow incapable of understanding the existing protocol defined over 25 years ago. They were required to implement support for 1xx and 100. They will want to implement support for 103. They will have to implement this new 1xx support if they want a resumable upload without losing the initial request status, because 1xx is the only way to communicate method-specific, resource-based options before a final status code is sent. If the 1xx is lost, the client will only see the result of the initial request in a 2xx or 4xx response, which could also include extensions to indicate where the partial upload is kept and how to resume/cancel it with further requests. The difference is that the client wouldn't receive that information if the connection fails before receiving the final response headers. ....Roy
- Draft for Resumable Uploads Marius Kleidl
- Re: Draft for Resumable Uploads Roy T. Fielding
- Re: Draft for Resumable Uploads Guoye Zhang
- Re: Draft for Resumable Uploads Mark Nottingham
- Re: Draft for Resumable Uploads Guoye Zhang
- Re: Draft for Resumable Uploads Mark Nottingham
- Re: Draft for Resumable Uploads Guoye Zhang
- Re: Draft for Resumable Uploads Julian Reschke
- Re: Draft for Resumable Uploads Daniel Stenberg
- Re: Draft for Resumable Uploads Lucas Pardue
- Re: Draft for Resumable Uploads Guoye Zhang
- Re: Draft for Resumable Uploads Eric J Bowman
- Re: Draft for Resumable Uploads Guoye Zhang
- Re: Draft for Resumable Uploads Austin Wright
- Re: Draft for Resumable Uploads Martin J. Dürst
- Re: Draft for Resumable Uploads Eric J Bowman
- Re: Draft for Resumable Uploads Julian Reschke
- Re: Draft for Resumable Uploads Eric J Bowman
- Re: Draft for Resumable Uploads Julian Reschke
- Re: Draft for Resumable Uploads Guoye Zhang
- Re: Draft for Resumable Uploads Julian Reschke
- Re: Draft for Resumable Uploads Guoye Zhang
- Re: Draft for Resumable Uploads Mark Nottingham
- Re: Draft for Resumable Uploads Martin J. Dürst
- Re: Draft for Resumable Uploads Austin Wright
- Re: Draft for Resumable Uploads Eric J Bowman
- Re: Draft for Resumable Uploads Eric J Bowman
- Re: Draft for Resumable Uploads Eric J Bowman
- Re: Draft for Resumable Uploads Guoye Zhang
- Re: Draft for Resumable Uploads Austin Wright
- Re: Draft for Resumable Uploads Guoye Zhang
- Re: Draft for Resumable Uploads Eric J Bowman
- Re: Draft for Resumable Uploads Eric J Bowman
- Re: Draft for Resumable Uploads Austin William Wright
- Re: Draft for Resumable Uploads Guoye Zhang
- Re: Draft for Resumable Uploads Eric J Bowman
- Re: Draft for Resumable Uploads Eric J Bowman
- Re: Draft for Resumable Uploads Austin William Wright
- Re: Draft for Resumable Uploads Julian Reschke
- Re: Draft for Resumable Uploads Austin Wright
- Re: Draft for Resumable Uploads Glenn Strauss
- Re: Draft for Resumable Uploads Guoye Zhang
- Re: Draft for Resumable Uploads Eric J Bowman
- Re: Draft for Resumable Uploads Eric J Bowman
- Re: Draft for Resumable Uploads Julian Reschke
- Re: Draft for Resumable Uploads Julian Reschke
- Re: Draft for Resumable Uploads Roy T. Fielding
- Re: Draft for Resumable Uploads Stefan Eissing
- Re: Draft for Resumable Uploads Julian Reschke
- Re: Draft for Resumable Uploads Eric J Bowman
- Re: Draft for Resumable Uploads Eric J Bowman